Black-box testing is a method of software testing that examines the functionality of an application (e.g. what the software does) without peering into its internal structures or workings (see white-box testing). This method of test can be applied to virtually every level of software testing: unit, integration, system and acceptance. It typically comprises most if not all higher level testing, but can also dominate unit testing as well. Focuses on the analysis of software functionality, versus internal system mechanisms. Black box testing was developed as a method of analyzing client requirements, specifications and high-level design strategies.
A black box software tester selects a set of valid and invalid input and code execution conditions and checks for valid output responses.
Black box testing is also known as functional testing. A software testing technique whereby the internal workings of the item being tested are not known by the tester. For example, in a black box test on a software design the tester only knows the inputs and what the expected outcomes should be and not how the program arrives at those outputs. The tester does not ever examine the programming code and does not need any further knowledge of the program other than its specifications.
The advantages of this type of testing include:
- The test is unbiased because the designer and the tester are independent of each other.
- The tester does not need knowledge of any specific programming languages.
- The test is done from the point of view of the user, not the designer.
- Test cases can be designed as soon as the specifications are complete.
The disadvantages of this type of testing include:
- The test can be redundant if the software designer has already run a test case.
- The test cases are difficult to design.
- Testing every possible input stream is unrealistic because it would take a inordinate amount of time; therefore, many program paths will go untested.
For a complete software examination, both white box and black box tests are required.
- Tests are done from a user’s point of view and will help in exposing discrepancies in the specifications
- Tester need not know programming languages or how the software has been implemented
- Tests can be conducted by a body independent from the developers, allowing for an objective perspective and the avoidance of developer-bias
- Test cases can be designed as soon as the specifications are complete
- Only a small number of possible inputs can be tested and many program paths will be left untested
- Without clear specifications, which is the situation in many projects, test cases will be difficult to design
- Tests can be redundant if the software designer/ developer has already run a test case.
- Ever wondered why a soothsayer closes the eyes when foretelling events? So is almost the case in Black Box Testing.
If You are inetersted to learn more about the types, please see:
- Classification Trees Testing
- Decision Table Testing
- Def Taxonomies ErrGuessing Checklist Exploratory
- Equivalence Partitioning
- Pairwise Testing
- State Transition Testing
- Use Case Testing
So have fun....in automation.
- Decision Table Testing
- Def Taxonomies ErrGuessing Checklist Exploratory
- Equivalence Partitioning
- Pairwise Testing
- State Transition Testing
- Use Case Testing
So have fun....in automation.
No comments:
Post a Comment