The principle ‘Testing shows the presence of defects’ means that testing can demonstrate that defects are present, but cannot prove that there are no defects. The second tester’s approach of actively trying to find defects by performing unexpected actions aligns with this principle, as it aims to reveal issues that may not be caught by simply confirming the system works as specified.

The principle of ‘Absence-of-errors fallacy’ states that finding and fixing defects does not help if the system built is unusable and does not fulfill the users’ needs and expectations. More directly, testing can show defects are present, but cannot prove they are absent. Therefore, an exit criterion of ‘zero known critical defects’ is an unrealistic target that misunderstands the inherent limitations of testing; we can never be certain we have found all critical defects.

A failure is an event in which a component or system does not perform a required function within specified limits. In this scenario, the observable event is that the function fails when entering a past date, which deviates from the specified requirement. The flaw in the code (defect) is the cause, and the human mistake (error) is the root cause, but the immediate observation by the tester is the system’s failure.

Equivalence Partitioning involves dividing input data into valid and invalid partitions, and then selecting one representative value from each partition for testing. Here, the values represent different partitions: 4 and 9 (valid positive numbers), 0 (a boundary valid number), and -1 (an invalid number, as square root of a negative is typically not defined for real numbers).

State Transition Testing is used for systems that have defined states and transition between them based on events or rules. The thermostat is a classic example, with clear states (‘Heating’, ‘Idle’) and transitions triggered by specific conditions (temperature below/at set point). This technique is ideal for designing tests that cover valid transitions, invalid transitions, and sequences of states.

A decision table lists causes (inputs/conditions) and effects (outputs/actions). The causes here are: ‘Username has text?’ (True/False) and ‘Password has text?’ (True/False). To achieve the minimum coverage for all combinations of conditions, you must test all four possible combinations of True and False for the two conditions, which is exactly what option 2 describes.

A test condition is an item or event of a component or system that could be verified by one or more test cases (e.g., a function, transaction, feature, quality attribute, or structural element). It is derived from the test basis (sources like requirements) and answers the question ‘What can we test?’ before we define the detailed ‘How’ in a test case.

A principle of testing economics is that you should invest in activities that provide long-term value and reduce recurring costs. Automating repetitive, stable, and high-priority regression tests is a classic example. It requires an upfront investment but saves significant time and cost in subsequent cycles, improves consistency, and frees up human testers for more complex, exploratory, and non-automatable testing tasks.

Performance characteristics like response time are typically non-functional requirements of the complete, integrated system. Verifying that the system meets these specified performance criteria is a key objective of System Testing, where the system is evaluated as a whole against both functional and non-functional requirements.

The principle ‘Testing shows the presence of defects’ means that testing can demonstrate that defects are present, but cannot prove that there are no defects. The second tester’s approach of actively trying to find defects by performing unexpected actions aligns with this principle, as it aims to reveal issues that may not be caught by simply confirming the system works as specified.0