Black Box Testing - Download as DOC

Document Sample
Black Box Testing - Download as DOC Powered By Docstoc
					Black Box Testing

Probably this is what most of us practice and is used most widely. This is also type of
testing which is very close to customer experience. In this type of testing system is
treated as close system and test engineer do not assume any thing about how system was
created.
As a test engineer if you are performing black box test cases, one thing that you need to
make sure is that you do not make any assumptions about the system based on your
knowledge. Assumption created in our mind because of the system knowledge could
harm testing effort and increase the chances of missing critical test cases.

Only input for test engineer in this type of testing is requirement document and
functionality of system which you get by working with the system.
Purpose of black box testing is to

      Make sure that system is working in accordance with the system requirement.
      Make sure that system is meeting user expectation.


In order to make sure that purpose of black box testing is met, various techniques can be
used for data selection like

      Boundary value analyses
      Equivalence partitioning


Activities within every testing types can be divided into verification and validation.
Within black box testing following activities will need verification techniques

      Review of requirement and functional specification.
      Review of Test plan and test cases.
      Review of test data

And test case execution will fall under validation space.

Boundary Value Analysis Testing

Boundary value analysis is the technique of making sure that behavior of system is
predictable for the input and output boundary conditions. Reason why boundary
conditions are very important for testing is because defects could be introduced at the
boundaries very easily. For example, if you were to write code to simulate following
condition –

" Input should be greater than equal to 10 and less than 50"

Probably you will write something like
if (input >=10 AND input <50) then

do some

else

do some thing else.

So, according to this input values from 10 to 49 are valid, but if you make mistake in
specifying the conditions, following things can happen

input >10 AND input <50 -------> Input value 10 in invalid now.

input <=10 AND input <50 -------> Input value 9 is valid now.

input >=10 AND input <=50 -----> Input value 50 is valid now

input >=10 AND input >50 -----> Input value 49 is invalid now

Because it is very easy to introduce defects at boundaries, boundary values are important.
So for the above example, at the minimum we should have following test cases for
boundaries

9, 10, 11 and 48, 49, 50

lower_boundary - 1, lower_boundary, lower_boundary + 1 and upper_boundary - 1,
upper_boundary, upper_boundary + 1

Do you think boundary value analyses can be used for other boundaries as well? Have
you ever used boundary value analyses with some variation to suite your project need? It
will be great if you can share your experience of boundary value analyses with us, if
approved it will be published under case studies section.

Equivalence Partitioning
Equivalence partitioning is a software testing technique to minimize number of
permutation and combination of input data. In equivalence partitioning, data is selected in
such a way that it gives as many different out put as possible with the minimal set of data.

If software behaves in an identical way for a set of value, then the set is termed as
equivalence class or a partition. It can be assumed safely that functionality of the
software will be same for any data value from the equivalence class or partition. In
equivalence partitioning, input data is analyzed and divided into equivalence classes
which produces different output.
Now, data from these classes can be representative of all the input values that your
software expect. For equivalence classes, it can be assumed that software will behave in
exactly same way for any data value from the same partition.

So essentially, there are two steps that you need to follow if you want to use equivalence
partitioning in your projects -

Identifying equivalence classes or partition

Picking one value from each partition for the complete coverage.

Main advantage of using this technique is that testing efforts are minimized and at the
same time coverage is also ensured. Using this technique, redundancy of test cases is
removed by eliminating data which does not produce different output.

For example, consider a very simple function for awarding grades to the students. This
program follow these guideline to award grades

Marks 00 - 39 ------------ Grade D

Marks 40 - 59 ------------ Grade C

Marks 60 - 70 ------------ Grade B

Marks 71 - 100 ------------ Grade A

Based on the equivalence partitioning techniques, partitions for this program could be as
follows

Marks between 0 to 39 - Valid Input

Marks between 40 to 59 - Valid Input

Marks between 60 to 70 - Valid Input

