Preparing a test plan

In software development, a test plan defines your

testing team’s test strategy, goals, and scope,
which ultimately work together to ensure that all
your software components are tested sufficiently
before a release.
Follow these six steps to create an efficient test
plan:
1.Define the release scope
2.Schedule timelines
3.Define test objectives
4.Determine test deliverables
5.Design the test strategy
6.Plan test environment and test data

How to create a test plan

1. Define the release scope
Before any test activity occurs, it’s important to
define the scope of testing for your release. This
means defining the features or functions that need
to be included in the release, considering any
constraints and dependencies that can affect the
release, and determining what type of release it is.
Examples of questions to ask when defining the
release scope include:
 Are there new features being released in this
version?
 What are the risk areas?
 Are there any particularly sticky areas where
you’ve seen regressions in the past?
 What type of release is it? Is this a
maintenance release that includes bug fixes? Is
this a minor feature release? Is this a major
feature release?
 What does being “done” actually look like for
your team?
2. Schedule timelines
Specify release deadlines to help you decide your
testing time and routine. Here are some pointers
for determining timelines:
 Consult your project manager to understand
the current release timeline.
 Look at past release times and schedules.
 Consider extraneous elements: Does the
release need to coincide with outside variables,
such as conferences or events? Factor those
into your release date prediction.
  Consider the timeframes for development:
Your development team might have a set
schedule for finishing development work.
Make sure you comprehend that timeframe so
you can adjust the testing schedule.
 Add some extra wiggle room: It’s common to
encounter unexpected delays. Including extra
time for unforeseen events can help you stick
to your plan.
 Review and update the schedule frequently to
ensure the test timetable is attainable.
3. Define test objectives
A test objective is a reason or purpose for
designing and executing a test. These objectives
ultimately help guide and define the scope of
testing activities.
Examples of general test objectives include:
 Identifying and reporting defects
 Testing new features
 A certain level of test coverage
Examples of objectives for specific types of testing
include:
 Functional testing objectives: Ensure the
software works as it should. Examples of goals
 for this objective include: Validating user
workflows, data processing, and verifying
input/output parameters.
 Performance testing objectives: Ensure the
software is efficient and can handle various
loads. Examples of goals for this objective
include: Verifying software reaction time,
throughput, and scalability.
 Security testing objectives: Uncover program
security flaws. Examples of goals for this
objective include: Verifying authentication
and authorization features and identifying
potential threats.
 Usability testing objectives: Concentrate on
ease of use and user experience. Examples of
goals for this objective include: Validating
software accessibility, verifying user flow, and
identifying user-related issues.
4. Determine test deliverables
Test deliverables are the products of testing that
help track testing progress. Deliverables should
meet your project’s and client’s needs, be
identified early enough to be included in the test
plan, and be scheduled accordingly. There are
different test deliverables at every phase of the
software development lifecycle. Here are
important deliverables to focus on before, during,
and after testing:
Before testing
 Test plan document: The scope, objectives,
and approach of the testing endeavor are all
outlined in the test plan.
 Test suite: Test cases illustrate how to run a
test, including input data, expected output, and
pass/fail criteria.
 Test design and environment
specifications: The test environment outlines
the hardware and software configurations used
for testing.
During testing
 Test log: The test log records each test case’s
results, including issues and resolutions.
 Defect report: A defect report lists testing
issues by severity, priority, and
reproducibility.
 Test data: According to the International
Software Testing Qualifications Board
(ISTQB), test data is data created or selected
to satisfy the execution preconditions and
input content required to execute one or more
test cases.
  Test summary report: The test summary
report lists the number of tests run, passed, and
failed, as well as open defects.
After testing
 Test completion report: Covers the testing
scope, product quality, and lessons discovered.
 User acceptance test (UAT) report: Points to
any issues found and fixed.
 Release notes: List information about what
the release includes. Examples include any
new features for development, advancements,
or fixes.
A test plan’s content and structure differ
depending on its context. Although there isn’t one
cookie-cutter way to write a test plan, following
best practices for test plan development can help
companies deliver high-quality software.
TestRail is test plan software designed to make it
easy to follow best practices for test plan
development. In TestRail, you can enter test cases
with preconditions, test instructions, expected
results, priorities, and effort estimates.

5. Design the test strategy

Test strategy helps determine test cost, test effort,
and which features will be in-scope (planned to be
tested) versus out-of-scope (not planned to be
tested).
Identify testing types
It is critical to identify when to perform what type
of testing, what should be tested manually vs.
automated, the scope of automated tests, how
much work will be required to create new test
cases, and who will be doing that work.
Document risks and issues
It’s essential to document risks that may occur
during testing and the effect of these risks. Risks
can include:
 Strict deadlines
 Insufficient or inaccurate budget estimates
 Poor management
 Problems with the code
 Changes in the business environment
 Limited resources for testing
 Unexpected delays during testing
Document test logistics
Test logistics should answer the “Who, what,
where, when, and how.” Documenting test
logistics ensures that all human and system-related
testing resources are available. For example, it
may be important that your team identifies who is
available to do testing and who will support them
if needed during testing. Moreover, when resource
planning, it can be helpful to identify alternative
resources or build slack into your plan to ensure
your project gets completed.
Establish test criteria
Test Criteria is a standard that regulates all
activities within a testing project. The two main
types of test criteria include suspension and exit
criteria.
 Suspension Criteria: Establishes the
