People talk of software testing in terms of Black Box and White Box Testing, and test case design techniques are often organised into these two categories.
Black box and White Box are not Testing phases or types of testing, they are categories for techniques used to select and create test cases.
Black box testing:
Black box testing it is not required to know about code but the knowledge of functionality is mandatory. Black Box testing is done when the functionality/flow of the system is clearly defined and the internal logic is not looked into.
Black box testing takes an external perspective of the test object to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid input and determines the correct output. There is no knowledge of the test object's internal structure.
This method of test design is applicable to all levels of software testing: unit, integration, functional testing, system and acceptance. The higher the level, and hence the bigger and more complex the box, the more one is forced to use black box testing to simplify. While this method can uncover unimplemented parts of the specification, one cannot be sure that all existent paths are tested.
Typical black box test design techniques include:
a. Equivalence partitioning
b. Boundary value analysis
c. Decision table testing
d. Pairwise testing
e. State transition tables
f. Use case testing
g. Cross-functional testing
White Box Testing:
White box testing (a.k.a. clear box testing, glass box testing or structural testing) uses an internal perspective of the system to design test cases based on internal structure. It requires programming skills to identify all paths through the software. The tester chooses test case inputs to exercise paths through the code and determines the appropriate outputs. In electrical hardware testing, every node in a circuit may be probed and measured; an example is in-circuit testing (ICT).
Since the tests are based on the actual implementation, if the implementation changes, the tests probably will need to change, too. For example ICT needs updates if component values change, and needs modified/new fixture if the circuit changes. This adds financial resistance to the change process, thus buggy products may stay buggy. Automated optical inspection (AOI) offers similar component level correctness checking without the cost of ICT fixtures, however changes still require test updates.
While white box testing is applicable at the unit, integration and system levels of the software testing process, it is typically applied to the unit. While it normally tests paths within a unit, it can also test paths between units during integration, and between subsystems during a system level test. Though this method of test design can uncover an overwhelming number of test cases, it might not detect unimplemented parts of the specification or missing requirements, but one can be sure that all paths through the test object are executed.
Typical white box test design techniques include:
a. Control flow testing
b. Data flow testing
c. Branch Testing
Test condition is identified from Test scenarios. A scenario may have one or more test conditoins. In other words it's a similar set of stepsÂ followed by top-down approach in a sequence to perform a certain task.