Marks between 71 to 100 - Valid Input

Marks less than 0 - Invalid Input

Marks more than 100 - Invalid Input

Non numeric input - Invalid Input

From the example above, it is clear that from infinite possible test cases (Any value
between 0 to 100, Infinite values for >100 , < 0 and non numeric) data can be divided
into seven distinct classes. Now even if you take only one data value from these
partitions, your coverage will be good.

Most important part in equivalence partitioning is to identify equivalence classes.
Identifying equivalence classes needs close examination of the possible input values.
Also, you can not rely on any one technique to ensure your testing is complete. You still
need to apply other techniques to find defects.

If you have used Equivalence Partitioning in some interesting way, why not share with
all?

Decision table

Decision tables are a precise yet compact way to model complicated logic. Decision
tables, like if-then-else and switch-case statements, associate conditions with actions to
perform. But, unlike the control structures found in traditional programming languages,
decision tables can associate many independent conditions with several actions in an
elegant way.

Structure

Decision tables are typically divided into four quadrants, as shown below.

                                   The four quadrants
                            Conditions Condition alternatives
                            Actions      Action entries

Each decision corresponds to a variable, relation or predicate whose possible values are
listed among the condition alternatives. Each action is a procedure or operation to
perform, and the entries specify whether (or in what order) the action is to be performed
for the set of condition alternatives the entry corresponds to. Many decision tables
include in their condition alternatives the don't care symbol, a hyphen. Using don't cares
can simplify decision tables, especially when a given condition has little influence on the
actions to be performed. In some cases, entire conditions thought to be important initially
are found to be irrelevant when none of the conditions influence which actions are
performed.

Aside from the basic four quadrant structure, decision tables vary widely in the way the
condition alternatives and action entries are represented. Some decision tables use simple
true/false values to represent the alternatives to a condition (akin to if-then-else), other
tables may use numbered alternatives (akin to switch-case), and some tables even use
fuzzy logic or probabilistic representations for condition alternatives. In a similar way,
action entries can simply represent whether an action is to be performed (check the
actions to perform), or in more advanced decision tables, the sequencing of actions to
perform (number the actions to perform).

Example
The limited-entry decision table is the simplest to describe. The condition alternatives are
simple boolean values, and the action entries are check-marks, representing which of the
actions in a given column are to be performed.

A technical support company writes a decision table to diagnose printer problems based
upon symptoms described to them over the phone from their clients.

                                 Printer troubleshooter
                                                                     Rules
                   Printer does not print                Y Y Y Y N N N N
      Conditions A red light is flashing                 Y Y N N Y Y N N
                   Printer is unrecognized               Y N Y N Y N Y N
                   Check the power cable                         X
                   Check the printer-computer cable      X       X
      Actions      Ensure printer software is installed X        X       X     X
                   Check/replace ink                     X X             X X
                   Check for paper jam                       X       X

Of course, this is just a simple example (and it does not necessarily correspond to the
reality of printer troubleshooting), but even so, it demonstrates how decision tables can
scale to several conditions with many possibilities.

Software engineering benefits
Decision tables make it easy to observe that all possible conditions are accounted for. In
the example above, every possible combination of the three conditions is given. In
decision tables, when conditions are omitted, it is obvious even at a glance that logic is
missing. Compare this to traditional control structures, where it is not easy to notice gaps
in program logic with a mere glance --- sometimes it is difficult to follow which
conditions correspond to which actions!

Just as decision tables make it easy to audit control logic, decision tables demand that a
programmer think of all possible conditions. With traditional control structures, it is easy
to forget about corner cases, especially when the else statement is optional. Since logic is
so important to programming, decision tables are an excellent tool for designing control
logic. In one incredible anecdote, after a failed 6 man-year attempt to describe program
logic for a file maintenance system using flow charts, four people solved the problem
using decision tables in just sixteen man-weeks .

				
DOCUMENT INFO