BLACK BOX TESTING Using the black box approach

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-undertest may come from a formal specification, an Input/Process/Output Diagram (IPO), or a well-defined set of pre and post conditions. BBT 1

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 2

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 3

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 1. 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 4

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 5

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