Author: Haroon Khalil

Side Note: n-wise combinatorial testing The testing techniques we have looked at so far are all based on system specifications and their associated considerations. If there are no direct dependencies between individual inputs (i.e., all inputs can be feely combined), mathematics can help us select appropriate combinations and design the corresponding test cases. Here is…

The techniques discussed so far view multiple input parameters separately from one another, and test cases are designed on the basis of individual values. Dependencies between the various input parameters and their effects on the test object’s output are not an explicit part of the test case specifications. Side Note: Cause-Effect Graphing [Myers 12] describes Cause-Effect…

The present system state depends on the past Alongside input data, preceding steps in the program flow also influence output and general system behavior. In other words, you also need to pay attention to the history of the system you test. State models and state diagrams are used to help design state transition tests. Guard…

A useful addition Boundary value analysis provides a useful addition to test cases determined using equivalence partitioning. This is because faults often occur at the boundaries of equivalence partitions where error-prone special cases occur. Tests with boundary values often reveal previously undiscovered defects. Boundary value analysis can only be applied if the data set in…

An exit criterion can be defined by the relationship between the number of tested values and the total number of equivalence partitions: EP coverage = (Number of tested EPs / total number of EPs) ×100% In our example, 18 input value equivalence partitions are derived from the specifications, of which 1510 are used to build test…

Here, the absolute number of possible concrete input values for the input data (a single parameter of the test object) is divided into partitions (also called “classes”). An equivalence partition contains all data values that the tester expects the test object to process in the same way. In other words, it is assumed that testing…

Because a black-box test has no knowledge of the inner workings of the test object, test cases are derived from (or, ideally, are already part of) the specifications. Because they are derived from specifications (i.e., requirements or system behavior), these techniques are also referred to as specification-based, or behavior-based. A complete test sequence that covers…

Experience-based test techniques leverage the know-how and experience of testers, developers, users, and other stakeholders to design test cases, test conditions, and test data. This approach also uses knowledge of the software’s planned usage, its environment, and the probable type and location of faults in the test object. A specific degree of coverage is difficult…

White-box test techniques can be applied on the lower component and integration test levels. A system test that is based on code makes little sense. Black-box techniques can be used on all test levels. All techniques that define test cases before coding (such as test-first/test-driven development) are by definition black-box techniques. Most test techniques belong…

Unlike black-box techniques, white-box testing techniques focus on the structures and behavior within the test object. This is why white-box techniques are also known as structural or structure-based testing techniques. Here too, test cases, test conditions and test data are derived from the test basis. As well as requirements (for example, to define the expected…