conditions for suspending all tests.
 Exit Criteria: Exit criteria are established
items or goals to complete that define the end
of a test phase. The exit criteria of a test are
the predetermined results that must be
achieved to move on to the next testing phase.
For example, 92% of all critical test cases
must pass before a feature can be deemed
suitable for release to your customers.
6. Plan the test environment and test data
Planning a test environment guarantees precise and
robust testing. The test environment includes
hardware, software, and network configurations
for software testing. Follow these procedures to set
up the test environment:
 Determine your hardware and program
requirements: Select test environment
devices and software, including operating
systems, browsers, databases, and testing
tools.
 Install the required software: Once
prerequisites are established, install the
necessary tools on the test environment. This
may require setting up a separate server to host
the application and installing a database
management system or other tools.
 Configure the network: Make sure that
firewall protocols, IP addresses, and DNS
settings, among other network configurations,
are identical between the test and production
environments.
 Create the test data: Prepare the test material
for the application’s testing. Test data can be
created manually with data from the
production environment, retrieved from an
 existing production environment and database,
or, created via automated Data Generation
Tools.
 Access the builds: Ensure that the builds that
the testers will be testing are accessible. One
example is setting up a file-sharing or version
control system to allow testers access to the
most current builds.
 Verify the test environment: After setting it
up, check that your test environment fulfills
the requirements.
What to estimate?

Software Testing Estimation techniques are the

effort estimation techniques that calculate the
approximate :
1.Time - How much time testing will take?
2.Team Count- How many QA members are
required?
3.Cost - What will be the overall testing cost?
4.Skills - What shall be the skill set of the QA
team?

Effort estimation in software testing

Some of the most popular and effective techniques
in software testing estimation are explained in the
below section. Though these techniques are
explained from a software testing estimation
standpoint, these can also be used for estimating
any complex work or project.

Types of estimation techniques in software testing

Types of estimation techniques in software

testing
1. Work Breakdown Structure (WBS) :
Break the work into smaller modules for easy &
accurate estimations. In this technique, a testing
task is broken down into smaller modules and
those modules are further divided into measurable
sub-modules. Each sub-module is, in turn, divided
into functionalities and they are split into sub-
functionalities. The outcome is a very detailed,
tightly coupled, traceable yet easy to understand,
and manageable hierarchical map of project
functionality. Using any other estimation
technique, these modules are estimated to get
actual effort. The benefit of using a work
breakdown structure (WBS) as a prerequisite with
other techniques is that breaking the complex
project into smaller modules gives more accurate
and measurable estimates. The estimation process
becomes simpler because it is easier to test and
estimate smaller tasks. The other benefit of WBS
is that sub-modules and functionalities are easily
distributed among the team members, can be easily
tracked and measured against original estimation.
2. 3-Point software testing Estimation:
The statistical way of estimation. Similar to the
WBS, it also divides the task into smaller sub-
tasks. But, this is a statistical method where three
possible scenarios should be estimated for each
sub-task based on prior experience or best guesses.
a = the best case estimate
m = the most likely estimate
w = the worst case estimate
A. The best-case estimate: It assumes that the
project aspects like the presence of a highly skilled
team, availability of necessary resources,
everything will go right and the project will face
no blockers. Now using any other estimation
technique project is estimated for the best case to
come to a value. Let's assume this number is 50
man-days for our further calculation. M. The most
likely estimate: It assumes that when the team is
skilled, with enough project resources, most of the
things will go well with very few blockers. Now
using any other estimation technique project is
estimated for the most likely case to come to a
value. Let's assume this number is 70 man-days for
our further calculation.
W. The worst-case estimate: When the team is
insufficiently skilled, the project has limited
resources and most things will not go as planned.
Now using any other estimation technique project
is estimated for the worst-case to come to a value.
Let's assume this number is 100 man-days for our
further calculation. Estimate Calculations B, M,
W respectively are used to calculate ‘E’ and ‘SD’.
‘E’ for estimation, and
‘SD’ for standard deviation - measures the
variability or uncertainty in the estimate
E= (B+4M+W)/6 For above example, E =
(50+(4*70)c+100)/6 = 71.6 man-hours SD = (W -
B)/6 For above example, E = (100-50)/6 = 8.3
Therefore, the nearest approximation for the
testing estimate can be considered to vary within
the range of E+SD to E-SD man-days. For the
above example, the estimate will vary from 63.3 to
79.9 man-hours.

3. Function Point Analysis (FPA) :

Estimation from the functionality standpoint.
Function point analysis is based on the
specifications of the project or design. Similar to
the WBS, tasks are divided into modules and
each model is given a function point, depending
on its complexity. Modules with higher
complexity have higher points. This technique
indicates software functionality from the user’s
point of view and estimates the value of Total
Effort with respect to time, cost, or size of the task.
4

Total Effort = Total FP x Estimate per FP

Estimate per FP is defined by the test manager on

the basis of team experience and skill, with respect
to time, money, or size. For instance,
10hours/points or $100/points. The FP for each
module = No. of modules of a certain difficulty x
FP for that module. Each module’s FP is then
added to have the total FP.

