1. BLACK BOX TESTING
Using the black box approach, a tester considers the software-under test to be an opaque box. There is no knowledge of its inner structure (i.e., how it works).
The tester only has knowledge of what it does.
The size of the software-under-test using this approach can vary from a simple module, member function, or object cluster to a subsystem or a complete Software system.
The description of behavior or functionality for the software-under- test may come from a formal specification, an Input/Process/Output Diagram (IPO), or a well-defined set of pre and post conditions.
BBT

2. BLACK BOX TESTING
Another source for information is a requirements specification document that usually describes the functionality of the software-under-test and its inputs and expected outputs. The tester provides the specified inputs to the software-under-test, runs the test and then determines if the outputs produced are equivalent to those in the specification.  
BBT

3. BLACK BOX TESTING
Because the black box approach only considers software behavior and functionality, it is often called functional or specification- based testing.
This approach is especially useful for revealing requirements and specification defects.
BBT

4. BLACK BOX TESTING Example
LOCK AND KEY: Should not know the levers in the lock, but we know the set of inputs and expected output ( Lock and unlock)
Functionality
Features of a key:
Made up of metal
It has a Hole Provision to lock
Facility to insert key
Ability to turn clockwise and anticlockwise direction
BBT

5. BLACK BOX TESTING
2. Features of a Key It is made of metal It Fit into a particular lock’s keyhole 3. Action performed Key inserted and turned clockwise to lock Key inserted and turned anticlockwise unlock
BBT

6. BLACK BOX TESTING
4. States Locked and unlocked 5. Inputs Key turned clockwise or anticlockwise 6. Expected outcome Locking and unlocking
BBT