Category: Dynamic Testing

Faulty specifications or requirements are not revealed All black-box testing techniques are based on the requirements and/or specifications of a system or its components and their interactions. If the requirements include erroneous definitions or an erroneous specification was used as the basis for an implementation, black-box testing will not reveal these defects. This is because…

Use cases and business cases are often used to determine and document system requirements. These are generally illustrated using use case diagrams. Such diagrams describe typical use/system interactions and are used to specify requirements on a fairly abstract level. Figure 5-8 shows a use case diagram for part of the VSR-II vehicle selection process. Example Fig. 5-8Use-Case diagram for…

Open-source tools You are sure to be asking yourself which formulae you can use to derive your n-wise test cases. Fortunately, there are plenty of dedicated software tools available that do (most of) the work for you. We are not in the business of advertising, but the authors of the German-language OpenBook “Lean Testing for…

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…