4. Delphi Technique
This technique is a group estimation technique and
is one of the most popular where estimates are
derived after multiple rounds of questionnaires
sent to a panel of experts. It has the following
steps -
1.An expert panel makes forecasts, with reasons,
based on the results of multiple rounds of
questionnaires regarding how many hours a
 certain task or project will take under the
guidance of the manager.
2.After the first round, the experts are allowed to
revise their estimates based on how they
interpret group responses, accounting for other
experts’ judgment.
3.Rounds are repeated till the range of forecasts
decrease and an average value is reached.
4.This method is simple and reliable as the
experts are highly experienced in the subject
area. The resulting estimates from this
technique reflect the consensus estimation of
the group of experts.

5. Agile Estimation
In the previous techniques, details and
requirements are defined before we plan the
schedule and budget. This has some drawbacks
because the software industry is constantly
changing and hence the use of the previous
techniques is decreasing. The test estimation
techniques in agile support continuous delivery.
In these techniques, the currently available data
and prior experience are used for estimation and
new information is continuously integrated into the
project to refine the process of estimation. Some of
the widely used agile estimation techniques are -
1.Planning Poker: It is a consensus-based
technique for estimating, mostly used to
estimate the effort or relative size of testing by
breaking project work into sprints. At the start
of each sprint, estimates are done for the user
stories (smallest measurable user requirement)
and priorities are defined. The team members
use a deck of cards with numbers on them
from 0 to 21 in the Fibonacci sequence (0, 1,
2, 3, 5, 8, 13, 21). These numbers represent
‘Story Points’. The meeting moderator
describes a story and asks agile team members
to estimate the effort privately without
consulting any other team member. Estimates
are done on the story-pointing scale. Members
then asked to hold up the card at the same time
showing the effort they think is required for
the story. This consensus repeats with
discussion until all the votes are accounted for
and reasoned for.
2.T-Shirt Sizing: Sometimes, the story-pointing
scale is overwhelming for the team members
to estimate. In such cases it is more efficient to
switch to a non-numerical system like T-shirt
sizes: XS, S, M, L, XL, and so on, with these
sizes corresponding to the story size that the
 member estimates a story to have. This
presents a simple yet accurate way to estimate
testing efforts.

6. Test Case Point Analysis / Test case based

estimation
This test case-based estimation technique is useful
when test case writing is completed or a number of
test cases and their complexity is known or
estimated beforehand. In the Test Case Point
(TCP) analysis, the test cases are used as input for
estimating testing efforts. Test cases are classified
in terms of complexity. Usually as low, medium,
high, and very high. Then considering a test case
of each complexity level, an effort value can be
estimated for each level of complexity. This value
can also be measured by running a test case each
from the complexity levels and noting the time it
took to run the test. Then this time is multiplied
with the number of test cases of each category to
come to final estimates of the complete test case
set. For eg, assume we have to estimate the testing
effort of test cases set of 100 test cases Step 1.
Classify test cases on the complexity scale. Let's
assume below is the output from our test case set
of 100 test cases. Step 2. Estimate the time it will
take to run test cases for each complexity level.
Step 3. Calculate the total estimates for running all
test cases using numbers from step 1 and step 2.

7. Estimation based Historical Data:

This method analyses and studies the historical
data from past testing projects. This technique
works on the rule that time taken for testing
projects in the past will take similar efforts for
similar complexity projects or functionality. This
method is useful for estimating projects which
have similar nature, technical stack, and test team
members.

Work Breakdown Structure (WBS)

Work Breakdown Structure (WBS) can be easily
understood as a method of breaking down large
tasks into smaller, easily executable groups. The
aim of this method is to make tasks more
approachable and manageable.
In WBS, a testing task gets broken down into
smaller modules, and those modules are further
divided into measurable sub-modules.
Advantages of Work Breakdown Structure
 Provides support in managing the whole
project, including having an overview of the
 project and allocating responsibilities and
resources
 Simplifies the tasks into easy-to-understand

modules
Also Read: How Impact Analysis in Testing can
Fasten Release Cycles

Functional Point Analysis

This method can be useful to get the overall
picture of software testing estimation. It can help
gauge the size, cost, and duration of the project.
Just like WBS, the overall task must be broken
into smaller tasks here as well. These smaller tasks
can be categorized according to functional points.
Software functionality is expressed from the
viewpoint of the user in this technique. These
functional points can be first categorized as
simple, medium, and complex. The more complex
the function point, the more effort is required to
test it.
Total Effort = Total Functional Points x
Estimate per Functional Point
The above formula calculates an effort’s value
based on the task’s time, cost, or size.
Let’s take an example to understand the formula
mentioned above:
Let us assume that the development team has
developed a new e-commerce website and it needs
to be tested.
The task of testing the website will be broken
down into smaller modules.
 Module 1: Payment Gateway to be checked
 Module 2: Log-in system to be tested

 Module 3: Recreation or changing of

password to be checked
All the modules are to be categorized according to
the complexity and given a functional point
Module Complexity Functional P

Payment Gateway Complex 4

to be checked

Log-in system to Simple 1

be tested

Recreation or Medium 2
changing of
password to be
 checked

