Software Engineering

Unit – IV

Software Testing Strategies

Dr. S. Manikandan
HOD-IT

1
 1. Introduction to Software Testing

• Software Testing is a method to check whether the actual

software product matches expected requirements and to
ensure that software product is defect free
• Software testing is a procedure of implementing software
or the application to identify the defects or bugs.

2
2. Software Testing Life Cycle (STLC)

3
• Requirement Analysis:
In this phase, tester analyses requirement document of
SDLC (Software Development Life Cycle) to examine
requirements stated by the client. After examining the
requirements, the tester makes a test plan to check whether
the software is meeting the requirements or not.
• Test Plan Creation:
Here all the testing strategies are defined. Tester determines
the estimated effort and cost of the entire project. Testing
strategy and effort estimation documents provided by this
phase. Test case execution can be started after the
successful completion of Test Plan Creation.

4
• Environment setup:
Setup of the test environment is an independent activity and
can be started along with Test Case Development.
Environment setup requires a group of essential software
and hardware to create a test environment. The testing team
is not involved in setting up the testing environment, its
senior developers who create it.
• Test case Execution:
Test case Execution takes place after the successful
completion of test planning. In this phase, the testing team
starts case development and execution activity. The testing
team writes down the detailed test cases, also prepares the
test data if required. The prepared test cases are reviewed
by peer members of the team or Quality Assurance leader.
5
• Defect Logging:
Testers and developers evaluate the completion criteria of
the software based on test coverage, quality, time
consumption, cost, and critical business objectives. This
phase determines the characteristics and drawbacks of the
software. Test cases and bug reports are analyzed in depth
to detect the type of defect and its severity.
• Test Cycle Closure:
The test cycle closure report includes all the documentation
related to software design, development, testing results, and
defect reports.

6
 3. Strategic Approach to Software Testing

Following are the characteristic that process the

testing templates:
• The developer should conduct the successful technical
reviews to perform the testing successful.
• Testing starts with the component level and work from
outside toward the integration of the whole computer
based system.
• Different testing techniques are suitable at different point
in time.
• Testing is organized by the developer of the software
and by an independent test group.
• Debugging and testing are different activities, then also
the debugging should be accommodated in any strategy
of testing.
7
 Verification Validation
Verification is the process to find whether The validation process is checked whether
the software meets the specified the software meets requirements and
requirements for particular phase. expectation of the customer.
It estimates an intermediate product. It estimates the final product.
The objectives of verification is to check The objectives of the validation is to check
whether software is constructed according whether the specifications are correct and
to requirement and design specification. satisfy the business need.
It describes whether the outputs are as per It explains whether they are accepted by
the inputs or not. the user or not.
Verification is done before the validation. It is done after the verification.
Plans, requirement, specification, code are Actual product or software is tested under
evaluated during the verifications. validation.
It manually checks the files and document. It is a computer software or developed
program based checking of files and
document.

8
9
• As per the procedural point of view the testing includes
following steps.

1) Unit testing
2) Integration testing
3) High-order tests
4) Validation testing

10
 4. Strategic Issues
Following are the issues considered to implement
software testing strategies.
• Specify the requirement before testing starts in a
quantifiable manner.
• According to the categories of the user generate profiles
for each category of user.
• Produce a robust software and it's designed to test itself.
• Should use the Formal Technical Reviews (FTR) for the
effective testing.
• To access the test strategy and test cases FTR should be
conducted.
• To improve the quality level of testing generate test plans
from the users feedback.

11
 5. Test Strategies for Conventional Software

Following are the four strategies for conventional

software:
1) Unit testing
2) Integration testing
3) Regression testing
4) Smoke testing

12
6. Unit Testing

13
 7. Integration Testing

• There are two approaches of incremental testing are:

i) Non incremental integration testing
ii) Incremental integration testing
i) Non incremental integration testing
• Combines all the components in advanced.
• A set of error is occurred then the correction is difficult
because isolation cause is complex.
ii) Incremental integration testing
• The programs are built and tested in small increments.
• The errors are easier to correct and isolate.
• Interfaces are fully tested and applied for a systematic
test approach to it.

14
 Regression and Smoke Testing

Regression testing Smoke testing

