Unit-2: Methods of Testing
1. Software Verification and Validation, Black-Box
and White-Box Testing, Static and Dynamic Testing.
2. Black-Box Testing Techniques-Equivalence
Partitioning, Data Testing, State Testing, Other Black
Box Test Techniques.
3. White-Box Testing Techniques-Data Coverage,
Code Coverage, Other White Box Test Techniques.
Software Verification and Validation
• Black-Box and White-Box Testing
• Black Box Testing :
• BBT is a software testing method in which the
internal structure /design /implementation of the
item being tested is not known to the tester.
• Only the external design and structure are tested.
• White Box Testing :-
• WBT is a software testing method in which the
internal structure/design/implementation of the
item being tested is known to the tester.
• Implementation and impact of the code are
tested.
Static and Dynamic Testing
• Static Testing is a type of a Software Testing
method which is performed to check the defects in
software without actually executing the code of the
software application.
• Static testing is performed in early stage of
development to avoid errors as it is easier to find
sources of failures and it can be fixed easily.
• Dynamic Testing:
Dynamic Testing is a type of Software Testing
which is performed to analyze the dynamic
behavior of the code.
It includes the testing of the software for the
input values and output values that are analyzed.
[Link]-Box Testing Techniques-
Equivalence Partitioning, Data Testing,
State Testing, Other Black Box Test
Techniques.
Black-Box Testing Techniques
• Equivalence Partitioning - A Black Box Testing
Technique
• The equivalence partitions are derived from
requirements and specifications of the software.
• The advantage of this approach is, it helps to reduce
the time of testing due to a smaller number of test
cases from infinite to finite.
• It is applicable at all levels of the testing process.
• How to do Equivalence Partitioning?
• Consider that you are filling an online application form
for a gym membership.
• What are the most important criteria for getting a
membership? Of course, the age! Most of the gyms
have age criteria of 16-60.
• If you look at below membership form, you will need
to fill age first. After that, depending on whether you
are between 16-60, you can go further.
• Otherwise, you will get a message that you cannot get
a membership.
• If we have to test this age field, the common sense tells us that we need
to test the values between 16-60, and values which are less than 16,
and some values which are more than 60.
• It is easy to figure out, but how many combinations we need to test to
say that the functionality works safely?
• <16 has 15 combinations from 0-15, and if you test negative values,
then some more combination can be added.
• 16-60 has 45 combinations
• >60 has 40 combinations (if you only take till 100)
• Should we test all these 100+ combinations? Surely! If we had all the
time in the world, and the cost was not an issue at all. Practically we
can never do that because there is minimal time for testing.
• Additionally, we need to ensure that we create
minimal test cases with maximum test coverage. It
is where this testing techniques come into the
picture. Let's see how Equivalence Partitioning
will solve this problem.
• The First step in Equivalence partitioning is to
divide (partition) the input values into sets of
valid and invalid partitions.
• Continuing the same example our partition will
look like below –
• Valid Partitions are values that should be accepted by the system
under test. This partition is called "Valid Equivalence
Partition.“
• Invalid Partitions are values that should be rejected by the
system under test. This partition is called "Invalid Equivalence
Partition.“
• So what should we do after knowing these partitions? The
premise of this technique works on the assumption that all values
within the partition will behave the same way. So all values from
16-60 will behave the same way. The same goes for any value
less than 16 and values greater than 60.
• As such, we only test 1 condition within each partition and
assume that if it works/doesn't work, the rest of the condition
• Our Test conditions in Such case could be:
• Enter Age = 5
• Enter Age = 20
• Enter Age = 65
• These 3 test conditions will cover the 100+
conditions.
• By applying this technique, we have significantly
reduced our test cases, but yet the coverage remains
high.
• Boundary Value Analysis
• We already know that Black box testing involves validating the
system without knowing its internal design.
• Equivalence partitioning has some dis-advantages and it can
fail at partition boundaries.
• The basis of Boundary Value Analysis (BVA) is testing the
boundaries at partitions .
• BVA is an extension of equivalence partitioning. However,
this is useable only when the partition is ordered, consisting of
numeric or sequential data.
• The minimum and maximum values of a partition are its
boundary values.
• We have seen that there are high chances of finding the
defects at the boundaries of a partition (E.g., A developer
using >10 instead of >= 10 for a condition).
• Equivalence partitioning alone was not sufficient to catch
such defects. Therefore, a need to define a new technique
that can detect anomalies at the boundaries of the partition .
It is how Boundary value analysis came into the picture.
• Boundary value analysis can perform at all test levels, and
its primarily used for a range of numbers, dates, and time.
• How to Do Boundary Value Analysis?
• We will refer to the example of gym form ,where
we need to enter Age.
• The first step of Boundary value analysis is to create
Equivalence Partitioning, which would look like
below
• Now Concentrate on the Valid Partition, which
ranges from 16-60. We have a 3 step approach to
identify boundaries:
[Link] Exact Boundary Value of this partition
Class - which is 16 and 60.
[Link] the Boundary value which is one less than the
exact Boundary - which is 15 and 59.
[Link] the Boundary Value which is one more than the
precise Boundary - which is 17 and 61 .
• If we combine them all, we will get below
combinations for Boundary Value for the Age
Criteria.
• Valid Boundary Conditions : Age = 16, 17, 59, 60
• Invalid Boundary Conditions : Age = 15 61
• It's straightforward to see that valid boundary
conditions fall under Valid partition class, and
invalid boundary conditions fall under Invalid
partition class.
• Pitfalls ( Dis-advantages) of BVA
• After applying both boundary value and Equivalence
partitioning, can we confidently say that we got all the
required coverage? Unfortunately, it's not that simple!
• Boundary value and equivalence partitioning assume
that the application will not allow you to enter any other
characters or values. Such characters, like @ or
negative values or even alphabets, will not be allowed
to enter.
• This assumption is however not valid for all
applications, and it's essential to test these out before we
can say that the field value is completely working.
• Apart from that, we can have situations where
the input value depends on the decision of
another value.
• E.g., If the Gym form has another field Male
and Female, and the age limit will vary
according to that selection.
• Boundary value alone cannot handle such
variations, and this leads us to another black box
technique called Decision Table Testing.
Error Guessing
• Error guessing is a technique in which there is no
specific method for identifying the error.
• It is based on the experience of the test analyst,
where the tester uses the experience to guess the
problematic areas of the software.
• It is a type of black box testing technique which
does not have any defined structure to find the
error.
• In this approach, every test engineer will derive
the values or inputs based on their understanding
or assumption of the requirements, and we do not
follow any kind of rules to perform error guessing
technique.
• The accomplishment of the error guessing
technique is dependent on the ability and product
knowledge of the tester because a good test
engineer knows where the bugs are most likely to
be, which helps to save lots of time.
• It requires only well-experienced testers with quick
error guessing technique.
• The main purpose of this technique is to identify
common errors at any level of testing by exercising
the following tasks:
1. Enter blank space into the text fields.
2. Null pointer exception.
3. Enter invalid parameters.
4. Divide by zero.
5. Use maximum limit of files to be uploaded.
6. Check buttons without entering values.
• Example1
• A function of the application requires a mobile
number which must be of 10 characters. Now,
below are the techniques that can be applied to
guess error in the mobile number field:
1. What will be the result, if the entered character is
other than a number?
2. What will be the result, if entered characters are
less than 10 digits?
3. What will be the result, if the mobile field is left
blank?
• After implementing these techniques, if the output
is similar to the expected result, the function is
considered to be bug-free, but if the output is not
similar to the expected result, so it is sent to the
development team to fix the defects.
• However, error guessing is the key technique
among all testing techniques as it depends on the
experience of a tester, but it does not give surety of
highest quality benchmark.
• It does not provide full coverage to the software.
This technique can yield a better result if combined
Decision table technique in BBT
• Decision table technique is a systematic approach
where various input combinations and their respective
system behavior are captured in a tabular form.
• That's why it is also known as a cause-effect table. This
technique is used to pick the test cases in a systematic
manner, it saves the testing time and gives good
coverage to the testing area of the software application.
• Decision table technique is appropriate for the
functions that have a logical relationship between two
and more than two inputs.
• To design the test cases by decision table
technique, we need to consider conditions as input
and actions as output.
• Example:- Most of us use an email account, and
when you want to use an email account, for this
you need to enter the email and its associated
password.
• If both email and password are correctly matched,
the user will be directed to the email account's
homepage; otherwise, it will come back to the
login page with an error message specified with
"Incorrect Email" or "Incorrect Password."
• Now, let's see how a decision table is created for
the login function in which we can log in by using
email and password. Both the email and the
password are the conditions, and the expected
result is action.
• In the table, there are four conditions or test cases to test the login
function.
1. In the first condition if both email and password are correct, then the
user should be directed to account's Homepage.
2. In the second condition if the email is correct, but the password is
incorrect then the function should display Incorrect Password.
3. In the third condition if the email is incorrect, but the password is
correct, then it should display Incorrect Email.
4. Now, in fourth and last condition both email and password are incorrect
then the function should display Incorrect Email.
• In this example, all possible conditions or test cases have been included,
and in the same way, the testing team also includes all possible test cases
so that upcoming bugs can be cured at testing level.
State Transition Black Box Testing
• State Transition Testing is basically a black box
testing technique that is carried out to observe the
behavior of the system or application for
different input conditions passed in a sequence.
• In this type of testing, both positive and negative
input values are provided and the behavior of the
system is observed.
• State Transition Testing Technique is helpful
where you need to test different system
transitions.
• When to Use State Transition?
• This can be used when a tester is testing the
application for a finite set of input values.
• When the tester is trying to test sequence of events
that occur in the application under test. I.e., this
will allow the tester to test the application behavior
for a sequence of input values.
• When the system under test has a dependency on
the events/values in the past.
• Four Parts Of State Transition Diagram
1) States that the software might get
2) Transition from one state to another
3) Events that origin a transition like closing a file
or withdrawing money
4) Actions that result from a transition (an error
message or being given the cash.)
• Example 1:
• Let’s consider an ATM system function where if the
user enters the invalid password three times the
account will be locked.
• In this system, if the user enters a valid password in
any of the first three attempts the user will be logged
in successfully.
• If the user enters the invalid password in the first or
second try, the user will be asked to re-enter the
password. And finally, if the user enters incorrect
password 3rd time, the account will be blocked.
• State transition diagram
• In the diagram whenever the user enters the correct PIN he is
moved to Access granted state, and if he enters the wrong
password he is moved to next try and if he does the same for the
3rd time the account blocked state is reached.
3. White-Box Testing Techniques-Data
Coverage, Code Coverage, Other
White Box Test Techniques.
• 3 Main White Box Testing Techniques:
• Statement Coverage
• Branch Coverage
• Path Coverage
1) Statement coverage:
• In a programming language, a statement is nothing but
the line of code or instruction for the computer to
understand and act accordingly.
• A statement becomes an executable statement when it
gets compiled and converted into the object code and
performs the action when the program is in a running
mode.
• Hence “Statement Coverage”, as the name itself
suggests, it is the method of validating whether each
and every line of the code is executed at least once.
• Statement coverage is a white box testing technique
that ensures all executable statements in the code
are run and tested at least once.
• For example, if there are several conditions in a
block of code, each of which is used for a certain
range of inputs, the test should execute each and
every range of inputs, to ensure all lines of code are
actually executed.
2) Branch Coverage:
• “Branch” in a programming language is like the “IF
statements”. An IF statement has two branches: True
and False.
• So in Branch coverage (also called Decision coverage),
we validate whether each branch is executed at least
once.
• In case of an “IF statement”, there will be two test
conditions:
• One to validate the true branch and,
• Other to validate the false branch.
• Hence, Branch Coverage is a testing method which is
when executed ensures that each and every branch from
each decision point is executed.
• Branch coverage maps the code into branches of conditional logic,
and ensures that each and every branch is covered by unit tests. For
example, if there are several nested conditional statements:
• A, C, and D are conditional branches, because they occur only if a
condition is satisfied. B is an unconditional branch, because it is
always executed after A. In a branch coverage approach, the tester
identifies all conditional and unconditional branches and writes code
to execute as many branches as possible.
3) Path Coverage
• Path coverage tests all the paths of the
program.
• This is a comprehensive technique which
ensures that all the paths of the program are
traversed at least once.
• Path Coverage is even more powerful than
Branch coverage.
• This technique is useful for testing the
complex programs.
• Let’s take a simple example to understand all these
white box testing techniques.
• Consider the below simple code:
INPUT A & B
C=A+B
IF C>100
PRINT “ITS DONE”
• For Statement Coverage – we would only need one test case
to check all the lines of the code.
• That means:
• If I consider TestCase_01 to be (A=40 and B=70), then all
the lines of code will be executed.
• Now the question arises:
• Is that sufficient?
• What if I consider my Test case as A=33 and B=45?
• Because Statement coverage will only cover the true side,
for the code, only one test case would NOT be sufficient to
test it. As a tester, we have to consider the negative cases as
well.
• Hence for maximum coverage, we need to
consider “Branch Coverage”, which will evaluate the
• So now the code becomes:
INPUT A & B
C=A+B
IF C>100
PRINT “ITS DONE”
ELSE
PRINT “ITS PENDING”
• Since Statement coverage is not sufficient to test the
entire code, we would require Branch coverage to
ensure maximum coverage.
• So for Branch coverage, we would require two test
cases to complete the testing of this code.
• TestCase_01: A=33, B=45
• TestCase_02: A=25, B=30
• With this, we can see that each and every line of the
code is executed at least once.
• Here are the Conclusions that are derived
so far:
• Branch Coverage ensures more coverage than
Statement coverage.
• Branch coverage is more powerful than
Statement coverage.
• 100% Branch coverage itself means 100%
statement coverage.
• But 100 % statement coverage does not
guarantee 100% branch coverage.
• Path coverage is used to test the complex code,
which basically involve loop statements or
combination of loops and decision statements.
• Consider this code:
INPUT A & B
C=A+B
IF C>100
PRINT “ITS DONE”
END IF
IF A>50
PRINT “ITS PENDING”
END IF
• Now to ensure maximum coverage, we would
require 4 test cases.
• How? Simply – there are 2 decision statements, so
for each decision statement, we would need two
branches to test.
• One for true and the other for the false condition.
So for 2 decision statements, we would require 2
test cases to test the true side and 2 test cases to test
the false side, which makes a total of 4 test cases.
In order to have the full coverage, we would need
following test cases:
• TestCase_01: A=50, B=60
• TestCase_02: A=55, B=40
• TestCase_03: A=40, B=65
• TestCase_04: A=30, B=30
So the path covered will be:
• Red Line – TestCase_01 = (A=50, B=60)
• Blue Line = TestCase_02 = (A=55, B=40)
• Orange Line = TestCase_03 = (A=40, B=65)
• Green Line = TestCase_04 = (A=30, B=30)