Unit - 3

TEST DESIGN AND EXECUTION

 TEST OBJECTIVE IDENTIFICATION
The major objectives of Software testing are as follows:
• Finding defects which may get created by the programmer
while developing the software.
• Gaining confidence in and providing information about the
level of quality.
• To prevent defects.
• To make sure that the end result meets the business and user
requirements.
• To ensure that it satisfies the BRS that is Business
Requirement Specification and SRS that is System
Requirement Specifications.
• To gain the confidence of the customers by providing them a
 TEST DESIGN FACTORS
Test Design Factors
For designing Test Cases the following factors are
considered:
1. Correctness
2. Negative
3. User Interface
4. Usability
5. Performance
6. Security
7. Integration
8. Reliability
1. Correctness : Correctness is the minimum requirement of software,
the essential purpose of testing.
2. Negative : In this factor we can check what the product it is not
supposed to do.
3. User Interface : In UI testing we check the user interfaces.
4. Usability : Usability testing measures the suitability of the software
for its users
• Effectiveness : The capability of the software product to enable
users to achieve specified goals with the accuracy and completeness
in a specified context of use.
• Efficiency : The capability of the product to enable users to expend
appropriate amounts of resources in relation to the effectiveness
achieved in a specified context of use.
5. Performance : In software engineering, performance testing is
testing that is performed from one perspective to determine how
fast some aspect of a system performs under a particular workload.
• Load Testing: A load test is usually conducted to understand the
behavior of the application under a specific expected load.
• Stress Testing: Stress testing focuses on the ability of a system to
handle loads beyond maximum capacity
• Volume Testing: Volume testing refers to testing a software
application for a certain data volume.
6. Security : Process to determine that an Information System protects
data and maintains functionality as intended.
• Confidentiality : A security measure which protects against the
disclosure of information to parties other than the intended recipient
that is by no means the only way of ensuring
• Integrity: A measure intended to allow the receiver to determine that
the information which it receives has not been altered in transit other
than by the originator of the information.
• Authentication: Allows a receiver to have confidence that the
information it receives originated from a specific known source.
• Authorization: The process of determining that a requester is
7. Integration: Integration testing is a logical extension of unit testing.
In its simplest form, two units that have already been tested are
combined into a component and the interface between them is
tested.
8. Reliability: Reliability testing is to monitor a statistical measure of
software maturity over time and compare this to a desired reliability
goal.
9. Compatibility: Compatibility testing of a part of software's non-
functional tests. This testing is conducted on the application to
evaluate the application's compatibility with the computing
environment.
 Requirement identification
• Requirements analysis or requirements engineering
is a process used to determine the needs and
expectations of a new product.
• It involves frequent communication with the
stakeholders and end-users of the product to define
expectations, resolve conflicts, and document all
the key requirements.
Requirement identification
 Testable Requirements
• A testable requirement describes a single function
or behavior of an application in a way that makes it
possible to develop tests to determine whether the
requirement has been met.
• To be testable, a requirement must be clear,
measurable, and complete, without any ambiguity.
 Requirements of Software Testability
Below are some of the capabilities that are associated with software
testability requirements:
• Module capabilities: Software is developed in modules and each
module will be tested separately. Test cases will be designed for each
module and then the interaction between the modules will be tested.
• Testing support capabilities: The entry point to test drivers and root
must be saved for each person, test interface as during the increment
level testing, the trouble and accuracy level of testing root and driver
should be given high priority and importance.
• Defects disclosure capabilities:
– The requirement must be accurate, correct, concise, and
complete.
– The requirement should be unambiguous i.e it should have one
meaning for all staff members.
 – A requirement should not contradict other requirements.
– Priority-based ranking of requirements should be implemented.
– A requirement must be domain-based so that the changing
requirements won’t be a challenge to implement.
• Observation capabilities: Observing the software to monitor the
inputs, their outcomes, and the factors influencing them.

Benefits of software testability

• Minimizes testers’ efforts:
• Determines the volume of automated testing:
• Early detection of bugs:
 Modeling a Test Design Process
• Model-based testing is a systematic method to generate test cases
from models of system requirements.
• It allows you to evaluate requirements independent of algorithm
design and development.
Model-based testing involves:
• Creating a model of system requirements for testing
• Generating test data from this requirements model representation
• Verifying your design algorithm with generated test cases
 Boundary Value Analysis
• Boundary Value Analysis is based on testing the boundary values of
valid and invalid partitions.
• The behavior at the edge of the equivalence partition is more likely to
be incorrect than the behavior within the partition, so boundaries are
an area where testing is likely to yield defects.
• It checks for the input values near the boundary that have a higher
chance of error.
• Every partition has its maximum and minimum values and these
maximum and minimum values are the boundary values of a
partition.
• A boundary value for a valid partition is a valid boundary value.
• A boundary value for an invalid partition is an invalid boundary value.
• For each variable we check-
– Minimum value.
– Just above the minimum.
– Nominal Value.
– Just below Max value.
– Max value
• Example: Consider a system that accepts ages from 18 to 56.
Boundary Value Analysis(Age accepts 18 to 56)

Invalid Valid Invalid

(min-1) (min, min + 1, nominal, max – 1, max) (max + 1)

17 18, 19, 37, 55, 56 57

 EQUIVALENCE CLASS TESTING