Regression testing is used to check At the time of developing a software
defects generated to other modules by product smoke testing is used.
making the changes in existing programs.
In regression tested components are It permit the software development team to
tested again to verify the errors. test projects on a regular basis.
Regression testing needs extra manpower Smoke testing does not need an extra
because the cost of the project increases. manpower because it does not affect the
cost of project.
Testers conduct the regression testing. Developer conducts smoke testing just
before releasing the product.

15
 8. System Testing

• System testing is known as the testing behavior of the

system or software according to the software
requirement specification.
• It is a series of various tests.
• It allows to test, verify and validate the business
requirement and application architecture.
• The primary motive of the tests is entirely to test the
computer-based system.

16
 Following are the system tests for software-
based system

1. Recovery testing To check the recovery of the

software, force the software to fail in various ways.
Reinitialization, check pointing mechanism, data
recovery and restart are evaluated correctness.
2. Security testing It checks the system protection
mechanism and secure improper penetration.
3. Stress testing System executes in a way which
demands resources in abnormal quantity, frequency.
A variation of stress testing is known as sensitivity
testing.

17
4. Performance testing
• Performance testing is designed to test run-time
performance of the system in the context of an
integrated system.
• It always combines with the stress testing and needs
both hardware and software requirements.
5. Deployment testing
• It is also known as configuration testing.
• The software works in each environment in which it is
to be operated.

18
 9. The Art of Debugging

Debugging process
• Debugging process is not a testing process, but it is the
result of testing.
• This process starts with the test cases.
• The debugging process gives two results, i.e the cause
is found and corrected second is the cause is not
found.

19
20
 The debugging strategies
1. Brute force
• Brute force is commonly used and least efficient
method for separating the cause of software error.
• This method is applied when all else fails.
2. Backtracking
• Backtracking is successfully used in small programs.
• The source code is traced manually till the cause is
found.
3. Cause elimination
• Cause elimination establishes the concept of binary
partitioning.
• It indicates the use of induction or deduction.
• The data related to the error occurrence is arranged in
separate potential cause. 21
 10. Conventional Applications
Testability
• Software testability is simply how easily [a computer
program] can be tested.
The following characteristics lead to testable software.
• Operability—it operates cleanly
• Observability—the results of each test case are readily
observed
• Controllability—the degree to which testing can be
automated and optimized
• Decomposability—testing can be targeted
• Simplicity—reduce complex architecture and logic to
simplify tests
• Stability—few changes are requested during testing
• Understandability—of the design 22
What is a “Good” Test?
The following are the attributes of a “good” test:
• A good test has a high probability of finding an
error
• A good test is not redundant
• .A good test should be “best of breed”
• A good test should be neither too simple nor too
complex

23
 Internal and External Views of Testing

• Any engineered product (and most other things) can

be tested in one of two ways:
• Knowing the specified function that a product has been
designed to perform, tests can be conducted that
demonstrate each function is fully operational while at
the same time searching for errors in each function;
This approach takes an external view and is called
black-box testing.
• Knowing the internal workings of a product, tests can
be conducted to ensure that "all gears mesh," that is,
internal operations are performed according to
specifications and all internal components have been
adequately exercised. This approach requires an
internal view and is termed white-box testing.
24
 11. Basis path Testing

• Basis Path Testing is a white-box testing technique

based on the control structure of a program or a
module. Using this structure, a control flow graph is
prepared and the various possible paths present in the
graph are executed as a part of testing. Therefore, by
definition,
• Basis path testing is a technique of selecting the paths
in the control flow graph, that provide a basis set of
execution paths through the program or module.
• Since this testing is based on the control structure of
the program, it requires complete knowledge of the
program’s structure.

25
To design test cases using this technique,
four steps are followed :
• Construct the Control Flow Graph
• Compute the Cyclomatic Complexity of
the Graph
• Identify the Independent Paths
• Design Test cases from Independent
Paths

26
1. Control Flow Graph –
A control flow graph (or simply, flow graph) is a
directed graph which represents the control structure of
a program or module. A control flow graph (V, E) has V
number of nodes/vertices and E number of edges in it.
A control graph can also have :
• Junction Node – a node with more than one arrow
entering it.
• Decision Node – a node with more then one arrow
leaving it.
• Region – area bounded by edges and nodes (area
outside the graph is also counted as a region.).
• 27
28
Flow Graph Notation

29
2. Cyclomatic Complexity

The cyclomatic complexity V(G) is said to be a measure

