Black-Box Testing
• Black Box Testing is testing technique having no knowledge of the internal functionality/structure of the system
• Synonyms for Black-Box are Behavioral, Functional, Opaque-Box, Closed-Box etc.
• Black-box Testing focuses on testing the function of the program or application against its specification
• Determines whether combinations of inputs and operations produce expected results
• When black box testing is applied to software engineering, the tester would only know the "legal" inputs and what the expected outputs should be, but not how the program actually arrives at those outputs
Focus of Black-Box Testing
In this technique, we do not use the code to determine a test suite; rather, knowing the problem that we're trying to solve, we come up with four types of test data:
• Easy-to-compute data
• Typical data
• Boundary / extreme data
• Bogus data
Black-Box Testing Techniques

Equivalence Partitioning
Boundary Value Analysis
Error Guessing
Cause-Effect Graphing 

Equivalence Partitioning
An equivalence class is a subset of data that is representative of a larger class
Equivalence partitioning is a technique for testing equivalence classes rather than undertaking exhaustive testing of each value of the larger class
Example - EP

For example, a program which edits credit limits within a given range ($10,000 - $15,000) would have three equivalence classes
< $10,000 (invalid) Between $10,000 and $15,000 (valid) > $15,000 (invalid)

Boundary Analysis

This technique consists of developing test cases and data that focus on the input and output boundaries of a given function
In the same credit limit example, boundary analysis would test.
Low boundary -/+ one ($9,999 and $10,001)
On the boundary ($10,000 and $15,000)
Upper boundary -/+ one ($14,999 and $15,001)

Error Guessing
• Test cases can be developed based upon the intuition and experience of the tester
• For example, where one of the inputs is the date, a tester may try February 29, 2001
Cause-Effect Graphing
Cause-effect graphing is a technique for developing test cases for programs from the high-level specifications (A high-level specification states desired characteristics of the system)
These characteristics can be used to derive test data
Example – Cause Effect
For example, a program that has specified responses to eight characteristic stimuli (called causes) given some input has 256 "types" of input (i.e., those with characteristics 1 & 3; 5, 7 & 8 etc.).
A poor approach is to generate 256 test cases.
A more methodical approach is to use the program specifications to analyze the program's effect on the various types of inputs.
The program's output domain can be partitioned into various classes called effects.
For example, inputs with characteristic 2 might be subsumed by those with characteristics 3 & 4. Hence, it would not be necessary to test inputs with characteristic 2 and characteristics 3 & 4, for they cause the same effect.
This analysis results in a partitioning of the causes according to their corresponding effects
A limited entry decision table is then constructed from the directed graph reflecting these dependencies (i.e., causes 2 & 3 result in effect 4; causes 2, 3 & 5 result in effect 6 etc.)
The decision table is then reduced and test cases chosen to exercise each column of the table.
Since many aspects of the cause-effect graphing can be automated, it is an attractive tool for aiding in the generation of Functional Test cases.

Advantages of Black-Box Testing
• More effective on larger units of code than glass box testing
• Tester needs no knowledge of implementation, including specific programming languages
• Tester and programmer are independent of each other
• Tests are done from a user's point of view
• Will help to expose any ambiguities or inconsistencies in the specifications
• Test cases can be designed as soon as the specifications are complete

Disadvantages of Black-Box Testing

• Only a small number of possible inputs can actually be tested, to test every possible input stream would take nearly forever
• Without clear and concise specifications, test cases are hard to design
• There may be unnecessary repetition of test inputs if the tester is not informed of test cases the programmer has already tried
• May leave many program paths untested
• Cannot be directed toward specific segments of code which may be very complex (and therefore more error prone)