• Equivalence Class Testing -that assists the team in getting accurate
and expected results, within the limited period of time and while
covering large input scenarios.
• It plays such a significant role in Software Testing Life Cycle (STLC)
• Equivalence Class Testing, which is also known as Equivalence Class
Partitioning (ECP) and Equivalence Partitioning, is an important
software testing technique used by the team of testers for grouping
and partitioning of the test input data, which is then used for the
purpose of testing the software product into a number of different
classes.
 PATH TESTING
• Path Testing is a method that is used to design the
test cases. In path testing method, the control flow
graph of a program is designed to find a set of
linearly independent paths of execution.
• In this method Cyclomatic Complexity is used to
determine the number of linearly independent
paths and then test cases are generated for each
path.
• Path Testing Process:
Example: Step 1: Draw the control flow graph
Where,
E = Number of edges in control flow graph
N = Number of vertices in control flow graph
P = Number of nodes that have exit points
Step 3: Identify independent paths
The independent paths in the control flow graph are
as follows:
• Path 1: 1A-2B-3C-4D-5F-9
• Path 2: 1A-2B-3C-4E-6G-7I-9
• Path 3: 1A-2B-3C-4E-6H-8J-9
• Step 4: Design test cases
 Data Flow Testing
• Data Flow Testing is a type of structural testing. It is
a method that is used to find the test paths of a
program according to the locations of definitions
and uses of variables in the program.
• It has nothing to do with data flow diagrams.
It is concerned with:
1. Statements where variables receive values,
2. Statements where these values are used or
referenced.
To illustrate the approach of data flow testing,
assume that each statement in the program
assigned a unique statement number. For a
statement number S-
• DEF(S) = {X | statement S contains the definition of X}
• USE(S) = {X | statement S contains the use of X}
Reference or define anomalies in the flow of the
data are detected at the time of associations
between values and variables. These anomalies
are:
• A variable is defined but not used or referenced,
• A variable is used but never defined,
• A variable is defined twice before it is used
Example: Control flow graph of the example:

1. read x, y;
2. if(x>y)
3. a = x+1
else
4. a = y-1
5. print a;
Define/use of variables of above example:
• Definitions
(i) Defining Node
(ii) Usage node
(iii) Definition use Path
(iv) Definition clear path
• Testing Strategies Using du-Paths
(i) Test all du - Paths
(ii) Test all uses
(iii) Test all definitions
 Test Design Preparedness Metrics
1. Preparation Status of Test Cases (PST):
2. Average Time Spent (ATS) in Test Case Design:
3. Number of Available Test (NAT) Cases:
4. Number of Planned Test (NPT) Cases:
5. Coverage of a Test Suite (CTS):
 Test Case Design Effectiveness
The objectives of test case design effectiveness metric is to
(i) Measure the “defect revealing ability” of the test suite and
(ii) Use the metric to improve the test design process.

• During system level testing, defects are revealed due to the

execution of planned test cases.
• In addition to these defects, new defects are found during
testing for which no test cases have been planned.
• For these new defects, new test cases are designed, which are
called as test case escaped (TCE). Test escapes occur because of
deficiencies in the test design process. This happens because the
test engineers get new ideas while executing the planned test
cases.
• A metric commonly used in the industry to
measure test case design effectiveness is the test
case design yield (TCDY), defined as
• TCDY = ((NPT/NPT + number of TCE)) * 100%
where -NPT is the Number of Planned Test Cases
-TCE is the Test Case Escaped
• The TCDY is also used to measure the
effectiveness of a particular testing phase.
 Model-Driven Test Design
• MDTD is built on the idea that designers will
become more effective and efficient if they can
raise the level of abstraction.
• This approach breaks down the testing into a series
of small tasks that simplify test generation.
• Then test designers isolate their tasks and work at a
higher level of abstraction by using mathematical
engineering structures to design test values
independently of the details of the software or
design artifacts, test automation, and Test
Execution.
Different phases in MDTD
1. Test Design
2. Test Automation
3. Test Execution
4. Test Evaluation
 Test Procedures
• The various testing practices, processes, & techniques
used by testers to ensure that the software application
is tested and validated before its release or
deployment is known as software testing procedure.
• Test procedure/script specification report, - a
document providing detailed instructions for the
execution of one or more test cases.
• This report defines the purpose of various software
testing techniques used by testers and makes them
understandable for the client and other stakeholders
of the project.
• Format for Test Procedure / Script Specification:
• Identifier:
• Purpose:
• Special Requirements:
• Procedures/Script Steps:
 Test Case Organization and Tracking
• Test case organization and tracking is the process of
managing test cases throughout the software
development lifecycle.
• It involves creating, storing, updating and executing
test cases, as well as tracking their status and results.
• Common methods used are:
1. Using a test case management tool
2. Using a spreadsheet
3. Using a text document.
Eg: A spreadsheet can be used to effectively track and manage test suites and test
cases.
 Bug Reporting
• A Bug Report in Software Testing is a detailed
document about bugs found in the software
application.
• Bug report contains each detail about bugs like
description, date when bug was found, name of
tester who found it, name of developer who fixed it,
etc.
While reporting the bug to developer, your Bug Report should
contain the following information
• Defect_ID
• Defect Description
• Version
• Steps
• Date Raised
• Reference
• Detected By
• Status
• Fixed by
• Date Closed
• Severity
• Priority
Bug’s Life Cycle
A bug’s life cycle can easily become very complicated if the bug-fixing process doesn’t occur as
smoothly as expected
This generic bug life-cycle state table covers most of the possible situations that can occur.