Now using the formula, total effort can be

calculated
The FP for each module = Number of modules
of a certain complexity x FP for that module.
Each module’s Functional Point is then added to
have the total FP.
So, the functional point of the simple module is
1×1=1.
2 and 4 are for medium and complex, respectively.
Adding all these three will give the Total
Functional points
Estimate defined per Function Point: The
average effort to complete one function point. This
value totally depends on the productivity of the
member who will take charge of the task.
Advantages of Functional Point Analysis
 Can assess the size of any project.
 Results are easily understandable by not even
the QA team but also clients.

3 Point Software Estimation Test

3 – Point Estimation techniques take into
consideration three possible scenarios, the best
case estimate, the most likely estimate, and the
worst case estimate. Similar to the work
breakdown structure, here also, first the tasks are
divided into smaller sub-tasks, and then each sub-
task is estimated using these 3 – Point scenarios.
 Scenario 1: In this case, it is assumed that any
given project has the best resources available
with highly skilled experts working, and no
difficulty or crisis will come up. After these
assumptions points in mind, any estimation
technique can be used to come to a most likely
value.
 Scenario 2: This scenario assumes to be
having enough resources and a skilled team.
Most of the things are assumed to go well with
very few issues coming up. Using any other
estimation technique, now the project is
estimated for the most likely case to come to a
value.
 Scenario 3: Here the assumption is that the
project has limited resources with an
improperly skilled team, and most of the
things will not go as planned. One can use any
estimation technique to come up with a value
for the worst case.
So, taking an example to understand how to
estimate the time it may take to test an e-
commerce website:
 In the best case scenario, let’s assume b = 20
days,
 The most likely scenario may take 30 days, m

= 30 days,
 And in the worst case, it may take 50 days,

so w = 50 days.
How to Calculate Estimation
The effort to complete the task is calculated using
the double-triangular distribution formula –
E = (b+4m+w)/6
E is the value for the estimate
SD = (w – b)/6
SD stands for standard deviation which measures
the variability or uncertainty in the estimate. So,
taking values assumed to complete testing for an e-
commerce website:
E = (20+4(30)50)/6 = 31.67 days
SD = (50 – 20)/6 = 5 days
Therefore, the nearest approximation for the
testing estimate can be considered to vary within
the range of E+SD to E-SD days. For the above
example, the estimate will vary from 36.67 to
26.67 days.
Advantages of Software Estimation Test
 Can help in getting a more precise estimation
 Minimizes the chances of failures

Test Case Specification

Test Case Specification document described
detailed summary of what scenarios will be tested,
how they will be tested, how often they will be
tested, and so on and so forth, for a given feature.
It specifies the purpose of a specific test, identifies
the required inputs and expected results, provides
step-by-step procedures for executing the test, and
outlines the pass/fail criteria for determining
acceptance.
Test Case Specification has to be done separately
for each unit. Based on the approach specified in
the test plan, the feature to be tested for each unit
must be determined. The overall approach stated in
the plan is refined into specific test techniques that
should be followed and into the criteria to be used
for evaluation. Based on these the test cases are
specified for the testing unit.
However, a Test Plan is a collection of all Test
Specifications for a given area. The Test Plan
contains a high-level overview of what is tested for
the given feature area.
Reason for Test Case Specification:
There are two basic reasons test cases are specified
before they are used for testing:
1.Testing has severe limitations and the
effectiveness of testing depends heavily on
the exact nature of the test case. Even for a
given criterion the exact nature of the test
cases affects the effectiveness of testing.
2.Constructing a good Test Case that will
reveal errors in programs is a very creative
activity and depends on the tester. It is
important to ensure that the set of test cases
used is of high quality. This is the primary
reason for having the test case specification
in the form of a document.
The Test Case Specification is developed in the
Development Phase by the organization
responsible for the formal testing of the
application.
What is Test Case Specification Identifiers?
The way to uniquely identify a test case is as
follows:
 Test Case Objectives: Purpose of the test
 Test Items: Items (e.g., requirement
specifications, design specifications, code,
etc.) required to run a particular test case.
This should be provided in "Notes” or
“Attachment” feature. It describes the
features and conditions required for testing.
 Input Specifications: Description of what is
required (step-by-step) to execute the test case
(e.g., input files, values that must be entered
into a field, etc.). This should be provided in
“Action” field.
 Output Specifications: Description of what
the system should look like after the test case
is run. This should be provided in the
“Expected Results” field.
 Environmental Needs: Description of any
special environmental needs. This includes
system architectures, Hardware & Software
tools, records or files, interfaces, etc
To sum up, Test Case Specification defines the
exact set up and inputs for one Test Case.
What is Traceability Matrix (TM)?
A Traceability Matrix is a document that co-relates
any two-baseline documents that require a many-
to-many relationship to check the completeness of
the relationship.
It is used to track the requirements and to check
the current project requirements are met.

What is Requirement Traceability Matrix?

