ISE (Diploma 4 th Computer

Engineering)
Unit :
4
Software Coding and
Testing
 4.4 Testing Fundamentals
 The basic goal of any software development is to produce software
that has no errors or has few errors.
 So, verification is performed at output of each phase, but some faults
are likely to remain undetected and they can affect the
whole software.
 Testing is relied on to detect these faults.

 If program fails to behave as expected, it needs to be debugged and

corrected. For that testing is done.
 Testing is the process of executing a program to locate an error.

19
 4.4 Testing Fundamentals
 Testing a program consists of providing the program with a set of
test inputs (or test cases) and observing if the program behaves
as expected.
 Aim of testing  to identify all defects existing in a software
product.

 A good test case is one that has a high probability of finding

undiscovered errors.

20
 4.4 Testing Fundamentals
❖ Some commonly used terms associated with testing
Kind of mistake, may be syntax error or logical
error

Representation of error

Error or fault that cause it to produce incorrect or

unexpected result

Failure occurs when fault executes, it is

demonstration of error

It is a deviation from actual and

expected result
21
 4.4 Testing Fundamentals
❖ Some other testing terms

 Test case
 It defines how to test a system.

 It verifies system’s functionalities.

 It is a triplet of [I, S, O].

 It is written by a tester or QA professionals.

 Test cases are run after the implementation of a software product to

confirm whether the product meets its software requirements.

 There are mainly two types of test cases  formal (inputs

are known) and informal (undefined inputs).
22
 4.4 Testing Fundamentals
 Test suit
 Created based on the scope of the project.

 The collection of test cases is referred as test suit.

 The collection of test suite is referred as test plan.

 Testing is four stage process. 23

 4.4 Testing Fundamentals
 Design of test cases
• Design optimal test suit that may cover maximum errors.

• Systematic approach should be followed to design optimal test cases.

• There are mainly two approaches
▪ Black box testing approach
▪ White box testing approach

24
 4.4 Testing Fundamentals
❖ Levels of testing

25
 4.4 Testing Fundamentals
❖ Verification
• It is the process of checking that a software achieves its goal without
any bugs.
• Checking whether the output of one phase in software development
meets with its previous phase.
• It is a kind of static testing.
• It comes before validation.
• At the time of verification, code execution does not happen.
• The cost of verification is less compare with validation.
• It is concerned with phase containment of errors.
• In one statement we can say  Verification is “Are we doing right?”

26
 4.4 Testing Fundamentals
❖ Validation
• It is the process of checking whether the software product is up to
the mark.
• It is determining whether fully developed system confirms to
its requirements specification.
• Validation is concerned with final product to be error free.
• It is dynamic testing.
• The cost of validation is more compare with verification.
• It comes after verification.
• At the time of verification, code execution may happen.
• In one statement we can say  Validation is “Have we done right?”
• Different activities in validation  Black box testing, white
box
testing, unit testing, integration testing. 27
4.4 Testing Fundamentals

28
 4.5 Black Box Testing
• It is also called functional testing or behavioural testing.
• Black box testing is a testing method where test cases
are designed using only the functional specification of the
software,
i.e. without any knowledge of the internal structure of
the software.

Users don’t know about the internal working of the system

29
 4.5 Black Box Testing
• User (Tester) don’t know the internal working of the system. He only
has access to the inputs and outputs of the system.
• Purpose  to test the functionalities of the system.
• It can be conducted manually or using automated tools.
• Example – Search engine.
 Synonyms of black box testing
– Close box testing
– Functional testing
– Behavioural testing
– Non-transparent testing
– Data driven testing

30
 4.5 Black Box Testing
 Types of black box testing
o Functional testing – determines the functional req. of the software
o Non-functional testing – focuses on software functionality, scalability,
performance etc.
o Regression testing – testing is applied to check the system in case of
change or upgrade.
 Black box testing techniques
✓ Equivalence partitioning (Equivalence Class Partitioning)
✓ Boundary Value Analysis (BVA)
✓ Decision table testing
✓ State transition testing
✓ Error guessing
✓ Graph based testing
✓ Comparison testing
31
 4.5 Black Box Testing
❖ Equivalence partitioning (OR Equivalence class partitioning)
• In it, domain of input values (input test data) partitioned into finite
number of equivalence classes.
• So, the behaviour of the program is similar for every input data
belonging to the same equivalence classes.
• The main idea behind defining the equivalence classes is that if one
test case in a class detects an error all other test cases in the
class would be expected to find same error.
 Two steps are required to implement this technique
I. Identify equivalence classes based on input conditions.
II. Generate test cases for the above identified classes.

32
 4.5 Black Box Testing

• The aim is to choose at lease one element from each equivalent class.
• Some general guidelines:
o If input data values specified by a range
o If input data values are set of discrete numbers
o If the input values are Boolean
• Example (Self explanatory)
33
 4.5 Black Box Testing
❖ Boundary Value Analysis (BVA)

 Generally, errors are occurred at boundary of domains rather than

centre of domain.
 This is because test cases closer to boundary have more chance to
