Black Box Testing Techniques

© Moreniche

  • Equivalence Partitioning
  • Boundary Value Analysis
  • State Transitions
  • Exploratory Testing

1) Equivalence Partitioning

Partition the input domain into a finite number of equivalence classes

Create test cases to invoke as many different conditions as possible

It is based on the premise that if a test case in an equivalence class detects an error, all other test cases in the same class detect the same error

Step 1

Identify the input parameters

Identify the allowable classes of input

Select a representative value for each class

Create test cases to cover as many classes as possible

Step 2

Select invalid values for each class

Create additional test cases to cover invalid classes

Step 3

Identify the output parameters

Identify the possible classes of output

Create test cases to generate each possible output

External Condition



Boundary Value

1. Input Hours

a. Regular

b. Over Time

2. Input Rate

3.5 to 13.5

3. Gross pay

10 to 2000







2.1, -2.5

15.0, ax2

9, 2010



•Identify input equivalence classes

–Based on conditions on inputs / outputs in specification / description

–Both valid and invalid input equivalence classes

–Based on heuristics and experience

•“Input x in [1..10]” ® classes: x < 1, 1 £ x £ 10, x > 10

•“Enumeration A, B, C ® classes: A, B, C, not {A, B, C,}

• Define one / couple of test cases for each class

–Test cases that cover valid eq. classes

–Test cases that cover at most one invalid eq. class

•Test a function for calculation of absolute value of an integer

•Equivalence classes :

Condition Valid eq. classes Invalid eq. Classes


Nr of inputs 2 < style=""> > 2

Type of input int int int no-int, no-int int

Abs(value) value < 0, value ³ 0

maxint å k £ maxint,
å k > maxint

•Test Cases : maxint value result

Valid 100 10 55
100 -10 55
10 10 error
Invalid 10 - error
10 20 30 error
“XYZ” 10 error
100 9.1E4 error

2) Boundary Value Analysis

Boundary Value Analysis technique tests conditions on, above and beneath the edges of input and output Equivalence Classes

Test cases are created to test the edge of each Equivalence Class

Test cases are created to test edges of both input and output classes

For each equivalence class identified:

Select a value on the class boundary

Pick a value just under the boundary

Pick a value just over the boundary

External Condition



Boundary Value

1. Input Hours

a. Regular

b. Over Time

2. Input Rate

3.5 to 13.5

3. Gross pay

10 to 2000







2.1, -2.5

15.0, ax2

9, 2010

40, 39.9, 40.1

59.9, 60, 60.1

3.5, 3.49, 3.51

13.5, 13.51, 13.49

10.0, 10.01, 9.99

2000, 2000.1, 1999

3) Finite State Testing


Create test cases to:

Force each transition

Force each action

4) Exploratory Testing

Some people can design test cases that will discover failures based on their experience

Allow these people to write test cases

Address complex areas

Address changes

Report failures, faults and errors so that experience level may grow

White-Box Testing Techniques

1) Control Flow

Statement Coverage: To write test cases such that every statement is executed at least once, it is a weak criteria, it will not test the validity of logical operators

Decision (Branch) Coverage: Decision Coverage (also called Branch Coverage) states that test cases must be written such that each decision has a True and False outcome at least once, Decision Coverage emphasizes that each branch direction must be executed at least once, It usually satisfies Statement Coverage

Condition Coverage: Condition Coverage technique states that test cases must be written such that every condition in a decision takes all possible outcomes at least once, Condition Coverage technique may not cover all decision outcomes

Decision/Condition Coverage: Decision/Condition coverage technique states that each condition should take on all possible outcomes at least once and each decision must take on all possible outcomes at least once

Multiple Condition Coverage: Multiple Condition coverage technique states that test cases must be written such that all possible combinations of conditions in each decision are taken at least once

Loop Coverage: Loop coverage technique states that test cases must be written to test the loop counters

2) Data Flow

All Definitions

All Predicates Uses

All Computation Uses

All P-uses/some C-uses

All Uses

Walkthrough - Main purpose: understanding

  • Author guides the group through a document, so all understand the same thing, concensus on changes to make