Requirement Traceability Matrix (RTM) is a
document that maps and traces user requirement
with test cases. It captures all requirements
proposed by the client and requirement traceability
in a single document, delivered at the conclusion
of the Software development life cycle. The main
purpose of Requirement Traceability Matrix is to
validate that all requirements are checked via test
cases such that no functionality is unchecked
during Software testing.
Why RTM is Important?
The main agenda of every tester should be to
understand the client’s requirement and make sure
that the output product should be defect-free. To
achieve this goal, every QA should understand the
requirement thoroughly and create positive and
negative test cases.
This would mean that the software requirements
provided by the client have to be further split into
different scenarios and further to test cases. Each
of this case has to be executed individually.
A question arises here on how to make sure that
the requirement is tested considering all possible
scenarios/cases? How to ensure that any
requirement is not left out of the testing cycle?
A simple way is to trace the requirement with its
corresponding test scenarios and test cases. This
merely is termed as ‘Requirement Traceability
Matrix.’
The traceability matrix is typically a worksheet
that contains the requirements with its all
possible test scenarios and cases and their current
state, i.e. if they have been passed or failed. This
would help the testing team to understand the level
of testing activities done for the specific product.

Which Parameters to include in Requirement

Traceability Matrix?
 Requirement ID
 Requirement Type and Description
 Test Cases with Status
Above is a sample requirement traceability matrix.
But in a typical software testing project, the
traceability matrix would have more than these
parameters.

As illustrated above, a requirement traceability

matrix can:
 Show the requirement coverage in the number
of test cases
  Design status as well as execution status for
the specific test case
 If there is any User Acceptance test to be done
by the users, then UAT status can also be
captured in the same matrix.
 The related defects and the current state can
also be mentioned in the same matrix.
This kind of matrix would be providing One Stop
Shop for all the testing activities.
Apart from maintaining an excel separately. A
testing team can also opt for requirements tracing
available Test Management Tools.

Types of Traceability Test Matrix

In Software Engineering, traceability matrix can
be divided into three major component as
mentioned below:
 Forward traceability: This matrix is used to
check whether the project progresses in the
desired direction and for the right product. It
makes sure that each requirement is applied to
the product and that each requirement is tested
thoroughly. It maps requirements to test cases.
 Backward or reverse traceability: It is used
to ensure whether the current product remains
 on the right track. The purpose behind this
type of traceability is to verify that we are not
expanding the scope of the project by adding
code, design elements, test or other work that
is not specified in the requirements. It maps
test cases to requirements.
 Bi-directional traceability
( Forward+Backward): This traceability
matrix ensures that all requirements are
covered by test cases. It analyzes the impact of
a change in requirements affected by
the Defect in a work product and vice versa.

How to create Requirement Traceability

Matrix
Let’s understand the concept of Requirement
Traceability Matrix through a Guru99 banking
project.
On the basis of the Business Requirement
Document (BRD) and Technical Requirement
Document (TRD), testers start writing test cases.
Let suppose, the following table is our Business
Requirement Document or BRD for Guru99
banking project.
Here the scenario is that the customer should be
able to login to Guru99 banking website with the
correct password and user#id while manager
should be able to login to the website through
customer login page.

While the below table is our Technical

Requirement Document (TRD).

Note: QA teams do not document the BRD and

TRD. Also, some companies use Function
Requirement Documents (FRD) which are
similar to Technical Requirement Document but
the process of creating Traceability Matrix remains
the same.

A Software Testing Traceability Matrix (STM) is a

document that links and maps test cases to their
respective requirements, ensuring that each
requirement has been adequately tested.
It serves as a verification tool to confirm that all
software requirements, as defined in the
requirements specification document, are covered
by test scenarios and cases.
The matrix facilitates identifying missing tests,
understanding the impact of changes, and
ensuring comprehensive test coverage.
By maintaining traceability from requirements
through to test cases and defects, STMs provide
clear visibility into the test coverage, project
progress, and quality assurance process, aiding in
effective project management and delivery.

Benefits of Using Traceability Matrix

The Software Testing Traceability Matrix (STM)
is critical for several technical and project
management reasons:
1.Ensures Coverage: STM guarantees that all
requirements are tested, minimizing the risk of
untested functionality being released. It
systematically matches requirements with test
cases, ensuring comprehensive coverage.
2.Impact Analysis: It facilitates efficient impact
analysis by identifying which test cases are
affected by changes in requirements, thereby
streamlining regression testing and reducing
the risk of introducing defects.
3.Defect Traceability: STM links defects to
their corresponding requirements and test
cases, making it easier to pinpoint the source
of defects, understand their impact, and
prioritize fixes.
4.Project Management: It gives stakeholders a
transparent overview of testing progress and
requirement coverage, aiding in project
tracking, planning, and decision-making.
5.Compliance and Audit: For projects under
regulatory scrutiny, STM demonstrates due
diligence and adherence to quality standards
by providing auditable evidence of
requirement coverage and testing.
6.Efficiency in Test Maintenance: By clearly
linking requirements to test cases, STMs
simplify the maintenance of test suites,
 especially in agile and rapidly changing
environments.
7.Communication: It enhances communication
among team members by providing a clear and
common understanding of what needs to be
tested, the testing scope, and the rationale
behind test case selection.
Types of Software Testing Traceability Matrix
Mentioned below are the key types of software
testing traceability matrixes:
Forward Traceability
Forward traceability focuses on mapping
requirements to test cases. It ensures that every
requirement has corresponding test cases designed
to validate it. This type of traceability ensures
completeness in testing efforts by confirming that
all specified functionalities are covered by test
cases.