of the logical complexity of a program. It can be
calculated using three different formulae :
• Formula based on edges and nodes :
• V(G) = e - n + 2*P Where,
e is number of edges,
n is number of vertices,
P is number of connected components.
• For example, consider first graph given above,
• where, e = 4, n = 4 and p = 1
• So, Cyclomatic complexity V(G) = 4 - 4 + 2 * 1 = 2

30
 3. Independent Paths
An independent path in the control flow graph is the one which
introduces at least one new edge that has not been
traversed before the path is defined.
The cyclomatic complexity gives the number of independent
paths present in a flow graph. This is because the
cyclomatic complexity is used as an upper-bound for the
number of tests that should be executed in order to make
sure that all the statements in the program have been
executed at least once.
• Consider first graph given above here the independent
paths would be 2 because number of independent paths is
equal to the cyclomatic complexity.
So, the independent paths in above first given graph :
• Path 1:A -> B
• Path 2:C -> D 31
4. Design Test Cases :
Finally, after obtaining the independent paths, test
cases can be designed where each test case
represents one or more independent paths.

32
 12. Control Structure Testing

• Control structure testing is used to increase the

coverage area by testing various control structures
present in the program. The different types of testing
performed under control structure testing are as
follows-
• 1. Condition Testing
• 2. Data Flow Testing
• 3. Loop Testing

33
1. Condition Testing :
• Condition testing is a test cased design method,
which ensures that the logical condition and
decision statements are free from errors.
• The errors present in logical conditions can be
incorrect boolean operators, missing parenthesis in
a booleans expression, error in relational operators,
arithmetic expressions, and so on.
2. Data Flow Testing :
The data flow test method chooses the test path of
a program based on the locations of the definitions
and uses all the variables in the program.

34
3. Loop Testing

• Loop testing is actually a white box testing technique. It

specifically focuses on the validity of loop construction.
Following are the types of loops.
• Simple Loop – The following set of test can be applied
to simple loops, where the maximum allowable number
through the loop is n.
– Skip the entire loop.
– Traverse the loop only once.
– Traverse the loop two times.
– Make p passes through the loop where p<n.
– Traverse the loop n-1, n, n+1 times.

35
36
• Concatenated Loops – If loops are not dependent on
each other, contact loops can be tested using the
approach used in simple loops. if the loops are
interdependent, the steps are followed in nested loops.

37
• Nested Loops – Loops within loops are called as
nested loops. when testing nested loops, the number of
tested increases as level nesting increases.
The following steps for testing nested loops are as
follows-
– Start with inner loop. set all other loops to minimum
values.
– Conduct simple loop testing on inner loop.
– Work outwards.
– Continue until all loops tested.

38
• Unstructured loops – This type of loops should be
redesigned, whenever possible, to reflect the use of
unstructured the structured programming constructs.

39
 13. Black Box Testing

• Black box testing is a technique of software testing

which examines the functionality of software without
peering into its internal structure or coding. The
primary source of black box testing is a specification of
requirements that is stated by the customer.
• In this method, tester selects a function and gives input
value to examine its functionality, and checks whether
the function is giving expected output or not. If the
function produces correct output, then it is passed in
testing, otherwise failed. The test team reports the
result to the development team and then tests the next
function. After completing testing of all functions if
there are severe problems, then it is given back to the
development team for correction.
40
 Generic steps of black box testing
• The black box test is based on the specification of
requirements, so it is examined in the beginning.
• In the second step, the tester creates a positive test
scenario and an adverse test scenario by selecting valid
and invalid input values to check that the software is
processing them correctly or incorrectly.
• In the third step, the tester develops various test cases
such as decision table, all pairs test, equivalent division,
error estimation, cause-effect graph, etc.
• The fourth phase includes the execution of all test cases.
• In the fifth step, the tester compares the expected output
against the actual output.
• In the sixth and final step, if there is any flaw in the
software, then it is cured and tested again.
41
 Techniques Used in Black Box Testing

Decision Table Decision Table Technique is a systematic approach

