This document discusses black box testing techniques. It defines black box testing as testing that ignores internal mechanisms and focuses on inputs and outputs. Six common black box testing techniques are described: equivalence partitioning, boundary value analysis, cause-effect graphing, decision table-based testing, orthogonal array testing, and syntax-driven testing. The document provides examples of how to use these techniques to design test cases to uncover faults.

1. Black Box Testing

2. Testing Overview and Black-Box
Testing Techniques
 Software testing is an important technique for assessing the quality
of a software product.
 The basics of software testing, a verification and validation practice,
throughout the entire software development lifecycle
 The two basic techniques of software testing, black-box testing and
white-box testing
 Six types of testing that involve both black- and white-box
techniques.
 Strategies for writing test cases and still finding as many faults as
possible.

3. Introduction to Testing
 Software testing is the process of analyzing a software item to
detect the differences between existing and required conditions
(that is, bugs) and to evaluate the features of the software item.
Verification: Are we building the product right?
 Through verification, we make sure the product behaves the way
we want it to.
Validation: Are we building the right product?
 Through validation, we check to make sure that somewhere in
the process a mistake hasn’t been made such that the product
build is not what the customer asked for; validation always
involves comparison against requirements.

4.  The following terms with their associated definitions are helpful
for understanding these concepts:
• Mistake – a human action that produces an incorrect result.
• Fault [or Defect] – an incorrect step, process, or data definition in
a program.
• Failure – the inability of a system or component to perform its
required function within the specified performance requirement.
• Error – the difference between a computed, observed, or
measured value or condition and the true, specified, or
theoretically correct value or condition.
• Specification – a document that specifies in a complete, precise,
verifiable manner, the requirements, design, behavior, or other
characteristic of a system or component, and often the
procedures for determining whether these provisions have been
satisfied.

6. The Economics of Software Testing
 In software development, there are costs associated with testing our
programs. We need to write out test plan and our test cases, we
need to set up the proper equipment, we need to systematically
execute the test cases, we need to follow up on problems that are
identified, and we need to remove most of the faults we find.
 To minimize the costs associated with testing and with software
failures, a goal of testing must be to uncover as many defects as
possible with as little testing as possible. In other words, we want to
write test cases that have a high likelihood of uncovering the faults
that are the most likely to be observed as a failure in normal use.

7. The Basics of Software Testing
 Black box testing (also called functional testing) is testing that ignores
the internal mechanism of a system or component and focuses solely
on the outputs generated in response to selected inputs and
execution conditions.
 White box testing (also called structural testing and glass box testing)
is testing that takes into account the internal mechanism of a system
or component.

9. Black Box Testing:
 Only input & output functionality are visible.
 Inputs are given and outputs are compared against
specification.
Features:
• Correct outputs from inputs properly.
• Test cases are designed from user requirements.
• Test planning can begin early in the software process.
• Looking at the program from an external point of view.

11. Black Box Testing
Input Test Data I
System
output Test Results O
Inputs
causing
anomalous
behavior
Outputs which
reveal the
presence of
defects

12. Black Box Testing is a “Expert” in
Finding
1. Incorrect or missing functions.
2. Interface errors
3. Behavior or performance errors.
4. Initialization and termination errors.
5. Errors in data structures
6. External database errors.

13. Graph Based Testing Methods
 Each and every application is build up of some objects. All such
objects are identified and graph is prepared. From this object graph
each object relationship is identified and test cases written
accordingly to discover the errors.

14. Sample Graph Notation
Directed Link
Object 1 Object 2
Object 3
•Nodes are represented as circles.
•Links between nodes are categorized as:
•Directed Link (one direction)
•Bidirectional or Undirected or Symmetric Link: both directions.
•Parceled links: different relationships established between nodes.

15. Error Guessing Testing Methods
 This is purely based on previous experience and judgment of tester.
Error Guessing is the art of guessing where errors can be hidden. For
this technique there are no specific tools, writing the test cases that
cover all the application paths.

16. Methods of Black box Testing

17. 1. Equivalence Partitioning
 Equivalence Partitioning is a software test design technique that
involves dividing input values into valid and invalid partitions and
selecting representative values from each partition as test data.

18. 2. Boundary Value Analysis (BVA)
 Boundary Value Analysis is a software test design technique that
involves determination of boundaries for input values and selecting
values that are at the boundaries and just inside/outside of the
boundaries as test data.

19. 3. Cause Effect Graphing
 Cause Effect Graphing is a software test design technique that involves
identifying the cases (input conditions) and effects (output conditions),
producing a Cause-Effect Graph, and generating test cases accordingly.

20. 4. Decision Table-Based Testing
 Decision tables are used to record complex business rules that must
be implemented in the program, and therefore tested
 In the table, the conditions represent possible input conditions. The
actions are the events that should trigger, depending upon the
makeup of the input conditions. Each column in the table is a
unique combination of input conditions (and is called a rule) that
result in triggering the action(s) associated with the rule. Each rule
(or column) should become a test case.

22. 5. Orthogonal Array Testing
 Used to finding errors associated with region faults.
 number of inputs to the system is relatively small, but too large to
allow for exhaustive testing of every possible input to the systems.
 It provides good test coverage with test cases.

23. 6. Syntax Driven Testing
 Very good methodology for compliers and parsers.
 Use BNF notation.
 Described by grammar.
 Grammar for simple arithmetic:
(exp)::=(exp)+(term)|(exp)-(term)|(term)
(term)::=(term)*(factor)|(term)-(factor)|(factor)
(factor)::=(identifier)|(<expression>)
(id)::=|a|b|c|d|e………|z

24. 7. Cause and Effect Graphs in
Functional Testing
 Represents relationship between input and output
 Input  cause
 Output  effect.
Ex: ATM Banking Transaction System

25. Causes:
C1: Command is credit
C2: Command is Debit
C3: Account Number is valid.
C4: Transaction amount is Valid.
Effects:
E1: Print “Invalid command”
E2: Print “invalid account number”
E3: Print “debit amount not valid”
E4: debit account
E5: credit account.

26. Types processing modes
 And  effect occurs of all the inputs are true.
 Or  Effect occurs if at least one input is true
 Negation : effect occurs if input are false.

27. C2
C3
C4
E3
and
Used to reduce the test case
count
C1 C2 C3
C4
Don’t
care
condition
True false