Review - Main purpose: decision-making

  • Group discusses document and makes a decision about the content, e.g. how something should be done, go or no-go decision

Inspection - Main purpose: find defects

  • Formal individual and group checking, using sources and standards, according to detailed and specific rules
  • Inspection is a well-defined process


Code Walk-Through

Select some test cases.

Simulate execution of the code by hand.


The number of people involved should be small (3-5).

The participants should receive written documentation from the designer a few days before the meeting.

The meeting should last a predefined amount of time.

Discussion should be focused on the discovery of errors, not fixing them, nor on proposing alternative design decisions.

Key people should be

• designer, presenting the rationale of the work.

• moderator for the discussion.

• secretary for writing a report.

Managers should not participate in the meeting.

Code Inspections

Similar to the code walk-through.

The analysis is aimed at the discovery of commonly made errors.

A list of some classical programming errors:

Use of uninitialized variables.

Jumps into loops.

Incompatible assignments.

Nonterminating loops.

Array indexes out of bound.

Improper storage allocation-deallocation.

Actual-formal parameter mismatches.

Comparisons of equality for floating point values.

Equivalence Class Partition and Boundary Condition Analysis

Equivalence class partitioning is a timesaving practice that identifies tests that are equivalent to one another; when two inputs are equivalent, you expect them to cause the identical sequence of operations to take place or they cause the same path to be executed through the code. When two or more test cases are seen as equivalent, the resource savings associated with not running the redundant tests normally outweighs the risk.

An example of an equivalence class includes the testing of a data-entry field in an HTML form. If the field accepts a five-digit ZIP code(e.g., 22222) then it can reasonably be assumed that field will accept all other five-digit ZIP codes (e.g. 33333, 44444, etc.)

In equivalence partitioning, both valid and invalid values are treated in this manner. For example, if entering six letters into the ZIP code field just described results in an error message, then it can reasonably be assumed that all six-letter combinations will result in the same error message. Similarly, if entering a four-digit number into the ZIP code field results in an error message, then it should be assumed that all four digit combinations will result in the same error message.


  • Ranges of numbers (such as all numbers between 10 and 99, which are of the same two-digit equivalence class)
  • Membership in groups (dates, times, country names, etc.)
  • Invalid inputs (placing symbols into text-only fields, etc)
  • Equivalent output events (variation of inputs that produce the same output)
  • Equivalent operating environments
  • Repetition of activities
  • Number of records in a database (or other equivalent objects)
  • Equivalent sums or other arithmetic results
  • Equivalent numbers of items entered (such as the number of characters entered into a field)
  • Equivalent space (on a page or on a screen)
  • Equivalent amount of memory, disk space, or other resources available to a program.

Boundary values mark the transition points between equivalence classes. They can be limit values that define the line between supported inputs and no supported inputs, or they can define the line between supported system requirements and nonsupport system requirements. Applications are more susceptible to errors at the boundaries of equivalence classes, so boundary condition tests can be quite effective at uncovering errors.

Generally, each equivalence class is partitioned by its boundary values. Nevertheless, not all equivalence classes have boundaries. For example, given the following four browser equivalent classes (NETSCAPE 4.6.1 and Microsoft Internet Explorer 4.0 and 5.0), there is no boundary defined among each class.

Each equivalence class represents potential risk. Under the equivalent class approach to developing test cases, at most, nine test cases should be executed against each partition.

HI to all,

I am having some doubt in Equivalence partitioning and Boundary value analysis.

Scenario: if i am giving you a range from 4 to 10.

What are the test case you can write in the above two analysis?

please send me the answer of both equivalence and boundary value otherwise explain me with some example.

U can break this range into 3 (apply equivalence partitioning)

1. Value <= 4

2. between 4 & 10

3. Value >=10

Now apply Boundary Value Analysis in each case

1. Select 3,4 & 5

2. Select 6

3. Select 9,10,11

Hi chinmaya ,

Equivalence partitioning for range there 1 valid and 2 invalid case's

