Black Box testing validates that the software meets the functional requirements irrespective of the paths of execution taken to meet each requirement. It is conducted on integrated, functional components whose design integrity has been verified through the completion of traceable white box tests.
Black Box testing treats the software as a 'black box' without any knowledge of internal implementation. It is a specification-based testing which aims to test the functionality of software according to the applicable requirements. The tester inputs data into and only sees the output from the test object. This level of testing usually requires thorough test cases to be provided and then simply verify that for a given input, the output value 'is' or 'is not' the same as the expected value specified in the test case.
When creating black box test cases, the input data used is critical. Three successful techniques for managing input data are
- Equivalence Partitioning
- Boundary Value Analysis
- Error Guessing
This technique is used to reduce the number of test cases to a necessary minimum and to select the right test cases out of a larger class rather than undertaking exhaustive testing of each value of the larger class.
For eg, a program which edits credit limits within a given range ($10,000- $15,000) would have three equivalence classes, <$10,000, between $10,000 and $15,000 and > $15,000. The values within one partition are considered to be equivalent, so it is sufficient to select one value out of each partition. Thus the number of test cases can be reduced considerably.
Boundary Value Analysis
The technique that consists of developing test cases and data that focus on the input and output boundaries of a given function.
For the above example, the boundary values would be, low boundary plus or minus one($9,999 and $10,001), on the boundary($10,000 and $15,000) and upper boundary plus or minus one($14,999 and $15,001).
Error Guessing
This technique is based on the theory that test cases can be developed based upon the intuition and experience of the test engineer.
For eg, in a test case where the input is the date, the test engineer may try February 29,2000.
Remark
Specification-based testing is necessary, but it is insufficient to guard against certain risks, because the tester doesn't know how the software being tested was actually constructed.
White Box Testing
White Box testing examines the basic program structure and derives the test data from the program logic, ensuring that all statements and conditions have been executed atleast once.
The tester has access to the internal data structures and algorithms and the code that implemented these. The tester validates that the software design is valid and whether it was built according to the specified design.
Code Coverage
The test designer can create test cases to ensure that all statements in the program have been executed atleast once. This allows the software team to examine parts of a system that are rarely tested and ensures that the most important function points have been tested.
Code coverage includes decision coverage, statement coverage and condition coverage.
Incremental Testing
Incremental testing is partial testing of an incomplete product. The goal of incremental testing is to provide an early feedback to software developers. It involves adding unit-tested programs to a given module or component one by one, and testing each result and combination.
Types
Top-down- Begins testing from the top of the module hierarchy and works down to the bottom.
Bottom-up- Begins testing from the bottom of the hierarchy and works up to the top.
Thread Testing
Thread testing is often used during early integration testing. It is done by testing a string of units that accomplish a specific function in the application.
Thread testing and incremental testing are usually utilized together. Units can undergo incremental testing until enough units are integrated and a single business function can be performed threading through the integrated components.
No comments:
Post a Comment