Introduction
Focuses on the functional requirements and the information domain of the software. Used during the later stages of testing after white-box testing has been performed.
The tester identifies a set of input conditions that will fully exercise all functional requirements for a program. It is also known as Closed Box Testing, Behavioral Testing, and Functional Testing.
It attempts to find the errors of following categories:
- Incorrect or missing functions o Interface errors
- Errors in data structures or external data base access
- Behavior or performance errors o Initialization and termination errors
This type testing is designed to give answers the following types of questions: o How is functional validity tested? o How are system behavior and performance tested? o What classes of input will make good test cases?
- Is the system particularly sensitive to certain input values?
- How is the boundary values of a data class isolated? o What data rates and data volume can the system tolerate?
- What effect will specific combinations of data have on system operation?
Advantages
- The tester can be non-technical
- Used to verify contradiction in actual statement and specifications
Disadvantages
- Test input needs to be from large sample space
- Difficult to identify all possible inputs
Black Box Testing Image :-
Techniques of black box testing
- Equivalence class
- Boundary value analysis
- Error guessing
1. Equivalence Class
It divides the input domain of program in two classes of data from which test cases can be derived.
It labels classes as valid and invalid inputs .
EX: Area code: Blank or three digit not only
Password : six digit alphanumeric string
2. Boundary Value Analysis
- BVA is a test functional testing technique where extreme boundary values are chosen.
- Boundary values include maximum, minimum, just inside, typical values, and error values.
3. Error guessing
- This is simply based on prior experience and judgment of tester.
- Guessing is the art of guessing where error can be hidden
Verification v/s Validation
Verification: The software should confirm to its specification (Are we building the product right?)
Validation: The software should do what the user really requires (Are we building the right product?)