Backward Traceability
Backward traceability involves tracing test cases
back to the originating requirements. It ensures
that every test case has a clear association with one
or more requirements. This type of traceability
helps in validating the necessity of each test case
and identifying any redundant or obsolete ones.

Bidirectional Traceability
Bidirectional traceability combines both forward
and backward traceability, establishing a two-way
mapping between requirements and test cases.
It ensures not only that each requirement has
corresponding test cases but also that each test
case is linked back to the originating requirements.
This comprehensive approach provides a thorough
understanding of the testing coverage and its
alignment with the project requirements.

Vertical Traceability
Vertical traceability extends beyond requirements
and test cases to encompass other artifacts
throughout the software development lifecycle,
such as design documents, code modules, and user
manuals.
It enables stakeholders to trace the evolution of
various elements across different phases of
development, ensuring consistency and coherence
in the final product.

Horizontal Traceability
Horizontal traceability focuses on establishing
relationships between artifacts within the same
development phase. For example, it may involve
linking test cases to each other based on shared
test objectives or dependencies.
This type of traceability enhances collaboration
and coordination among testing teams, ensuring
that efforts are synchronized and aligned toward
common goals.

Basic Parameters to be included in TM

(Traceability Matrix)
 Requirement ID
 Type and description
 Test case no:
 Requirement coverage in a number of test
cases
 Test design status and the execution of the test
status
  Unit test cases
 Integration test cases
 System test cases
 Risks
 UAT (User Acceptance Test) Status
 Defects and current status
Tips for Effective Software Testing Traceability
1.Start Early: Incorporate traceability at the
beginning of the project. Early integration
ensures that all requirements are captured and
traced throughout the project lifecycle.
2.Maintain Consistency: Use a consistent
format for documenting requirements, test
cases, and defects. Consistency makes it easier
to trace and manage these artifacts as the
project evolves.
3.Automate Where Possible: Utilize tools that
support traceability and automate the process
of linking requirements, test cases, and
defects. Automation reduces manual errors
and saves time.
4.Regular Updates: Keep the traceability
matrix updated with changes in requirements,
test cases, and defect status. Regular updates
ensure the matrix remains an accurate
reflection of the project state.
5.Involve Stakeholders: Engage project
stakeholders in the traceability process. Their
input can provide additional insights, ensuring
comprehensive coverage and alignment with
project objectives.
6.Review and Audit: Periodically review the
traceability matrix for completeness and
accuracy. Audits can uncover gaps in test
coverage or discrepancies in the traceability
links.
7.Use Unique Identifiers: Assign unique
identifiers to requirements, test cases, and
defects. Unique IDs simplify the process of
tracing and reduce confusion.
8.Prioritize Traceability for Critical
Requirements: Focus on establishing clear
traceability for high-priority and critical
requirements. Ensuring these requirements are
thoroughly tested and traced is vital for project
success.
9.Train the Team: Educate your team on the
importance of traceability and how to
effectively use the traceability matrix. Well-
informed team members are more likely to
maintain accurate and useful traceability
records.
 10. Leverage Traceability for Impact
Analysis: Use the traceability matrix to
conduct impact analysis for proposed changes.
Understanding the relationships between
requirements, test cases, and defects helps in
assessing the potential impact of changes.
How to Create TM (Traceability Matrix)?
Creating a Traceability Matrix (TM) involves
systematically linking project requirements with
their corresponding test cases, test results, and any
related issues or defects. This ensures that every
requirement is adequately tested and accounted
for. Here’s a step-by-step guide to creating an
effective Traceability Matrix:
Step 1: Identify Your Requirements
 Gather Requirements: Start by collecting all
project requirements from the requirements
documentation. This includes functional, non-
functional, and system requirements.
 Assign Unique Identifiers: Give each
requirement a unique identifier (ID) for easy
reference and tracking.
Step 2: Outline Your Test Cases
  List Test Cases: Identify all test cases that
have been designed to verify the requirements.
This includes both automated and manual test
cases.
 Assign Identifiers to Test Cases: Similar to
requirements, assign a unique ID to each test
case for easy referencing.
Step 3: Create the Matrix Structure
 Choose a Tool: Decide on a tool or software
to create the matrix. This can range from
simple tools like Microsoft Excel or Google
Sheets to more sophisticated test management
tools that offer traceability matrix features.
 Set Up the Matrix: Create a table with
requirements listed on one axis (usually the
vertical axis) and the test cases listed on the
other (usually the horizontal axis).
Step 4: Map Requirements to Test Cases
 Link Test Cases to Requirements: For each
requirement, indicate which test cases are
intended to verify it. This can be done by
placing a mark, such as a checkmark or a test
case ID, in the cell where the requirement row
and test case column intersect.
  Ensure Full Coverage: Make sure every
requirement has at least one test case linked to
it. If any requirement is not covered, you may
need to create additional test cases.
Step 5: Include Additional Information (Optional)
 Add Test Results: You can extend the
traceability matrix to include the results of
each test case (Pass/Fail/Blocked).
 Link to Defects: If applicable, include
