July 10th, 2008 chris
Black box testing is a strategy in which testing is based solely on the requirements and specifications. Unlike its complement, white box testing, black box testing requires no knowledge of the internal paths, structure, or implementation of the software under test (SUT).
The general black box testing process is:
- The requirements or specifications are analyzed.
- Valid inputs are chosen based on the specification to determine that the SUT processes them correctly. Invalid inputs must also be chosen to verify that the SUT detects them and handles them properly.
- Expected outputs for those inputs are determined.
- Tests are constructed with the selected inputs.
- The tests are run.
- Actual outputs are compared with the expected outputs.
- A determination is made as to the proper functioning of the SUT
Posted in Software Testing
July 10th, 2008 chris
Early views saw testing as a phase that occurred after software development, or “something that programmers did to get the bugs out of their programs.” The more modern view sees testing as a process to be performed in parallel with the software development or maintenance effort incorporating the activities of planning (determining risks and selecting strategies); analysis (setting test objectives and requirements); design (specifying tests to be developed); implementation (constructing or acquiring the test procedures and cases); execution (running and rerunning the tests); and maintenance (saving and updating the tests as the software changes).
This lifecycle perspective of testing represents a major change from just a few years ago, when many equated testing with executing tests. The contribution of planning, analyzing, and designing tests was under-recognized (and still is by many people), and testing was not seen as really starting until tests started running. Now we understand the evaluation power of test planning and analysis. These activities can be more powerful than test execution in defect prevention and timely detection. We also understand that an accurate interpretation of the situation when “all tests are running successfully” requires a clear understanding of the test design.
The lifecycle model for testing that has emerged borrows heavily from the methodology we’ve grown accustomed to for software. Considering that a test set is made up of data and procedures (which are often implemented as executable test programs), it should not come as a surprise that what it takes to build good software is also what it takes to build good testware!
Posted in Software Testing