Common terms used in HyBIST and its definitions/meaning are listed in table below.
| Needs and expectations | Needs represent the various features/flows of software/system, to enable end-user(s) to perform their tasks. Expectations, on the other hand, are about how well the “needs” (i.e. features of the system) are fulfilled. Good quality is about meeting expectations. |
| Cleanliness Criteria (CC) | Given that a need has to be meeting the expectation(s), how do we state the expectation? In HyBIST, this is stated as “cleanliness criteria” what quality aspects, where a criterion represents a characteristic/property that ‘a need’ shall have to satisfy. A collection of the entire criterion for ‘a need’ is termed “cleanliness criteria”, to enable expectation to be clear/testable. |
| Potential Defect (PD) | A possible problem/issue that could exist in the software application. |
| Potential Defect Type (PDT) | A set of similar PD(s) grouped into a defect category. Note CC is not met when PDTs that affect that CC may be present. |
| Feature | A service/function that is offered by the system. |
| Requirement/Use case | A collection of features that enables an end user to do a job. |
| Quality level | The act of uncovering PDTs in HyBIST is seen as a filtration process. In HyBIST there are NINE levels of filtration. Each filter is focused on uncovering a set of PDTs thereby meeting some of the cleanliness criteria. Each of these levels is termed ‘Quality level’. |
| Test type | A specific test that focuses on uncovering a specific set of PDTs. |
| Test technique | One that enables a formal design of scenarios and test cases. |
| Test strategy | Strategy in HyBIST is a Cartesian product of ‘What-to-test’ ,‘Test-for-what’ and ‘How-to-test’ i.e. what types of tests have to be performed on what features/requirements , what-test (design)-techniques’ to use and how to execute the test cases. |
| Behaviour-Stimuli approach | Stimulate the system-under-test and check behaviours – the design approach in HyBIST, wherein the focus is on coming up with ‘stimuli’ to ascertain correctness of ‘behaviours. Test cases are the ‘stimuli’ and these validate the scenario (‘behaviour’). |
| Test scenario | In HyBIST, a test scenario is one that validates “a-behaviour’ of an entity under test. Given that the behaviour can be modeled as a set of conditions to be satisfied by an EUT, a scenario represents an instantiation of the values of all the conditions resulting in a flow. A test scenario with at least one condition violated is termed as “negative scenario”, while a positive scenario is one where none of the conditions are violated. |
| Test case | A test case is a combination of inputs and represents a data set. A test scenario is thus a collection of test cases. |
| Fault traceability | Fault traceability is about ensuring that test scenarios/cases indeed have the power to detect the potential defects that been hypothesized. In requirement traceability test scenarios/cases are mapped to the entity under test, while here the test scenarios/cases are mapped to the potential defect type(PDT). |
| Countabilty | The ability to justify logically as to why we have the given number of test scenarios/cases. Useful to judge test adequacy. |
| Potency | The ability of test cases to uncover an instance of potential defect type. Potency is about the least number of test cases with ability to target specific types of defects in specific areas to ensure ‘clean software’. |
| Immunity | A term that indicates the ‘potential resistance’ to uncovering PDTs, that software has become immune to the test cases. Denotes that the areas targeted have become strong (good quality) and that the potency of the test cases have indeed become weak. |