Static black-box testing tests the functional requirements documents with the aim of ensuring they are complete, clear, relevant, feasible, and testable (Software Testing, 2nd Edition, 2006). No program is executed, and bugs caught at this stage can greatly reduce the costs of a project.
Once the requirements are understood, test input data is identified, expected results are confirmed, and dynamic block-box testing can begin.
Input data can be identified using black-box testing techniques such as equivalence partitioning, boundary value analysis, decision table testing, state transition testing, and exploratory testing. It is impossible to test all combinations of inputs and outputs in most software, and these techniques provide an effective set of test cases that can be executed in a reasonable amount of time.
Expected results should be clear before test execution begins. However, they may change as the project evolves, or the tester may encounter an actual result that only deviates slightly from what is expected but is too costly to change. In these cases, communication is important to ensure everyone is on the same page.
Dynamic black-box testing involves running the program, entering inputs, receiving outputs, and comparing the actual result with the expected result. The behaviour of the system is tested from a perspective similar to the customer’s experience.