columns to link failed test cases to reported
defects or issues, providing a direct trace from
requirements to defects.
Step 6: Maintain the TM
 Update Regularly: Keep the TM updated
with any changes in requirements, additions or
modifications of test cases, and updates in test
results or defect status.
 Review for Completeness: Periodically
review the TM to ensure it accurately reflects
the current state of the project and all
requirements are adequately tested.
Step 7: Utilize the TM for Reporting and Analysis
  Analyze Test Coverage: Use the TM to
identify any gaps in test coverage and address
them.
 Support Impact Analysis: Leverage the TM
to assess the impact of requirement changes on
existing test cases and defects.
Creating and maintaining a Traceability Matrix is
a dynamic process that requires ongoing attention
throughout the project lifecycle. It’s a powerful
tool for ensuring that all project requirements are
met and that the final product is of high quality.

What Is the Architecture of Test Automation?

Test architecture is the high-level structure of the
automation tests for a software project. A well-
designed test architecture can make the difference
between a successful project and one that fails to
meet its goals. The architecture of test automation
should take into account the objectives of the
testing, the types of tests to be performed, and the
resources required to execute the tests.
The Testing Pyramid
  The Test Pyramid provides:
 Starting Place for Automation Testing

 How Tests interact with each other

 The relative investment for each layer of

Automation Testing
The testing pyramid includes a model for how tests
should distribute across different levels. The three
main levels are unit, integration, and end-to-end
tests.
Unit tests are the foundation of the pyramid. They
test individual units of code, such as classes and
methods. These tests are fast to write and run, and
they provide a high degree of confidence that the
units under test behave as expected.
Integration tests build on top of unit tests by
testing how different units work together. These
tests are more complex than unit tests, and they
take longer to run. But they can give you
confidence that your units will work together as
intended when they are integrated.
End-to-end tests complete the pyramid by testing
the system as a whole. These tests simulate how a
real user would interact with the system. They are
the most complex and time-consuming tests to
write, but they can give you confidence that the
system works end-to-end.
The pyramid is not a strict model; there is no right
or wrong way to distribute your tests across the
levels. The important thing is to have a good mix
of tests at all levels to have confidence in your
system.

Types of Test Automation

There are two main types of test automation:
functional and non-functional.
Functional test automation tests the functionality
of the software. It includes tests like unit tests,
integration tests, and functional tests. Non-
functional test automation is used to test for things
like performance, security, and usability. It
includes tests like load tests, stress tests, and
security tests.
Functional test automation is typically used to
automate the regression testing process.
Regression testing is a type of testing that is done
to ensure that new code changes have not
introduced any bugs. It is important to perform
regression testing after every code change to make
sure that the software is still working as expected.
Non-functional test automation is typically used to
automate the performance testing process.
Performance testing ensures that the software can
handle the expected load. It is important to
perform performance testing before releasing the
software to make sure that it can handle the
expected traffic.
By knowing how to test an application, a tester can
develop a well-rounded testing strategy that covers
all of the bases.

Test Design
Designing an effective test automation strategy
requires taking a number of factors into
consideration. These include the types of tests to
be automated, the tools to be used, the team’s
skills and experience, and the project’s timeline
and budget.
The first step in designing a test automation
strategy is identifying which tests should be
automated. This can be done using the testing
pyramid framework discussed earlier. The tests
that should be given priority are the ones that are
most likely to find bugs.
The next step is to choose the right tools for the
job. Many different test automation tools are
available, each with its strengths and weaknesses.
The right tool for the job will depend on the nature
of the project and the team’s skills and experience.
Once the tools have been chosen, the team needs
to be trained to use them. This is important
because the architecture of test automation is only
as effective as the team using it. The team should
have a clear understanding of the process and be
able to use the tools effectively.
Finally, the project’s timeline and budget need to
be considered. Test automation can be a time-
consuming and expensive process. It is important
to make sure that there is enough time and money
allocated to the project to get the desired results.

How to Scale the Architecture of Test

Automation
1. Use a Cloud-Based Testing Solution
2. Use a Test Management Tool to Help You Organize and
Run Your Tests
3. Use a Cloud-Based Testing Solution
4. Use a Continuous Integration Server to Automatically
Run Your Tests
5. Plan For Growth From the Start

GENERIC REQUIREMENT FOR

TESTTOLL/FRAMEWORK
What is the generic requirement for test tool?
criteria for selection of testing tool are the
following:
Capable- It should be able to manage the project
test cases and test data efficiently.
Flexibility- It should be able to integrate with
other third-party tools to extend the functionality
tool.
Cost-effective- It should come into your project
budget.

The testing framework must allow many-to-many

relationships between test files, test cases, and test
results. There should not be an assumption of one-
to-one relationship between elements at the
various layers. A given test case may require
several test files. A given test file may be used by
several test cases.
Selection of Testing Tools
1. Project Requirements:

 Type of application that needs to be tested: It could be web, mobile, API or a desktop
application.
 Platforms that need to be tested: If yours is a desktop application, list down the
operating systems that should be tested. If yours is a mobile application, then list
down the supported mobile operating systems. If yours is a web application, then list
down the supported browsers.
 Language your application is built in: This can help if you are planning to use a
programming language for automation.
 Need for cross-browser testing/cross-device testing: If yours is a web application or a