1 valid ---- 7 (any no. bet & 4, 10 included)

2 invalid ----- 2 , 11

Boundary value analysis. (BVA)

for BVA case's r -1, minimum , +1 and -1 , maximum , +1

answer -- 3, 4, 5 and 9, 10 , 11

i think this both means the same thing as per my knowledge

for equivalence partitioning

one test case will be within the range that is anything from 4 to 10(valid test case)

and other one is from out of the range (invalid test case)

and for boundry value as mention

Ajith <> wrote:

Both are not exactly the same. But if u applied equivalence partition, boundary value analysis could be included

Consider different examples

Assume a text box for numbers. In this, first we have to apply equivalence partition to classify all the possible valid/invalid inputs

Here we can do the partition like

1. only numbers

2.only characters

3.only special characters

Except 1, others are invalid input. But we have to check invalid also. Now you can apply boundary value analysis theorem to reduce the no. of inputs/efforts. It is not possible to enter all the numbers, so find out the boundary values first and use that value with plus or minus 1 (eg: if 0 is minimum means, you have to take -1,0 & +1).You can apply the rule in other inputs also

this will reduce testing effort and also the no. of test cases. If test box is not accepting -1, it won't accept all the other negative numbers.

Equivalence Partitioning Method

Equivalence partitioning:
An equivalence class data is a subset of a larger class. This data is used for technically equivalence partitioning rather than undertaking exhaustive testing of each value in the larger set of data. For example, a payroll program, which edits professional tax deduction limits within Rs. 100 to Rs. 400, would have three equivalence partitions.

Less than Rs.100/- (Invalid Class)
Between Rs.100 to Rs.400/- (Valid Class)
Greater than Rs.400/- (Invalid Class)

If one test case from one equivalence class results in an error, all other test cases in the equivalence class would be expected to result the same error. Here, tester needs to write very few test cases, which is going to save our precious time and resources.

Boundary Value Analysis:

Experiences show that the test cases, which explore boundary conditions, have a higher payoff than test cases that do not. Boundary conditions are the situations directly on, above and beneath the edges of input and output equivalence classes.

This technique consists of generating test cases and relevant set of data, that should focus on the input and output boundaries of given function. In the above example of professional tax limits, boundary value analysis would derive the test cases for:

Low boundary plus or minus one (Rs.99/- and Rs.101/-)
On the boundary (Rs.100/- and Rs.400/-)
Upper boundary plus or minus one (Rs.399 and Rs.401/-)

Error Guessing:

This is based on the theory that test cases can be developed, based upon intuition and experience of the test engineer. Some people tend to adapt very naturally with program testing. We can say these people have a knack for 'Smelling out' errors without incorporating any particular methodology.
This "Error Guessing" quality of a tester enables him to put in practice, more efficient and result oriented testing than a test case should be able to guide a Tester.
It is difficult to give procedure for the error guessing technique since it is largely intuitive and ad hoc process. For example Where on of the input is the date test engineer may try February 29,2000 or 9/9/99.

Orthogonal Array:
Particularly this technique is useful in finding errors associated with region faults. An error category associated with faulty logic within software component.

For example there are three parameters (A, B & C) each of which has one of the three possible values. Which may require 3X3X3=27 Test cases. But because of the way program works it is probably it is more likely that the fault will depend on the values of only two parameters. In that case fault may occur for each of these 3 test cases.
1. A=1,B=1,C=1
2. A=1,B=1,C=2,
3. A=1,B=1,C=3

Since the value of the 'C' seems to be irreverent to the occurrence of this particular fault, any one of the three test cases will suffice. Depending upon the above assumption, test engineer may derive only nine test cases. Which will show all possible pairs within all three variables. The array is orthogonal because of each pair of parameters all combination of their values occurs once.

That is all possible pair wise combination between parameters A &amp;amp; B, B & C, C & A are shown since we are thinking in terms of pairs we say this array has strength of 2, It does not have strength of 3,
because not all thee way combination occurs A=1, B=2, C=3 for example, don't appear but it covers the pair

No comments:


My Blog List