detect errors.
• For this reason, boundary value analysis technique has
been developed.
34
 4.5 Black Box Testing
• In this technique, selection of test cases performed at the edges of
the class. Suppose we have an input variable x with a range from 1 to
100. The boundary values are: 1, 2, 99, 100.
• Consider a program with two input variables x and y. These input
variables have specified boundaries as:

• Both the inputs x and y are bounded by two intervals [a, b] and [c, d]
respectively. For input x, we may design test cases with values a
and b, just above a and also just below b. For input y, we may have
values c and d, just above c and just below d. These test cases
have more chance to detect an error. Like

35
 4.5 Black Box Testing

• Basic idea of BVA is to use input variables values at their minimum,

just above minimum, a nominal value, just below maximum and
at their maximum.
• Example: Generate test cases using BVA method for two input
variables X and Y that may have any values from 100 to 300.

36
 4.5 Black Box Testing
❖ Decision table testing
• It is also called cause-effect testing method.
• It is a way to test all the combinations of logic.
• This technique involves creating a table that represents all possible
combinations of inputs and expected outputs for a particular
feature or function.
• The tester can then test each combination to verify that the system
behaves correctly in all scenarios.
• In this testing, the inputs will be conditions and based on that the
expected result (action) is generated.
• In that testing, while creating a decision table,
Number of possible test cases = 2no. of conditions
37
 4.5 Black Box Testing
 Suppose we have a logical relationship like:

If (Condition = True)
{
then action1;
}
else action2; /* (Condition = False) */
• In above situation, a tester will identify two outputs (action1 and
action2) for two conditions (True and False). So based on
the probable scenarios a decision table is used to prepare a set
of test cases.
• Example: Consider an email system where user is providing his user-id
(email address) and password to login into the account. Generate
test cases using decision table testing.
38
 4.5 Black Box Testing
 Decision table for the given problem should be:

 While using the decision table technique, a tester determines the

expected output, if the function produces expected output, then it
is passed in testing, and if not then it is failed. Failed software is
sent back to the development team to fix the defect.

39
 4.5 Black Box Testing
❖ State transition testing
 This technique is used to test systems that have different states, such
as login screens, shopping carts, order status etc.
 The tester identifies the different states and then tests
the transitions between them to ensure that the system behaviour.
 In other words, tests are designed to execute valid and invalid state
transitions.
 This testing analysing the behaviour of system.
 It is mainly used for small applications where finite set of
input values.
 Example: Let’s consider an ATM system where if the user enters the
invalid password three times, the account will be blocked for a day.

40
 4.5 Black Box Testing
 The state transition diagram for the given system is:

 State transition table for the system is:

41
 4.5 Black Box Testing
❖ Error guessing
 In this technique prior experience in testing is used to uncover the
defects in software.
 It is an experience based technique in which the tester uses his/her
past experience or intuition to evaluate the problematic areas
of a software application.
 No specific method for identifying the error.
 The main purpose of this technique is to identify common errors at
any level of testing by exercising the following tasks:

✓ Enter the blank space into ✓ File upload with less or more than size
the text fields
✓ Null pointer exception ✓ File upload without attachment
✓ Enter invalid parameters ✓ Check buttons without entering values
✓ Divide by zero 42
 4.5 Black Box Testing
Example
A function of the application requires a mobile number which must
be of 10 digits. Now, below are the techniques that can be applied to
guess error in the mobile number field:
✓ What will be the result, if we provide input is other than a

✓ What will be the result, if entered digits which are less than 10 digits
number?

or greater than 10 digits?

✓ 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,
otherwise it is sent to the development team to fix the defects.

43
 4.5 Black Box Testing
❖ Graph based testing
 This technique uses graph to model and test the behaviour of the
system.
 In this technique, the software system is represented as a graph
where the nodes represent states or actions and the edges
represent the transitions between these states or actions.
 Goal  to check the system behaviour as expectations by using
various inputs and actions.
 Generally it is used for complex system with many states and
transitions.
 Steps to perform this technique:
I. Graph modeling III. Test case generation

II. Path selection IV. Test execution

44
 4.5 Black Box Testing
❖ Comparison testing
 In it, comparing the performance or behaviour of two or
more versions of the same software application.
 Goal  to identify differences between the versions and
to determine which version is better or have few errors.
 When to perform comparison testing
✓ Early stage of software development process
✓ Mid stage of the software development process
✓ Last stage of the software development process
 Testing criteria
✓ Compare software applications against known standards
✓ Compare software applications against specific features of other
existing software. 45
 4.5 Black Box Testing
❖ Advantages of black box testing
✓ No need to have detailed knowledge or internal working of the
system.
✓ Tester can be non-technical.
✓ Even an independent person who is not involved
in the development, can test the system. So, testing can be
outsourced.
✓ It is cost effective.
✓ Helps to identify errors quickly.
❖ Disadvantages of black box testing
✓ Doesn’t provide detailed explanation or internal structure.
✓ Time consuming process.
✓ Chance of ignoring the conditions that need to be tested. 46
 4.6 White Box Testing