Technique where various input combinations and their respective
system behavior are captured in a tabular form. It is
appropriate for the functions that have a logical
relationship between two and more than two inputs.
Boundary Value Boundary Value Technique is used to test boundary
Technique values, boundary values are those that contain the
upper and lower limit of a variable. It tests, while
entering boundary value whether the software is
producing correct output or not.
State Transition State Transition Technique is used to capture the
Technique behavior of the software application when different
input values are given to the same function. This
applies to those types of applications that provide the
specific number of attempts to access the application.
All-pair Testing All-pair testing Technique is used to test all the possible
Technique discrete combinations of values. This combinational
method is used for testing the application that uses
checkbox input, radio button input, list box, text box,
etc.
42
Cause-Effect Technique Cause-Effect Technique underlines the relationship
between a given result and all the factors affecting the
result. It is based on a collection of requirements.
Equivalence Partitioning Equivalence partitioning is a technique of software
Technique testing in which input data divided into partitions of valid
and invalid values, and it is mandatory that all partitions
must exhibit the same behavior.
Error Guessing Error guessing is a technique in which there is no
Technique 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.
Use Case Technique Use case Technique used to identify the test cases
from the beginning to the end of the system as per the
usage of the system. By using this technique, the test
team creates a test scenario that can exercise the
entire software based on the functionality of each
function from start to end.

43
 14. White Box Testing

• It tests internal coding and infrastructure of a software

focus on checking of predefined inputs against
expected and desired outputs.
• It is based on inner workings of an application and
revolves around internal structure testing. In this type of
testing programming skills are required to design test
cases.
• The primary goal of white box testing is to focus on the
flow of inputs and outputs through the software and
strengthening the security of the software.

44
The white box testing contains various tests, which are
as follows:
• Path testing
• Loop testing
• Condition testing
• Testing based on the memory perspective
• Test performance of the program

45
Path testing
• In the path testing, we will write the flow graphs and
test all independent paths. Here writing the flow graph
implies that flow graphs are representing the flow of
the program and also show how every program is
added with one another
Loop testing
• In the loop testing, we will test the loops such as while,
for, and do-while, etc. and also check for ending
condition if working correctly and if the size of the
conditions is enough.

46
Condition testing
• In this, we will test all logical conditions for
both true and false values; that is, we will verify for
both if and else condition.
Testing based on the memory (size) perspective
• The size of the code is increasing for the following reasons:
• The reuse of code is not there:
• The developers use the logic that might be modified. If
one programmer writes code and the file size is up to 250kb,
then another programmer could write a similar code using
the different logic, and the file size is up to 100kb.
• The developer declares so many functions and
variables that might never be used in any portion of the
code. Therefore, the size of the program will increase.
47
Test the performance (Speed, response time) of the
program
• The application could be slow for the following reasons:
• When logic is used.
• For the conditional cases, we will
use or & and adequately.
• Switch case, which means we cannot use nested if,
instead of using a switch case.

48
 15. Model Based Testing

• Model-based testing is a software testing technique

where the run time behavior of the software under test
is checked against predictions made by a model.
• A model is a description of a system’s behavior.
Behavior can be described in terms of input
sequences, actions, conditions, output, and flow of data
from input to output.
• It should be practically understandable and can be
reusable; shareable must have a precise description of
the system under test.

49
 16. Testing Object Oriented Applications

• The whole object oriented testing revolves around the

fundamental entity known as “class”.
• With the help of “class” concept, larger systems can be
divided into small well defined units which may then be
implemented separately.
• The object oriented testing can be classified as like
conventional systems. These are called as the levels
for testing.

50
51
Object- Oriented Testing Strategy
• Unit Testing in the OO Context Each class and each
instance of a class packages attributes and operations that
manipulate these data. Because a class can contain a
number of different operations, and a particular operation
may exist as a part of a number of different classes, the
operation is not tested in isolation but rather as a part of a
number of different classes.

52
• Integration Testing in the OO Context There are two different
strategies for integration testing of OO systems :
• 1)Thread-based testing : integrates the set of classes
required to respond to one input or event for the system.
Each thread is integrated and tested individually. Regression
testing is applied to ensure that no side effects occur.
• 2)Use-based testing : begins the construction of the system
by testing those classes that use very few server classes.
After independent classes are tested, dependent classes are
tested.
• 3)Cluster Testing : A cluster of collaborating classes is
exercised by designing test cases that attempt to uncover
errors in the collaboration.
53
• Validation Testing in the OO Context The validation of
OO software focuses on user- visible actions and user-
recognizable outputs from the system. To assist in the
derivation of validation tests, the tester should draw
upon use cases that are part of the requirement model.
Conventional black box testing methods can be used to
derive validation tests.

54