mobile application then you will, most probably, need this.

2.Team Skills / Learning Curve:

When selecting a tool for automation there could be 2 types of tools:

 A codeless test automation tool

 An automation tool that requires coding

If yours is a team that already has people that are skilled in some programming language then
you can think of using an automation tool in that programming language. Or, if you plan to
hire skilled people for automation then you don’t need to consider this point.
But, if you are planning to have an automation tool that will not need you to look for people
with the required skillset, going for codeless automation tools will be a good idea. These
tools allow the automation of test cases without the need for knowing a programming
language.
Check this guide to know about Codeless Testing in detail.
3. Budget:
This is a very important criteria for selection of testing tool. You might easily say that you
will want a free tool because you don’t want to spend on automation if you can avoid it.
But, you also need to consider that the amount of time being spent on automation, the number
of people working on the tool and the machines being used for automation also constitute the
amount you spend on automation. So, consider below points before deciding on the budget:
  Cost of human resources being used for automation: If there is a tool that does not
need you to hire new resources, especially for automation, consider it a saving.
 Time spent on learning the tool: If there is a tool that has a low learning curve, that is
an indirect saving in the cost you might have spent in terms of the time the resources
spend on learning the tool. Or hiring resources that are skilled in that particular tool.
 Time being spent on automation: If there is a tool that makes it easy to create and
maintain test cases, thereby saving time, consider it a saving in cost.
 Cost of infrastructure: Talking about cloud and hosting, you can go for an ideal PHP
hosting that gives an amazing managed hosting experience.

4. Ease of Test Case Creation and Maintenance:

Not every tool is made to handle all kinds of scenarios. So, to make sure that your chosen tool
meets your needs, try automating a few test cases of your application to know if the tool suits
your needs. That could be done with the trial version of a tool if your search has narrowed
down to premium tools.
Also, to avoid spending more time in test case maintenance as compared to test case creation,
make sure to choose a tool that fits your budget including the maintenance costs. There are
tools that have the ability to self-heal the test cases in case of minor changes in the
application.
Such tools help to reduce the cost of test case maintenance. Also, it helps if the tool supports
pause and resume of test case execution for a better debugging experience.
5. Reusability:
To avoid writing the same code multiple times in multiple test cases and to avoid
duplication of efforts, look for tools that allow the reuse of already created test steps
in different test cases and projects.
6. Data-driven Testing:
If yours is an application that needs testing for a variety of data at multiple interfaces,
it is important to choose a tool that supports data-driven testing.
7. Reporting:
Test case creation and test case execution would be useless if the reports were not
useful so do go through all the features in the reporting supported by a tool.
Few of them would be:

 Screenshots for failed steps

 Video for test execution
 Stack trace for the error
 A clear indication of failed test cases/steps
 Time taken for execution of test steps and test cases is reported
8. Support for Collaboration:
If you are doing automation of a project for a client, the client will want to review the
quality of automated test cases.
It will also be beneficial if other non-technical members of the team are able to
automate/review the test cases. So, in such scenarios, look for tools that make
collaboration with the management and clients easy.
9. Support for Tools for Integration:
If there are some process improvement or CI/CD tools that you already use or plan
on using, make sure that you chose a tool that integrates with them.
10. Training and 24×7 Support:
Consider a scenario – you started using a tool for automation, and after automating
about 10 test cases successfully, you got stuck on the 11th test case; you don’t know
how to resolve the problem. You have looked at all possible forums but you don’t
have a solution in sight. If you want to save the time, use a tool that has 24×7
support to resolve any problems you encounter.

PROCESS MODEL FOR AUTOMATION :

 Automated Testing is a technique where the Tester writes
scripts on their own and uses suitable Software or
Automation Tool to test the software. It is an Automation
Process of a Manual Process. It allows for executing
repetitive tasks without the intervention of a Manual
Tester.
 It is used to automate the testing tasks that are difficult to
perform manually.
 Automation tests can be run at any time of the day as
they use scripted sequences to examine the software.
 Automation tests can also enter test data compare the
expected result with the actual result and generate
detailed test reports.
 The goal of automation tests is to reduce the number of
test cases to be executed manually but not to eliminate
manual testing.
 It is possible to record the test suit and replay it when
required.
 In the year 1994, An aircraft completing its Routine
flight crashed just before landing. This was due to some
bug or defect in the Software. The Testers didn’t even
care about the final testing and hence this accident
happened. So to replace for few of the Manual Tests
(mandatory), there is a need for Automation Testing.
Below are some of the reasons for using automation
testing:
 Quality Assurance: Manual testing is a tedious task that
can be boring and at the same time error-prone. Thus,
using automation testing improves the quality of the
software under test as more test coverage can be
achieved.
 Error or Bug-free Software: Automation testing is more
efficient for detecting bugs in comparison to manual
testing.
 No Human Intervention: Manual testing requires huge
manpower in comparison to automation testing which
requires no human intervention and the test cases can be
executed unattended.
 Increased test coverage: Automation testing ensures
more test coverage in comparison to manual testing
where it is not possible to achieve 100% test coverage.
 Testing can be done frequently: Automation testing
means that the testing can be done frequently thus
improving the overall quality of the software under test
 Top of Form
 Bottom of Form