Testers have to know the internal structure of the system

 White box testing is a software testing technique that involves testing

the internal workings of an application or system.
 In it, tester has the access to the source code. He is able to examine
the structure of the system.
 Aim  investigate the internal logic of the system.

47
 4.6 White Box Testing
 Some synonyms of white box testing method

 It is necessary for a tester to have a knowledge of source code.

Concept of Stronger and
Complimentary

48
 4.6 White Box Testing
 Static and dynamic white box testing.
 Example : Circuit testing
 Test case generated using white box testing can:
✓ Guarantee that all individual paths have been exercised at least
once.
✓ All decisions (TRUE or FLASE) are exercised.
✓ The internal data structure of the program is exercised.
A White box testing techniques

49
 4.6 White Box Testing
 Statement coverage
 Also called as line coverage or segment coverage
 In it, each line of code is tested to ensure that all the statements have
been executed at least once.
 Principal idea  unless a statement is executed, it is very hard to
determine if an error exists in that statement.
 Main advantages  measure the quality of the code.
 The statement coverage s calculated as:

50
4.6 White Box Testing

51
 4.6 White Box Testing
 Branch coverage
 A branch is a decision point in the code, such as an if-else statement
or a switch statement.
 Branch coverage testing involves executing the code with different
inputs and verifying that all the possible branches in the code.
 The test suit (collection of test cases) designed to exercise all the
possible branches in the code.
 Goal  to ensure that every possible branch is executed at least
once. Suppose if the outcomes are binary, you need to test both
True and False outcomes.
 The branch coverage is calculated as:

52
4.6 White Box Testing

53
 4.6 White Box Testing
 Condition coverage
 This testing technique ensures that all possible outcomes
of a Boolean expression (condition) are tested.
 Purpose  to cover all logical conditions in the code.
 For example, if we have condition “if (X && Y)”, in order to get valid
condition coverage, following test cases will be sufficient.
Test 1: X = TRUE and Y = TRUE
Test 2: X = TRUE and Y = FALSE
Test 3: X = FASLE and Y = TRUE
Test 4: X = FALSE and Y = FALSE

Note: 100% condition coverage does not guarantee 100% branch coverage

54
 4.6 White Box Testing
 Condition coverage alone is not sufficient to achieve complete testing
coverage, other testing techniques like branch coverage and
path coverage are also necessary to achieve testing coverage.
Example
int a = 10;
if (a > 0) {
p
r
i
n
t
f
(
“
a
i
s
P
o 55
s
 4.6 White Box Testing
 Path coverage
 A path is defined as a sequence of instructions that are executed
from the start of the program to its end.
 This testing ensure that all possible paths through a program or a
software system are tested at least once.
 It focuses on logical flow of the system.
 To achieve path coverage, the tester needs to create test cases that
execute every possible path through the code, including
loops, branches, and conditional statements.
 Limitation of this technique  time consuming
 Creating and executing tests for all possible paths results in
100% statement coverage and 100% branch coverage.

56
 4.6 White Box Testing
 Example

int test (int X, int Y) {

int Z;
if (X > 0) {
Z = Y + 1;
}
else {
Z = Y -1;
}
return Z;
}

 To achieve the path coverage in above code, the tester needs

to create test cases that exercise both the paths.
 Sample test cases are: (5, 5) and (-5, 5)
57
 4.6 White Box Testing
 Data flow testing
 It examines the flow of data with respect to variables.
 It examines the initialization of variables and checks their values at
each instance.
 In simple terms  this testing technique relies on two things: where
the variables are defined and where these variables are used.
 Twp types of data flow testing:
✓ Static data flow testing
✓ Dynamic data flow testing
 Anomalies in data flow can be detected by:
✓ When variables are used without initialization
✓ If the initialized variables are not used at least once
✓ If a variable declared multiple times
58
 4.6 White Box Testing
 In this testing, the test cases are designed around variable definitions
and its usage.
 Example

In this code, we can see there are 6

statements and there are 5 different
variables (i.e., a, b, c, x, z). Now using data
flow testing we can trace the definition and
usage of variables used in the code.

Using above table, we can get the idea, in

our code some variables are defined but not
used, some variables are used not defined
and some are defined multiple times.

59
 4.6 White Box Testing
 Mutation testing
 In it, testers change specific components of source code to ensure a
software test suit will be able to detect changes.
 Goal  to test the quality of the test suit.
 There can be statement mutation, value mutation, decision mutation.
 Generally, it can be used in unit testing.

 Process of mutation testing

60
 4.6 White Box Testing
 Advantages of white box testing
✓ Product quality is improved.
✓ More effective test cases can be generated.
✓ Provide greater coverage of source code.
✓ Encourage developers to write better code.
 Disadvantages of white box testing
✓ Time consuming process.
✓ It requires professional resources.
✓ Cost is high.
✓ In depth knowledge is required in programming to
perform this testing.
✓ Limited relevance to end-users.
61
 4.6 White Box Testing
❖ Difference between Black box testing and White box testing

62