ppppppppppppppppppppppp[;';;;;;;;;;;;;;;;;;;;;;;;;;

SUBJECT : STQA (410245D)
(2019 PATTERN)
UNIT-II: TEST PLANNING AND MANAGEMENT
Prepared By : Prof.A.H.Joshi

SYLLABUS
 Test Planning –Artifacts, Strategy, Test
Organization –Test Manager ,Tester Role,
Test plan purpose ,contents, Test Strategy
and Approach, Test cases , Test Data, Test
Entry-Exit criteria, Test Execution Schedule,
Use case Testing, Scenario Testing, Test
Use case Testing, Scenario Testing, Test
Monitoring , Control -Test Metrics –Test
Case Productivity, Test case Coverage, Defect
Acceptance ,Rejection, Test Efficiency, Efforts
and Schedule Variance, Test Efforts biasing
Factors, Test Report , configuration
Management, Quality Assurance Process,
Documentation Risk Issues. Software
Quality, Quality Management Importance,
Quality Best practices.

TEST PLAN
 A test plan is document describing the scope,
approach, resources and scheduled of intended
test activities
 A Test Plan is a detailed document that catalogs
the test strategies, objectives, schedule,
the test strategies, objectives, schedule,
estimations, deadlines, and resources required to
complete that project.
 Test plan is monitored and controlled by test
manager

TYPES OF TEST PLAN
 Master test Plan
- Complete testing strategy
- Includes multiple level of testing
 Phase test Plan
 Phase test Plan
- Addresses any one phase of the testing strategy
- E.g. List of Tools, List of test cases
 Specific test Plan
- Design for major type of testing like security testing ,Load
testing, Performance testing

HOW TO WRITE A TEST PLAN
 Follow the seven steps below to create a test plan
as per IEEE 829
1. Analyze the product
2. Design the Test Strategy
3. Define the Test Objectives
3. Define the Test Objectives
4. Define Test Criteria
5. Resource Planning
6. Plan Test Environment
7. Schedule & Estimation
8. Determine Test Deliverables

STEP 1) ANALYZE THE PRODUCT
 How can you test a product without any information
about it? The answer is Impossible. You must learn
a product thoroughly before testing it.
 The product under test is Guru99 banking website.
You should research clients and the end users to
know their needs and expectations from the
know their needs and expectations from the
application
 Who will use the website?
 What is it used for?
 How will it work?
 What are software/ hardware the product uses?
 You can use the following approach to analyze the site

STEP 2) DEVELOP TEST STRATEGY
 Test Strategy is a critical step in making a Test
Plan in Software Testing. A Test Strategy
document, is a high-level document, which is
usually developed by Test Manager. This
document defines:
document defines:
 The project’s testing objectives and the means
to achieve them
 Determines testing effort and costs
 Back to your project, you need to develop Test
Strategy for testing that banking website. You
should follow steps below

 Step 2.1) Define Scope of Testing
 Before the start of any test activity, scope of the
testing should be known. You must think hard about
it.
 The components of the system to be tested (hardware,
software, middleware, etc.) are defined as “in scope“
The components of the system that will not be tested
 The components of the system that will not be tested
also need to be clearly defined as being “out of
scope.”
 Defining the scope of your testing project is very
important for all stakeholders. A precise scope helps
you
 Give everyone a confidence & accurate
information of the testing you are doing
 All project members will have a clear understanding
about what is tested and what is not

 Step 2.2) Identify Testing Type
 A Testing Type is a standard test procedure
that gives an expected test outcome.
 Each testing type is formulated to identify a
specific type of product bugs. But, all Testing
specific type of product bugs. But, all Testing
Types are aimed at achieving one common goal
“Early detection of all the defects before
releasing the product to the customer”

 Step 2.3) Document Risk & Issues
 Risk is future’s uncertain event with a
probability of occurrence and a potential for
loss. When the risk actually happens, it becomes
the ‘issue’.
In the article Risk Analysis and Solution, you
 In the article Risk Analysis and Solution, you
have already learned about the ‘Risk’ analysis in
detail and identified potential risks in the
project.
 In the QA Test Plan, you will document those
risks


 Step 2.4) Create Test Logistics
 In Test Logistics, the Test Manager should answer
the following questions:
 Who will test?
 When will the test occur?
 Who will test?
 Who will test?
 You may not know exact names of the tester who will
test, but the type of tester can be defined.
 To select the right member for specified task, you
have to consider if his skill is qualified for the task or
not, also estimate the project budget. Selecting wrong
member for the task may cause the project
to fail or delay.


 Person having the following skills is most ideal
for performing software testing:
 Ability to understand customers point of view
 Strong desire for quality
Attention to detail
 Attention to detail
 Good cooperation
 In your project, the member who will take in
charge for the test execution is the tester. Base
on the project budget, you can choose in-source or
outsource member as the tester.

 When will the test occur?
 Test activities must be matched with associated
development activities.
 You will start to test when you have all
required items shown in following figure
required items shown in following figure


STEP 3) DEFINE TEST OBJECTIVE
 Test Objective is the overall goal and
achievement of the test execution. The objective
of the testing is finding as many software defects
as possible; ensure that the software under test
is bug free before release.
is bug free before release.
 To define the test objectives, you should do 2
following steps
 List all the software features (functionality,
performance, GUI…) which may need to test.
 Define the target or the goal of the test based on
above features

STEP 4) DEFINE TEST CRITERIA
 Test Criteria is a standard or rule on which a test
procedure or test judgment can be based. There’re 2
types of test criteria as following
 Suspension Criteria
 Specify the critical suspension criteria for a test. If
the suspension criteria are met during testing, the
the suspension criteria are met during testing, the
active test cycle will be suspended until the criteria
are resolved.
 Test Plan Example: If your team members report that
there are 40% of test cases failed, you
should suspend testing until the development team
fixes all the failed cases.


 Exit Criteria
 It specifies the criteria that denote
a successful completion of a test phase. The exit
criteria are the targeted results of the test and
are necessary before proceeding to the next phase
are necessary before proceeding to the next phase
of development. Example: 95% of all critical test
cases must pass.

 Some methods of defining exit criteria are by
specifying a targeted run rate and pass rate.
 Run rate is ratio between number test cases
executed/total test cases of test specification.
For example, the test specification has total 120
For example, the test specification has total 120
TCs, but the tester only executed 100 TCs, So the
run rate is 100/120 = 0.83 (83%)
 Pass rate is ratio between numbers test cases
passed / test cases executed. For example, in
above 100 TCs executed, there’re 80 TCs that
passed, so the pass rate is 80/100 = 0.8 (80%)

STEP 5) RESOURCE PLANNING
 Resource plan is a detailed summary of all
types of resources required to complete project
task. Resource could be human, equipment and
materials needed to complete a project
 The resource planning is important factor of the
 The resource planning is important factor of the
test planning because helps
in determining the number of resources
(employee, equipment…) to be used for the
project. Therefore, the Test Manager can make
the correct schedule & estimation for the project.

Human Resource
Test Manager
Manage the whole project
Define project directions
Acquire appropriate resources
Tester
Execute the tests, Log results, Report the defects. Tester
could be in-sourced or out-sourced members, base on the
project budget
Developer in
Test
Implement the test cases, test program, test suite etc.
Test Builds up and ensures Test Environment and assets
Test
Administrator
Builds up and ensures Test Environment and assets
are managed and maintained
SupportTester to use the test environment for test execution
SQA members Take in charge of quality assurance
Check to confirm whether the testing process is meeting
specified requirements

Human Resource
Server Install the web application under test
This includes a separate web server, database server, and
application server if applicable
Test tool
The testing tool is to automate the testing, simulate the
user operation, generate the test results
There are tons of test tools you can use for this project such
as Selenium, QTP…etc.
Network
You need a Network include LAN and Internet to simulate
Network
You need a Network include LAN and Internet to simulate
the real business and user environment
Computer The PC which users often use to connect the web server

STEP 6) PLAN TEST ENVIRONMENT
 What is the Test Environment
 A testing environment is a setup of software and
hardware on which the testing team is going to
execute test cases. The test environment consists
of real business and user environment, as well as
physical environments, such as server, front end
running environment.
running environment.
 How to setup the Test Environment
 Back to your project, how do you set up test
environment for this banking website?
 To finish this task, you need a strong
cooperation between Test Team and Development
Team


 You should ask the developer some questions to
understand the web application under
test clearly. Here’re some recommended
questions. Of course, you can ask the other
questions if you need.
questions if you need.
 What is the maximum user connection which this
website can handle at the same time?
 What are hardware/software requirements to
install this website?
 Does the user’s computer need any particular
setting to browse the website?

STEP 7) SCHEDULE & ESTIMATION
 In Test estimation, you already used some
techniques to estimate the effort to complete the
project. Now you should include that estimation
as well as the schedule to the Test Planning
 In the Test Estimation phase, suppose you break
 In the Test Estimation phase, suppose you break
out the whole project into small tasks and add
the estimation for each task as below

Task Members Estimate effort
Create the test
specification
Test Designer 170 man-hour
Perform Test
Execution
Tester, Test
Administrator
80 man-hour
Test Report Tester 10 man-hour
Test Report Tester 10 man-hour
Test Delivery 20 man-hour
Total 280 man-hour

 Then you create the schedule to complete these
tasks.
 Making schedule is a common term in project
management. By creating a solid schedule in the
Test Planning, the Test Manager can use it as
Test Planning, the Test Manager can use it as
tool for monitoring the project progress, control
the cost overruns.

 To create the project schedule, the Test Manager
needs several types of input as below:
 Employee and project deadline: The working
days, the project deadline, resource availability
are the factors which affected to the schedule
are the factors which affected to the schedule
 Project estimation: Base on the estimation, the
Test Manager knows how long it takes to
complete the project. So he can make the
appropriate project schedule
 Project Risk : Understanding the risk helps
Test Manager add enough extra time to the
project schedule to deal with the risks

STEP 8) TEST DELIVERABLES
 Test Deliverables is a list of all the documents,
tools and other components that has to be
developed and maintained in support of the
testing effort.
 There are different test deliverables at every
 There are different test deliverables at every
phase of the software development lifecycle.


Test deliverables are
provided before testing
phase.
1.Test plans document.
2.Test cases documents
3.Test Design specifications.
provided during the testing
1.Test Scripts
2.Simulators.
3.Test Data
4.Test Traceability Matrix
5.Error logs and execution logs.
provided after the testing
cycles is over.
Test Results/reports
Defect Report
Installation/ Test procedures
guidelines
Release notes

TEST ARTIFACT
 Test artifacts are also known as test deliverables.
These are the reports or documents created while
the testing is being carried out. These help in
ensuring that the stakeholders are kept informed
about the progress in the project.
about the progress in the project.
 A software project undergoes several phases
before its finally delivered to the end-user. These
phases are completely documented and presented
to the client so that they are updated and can
analyze if the requirements are being met or not.

TYPES OF TEST ARTIFACT
1.Test Strategy : It is usually developed by the project
manager. A test strategy is a document that lists the
details about how the whole project will proceed.
These include requirements and resources for the
project, testing strategies involved, test design,
incremental phases involved, client communication
incremental phases involved, client communication
processes, etc. The document is just an outline that
goes about how the whole project will be managed.
2.Test Plan : A Test plan is often confused with a test
strategy. It is a detailed document covering all the
aspects of the testing phase. Whereas a test strategy
is just an outline for the whole project.

 The test plan has a more systematic approach while
covering minute details about how the whole testing phase
will work. The document is dynamic and acts as a reference
to map how the testing phase is progressing by the QA
(Quality Assurance) team. A test plan includes details like-
1. Scope of the project.
The objective of the project.
2. The objective of the project.
3. Resources required.
4. Different effective testing approaches. How all the testing
phases will be carried out?
5. Risks involved.
6. Actual and expected test results.
7. Mapping out different phases of testing.
8. The final table of failed and passed test results.

3.Test Scenario : A test scenario is a condition
created to perform successful end-to-end testing.
Several test cases come under a test scenario.
The test cases are developed on the basis of a
high-level test scenario.
high-level test scenario.
It is also sometimes referred to as a test
condition or test possibility. A test scenario
resolves the dilemma of software’s real-life
application.

 4. Test Cases
 The test cases are the extended part of the test scenario
which helps in execution in testing. The document is
quite detailed and includes information like steps to
execute the test, test name, pre-and post-conditions of
the tests, etc. They help to determine the functioning of
the software in different situations.
Points included in the test cases document are-
Points included in the test cases document are-
 Test case ID -Each test case has a unique identification
number.
 Test case name.
 Description of the test case – It’s an explanation of how
the test case will proceed.
 Expected and actual outcomes of the test.
 Results – Either the test case is passed or failed.

5.Required Traceability Matrix
 The RTM document is used to map out the many to many
relationships between two documents. This is used to
match the requirements of the client with the testing
approach. It is maintained in a table format and links the
requirements to verify if they are being fulfilled.
There are two types of RTM- forward RTM and backward
RTM. Details that are included in the traceability matrix
document are-
 Requirement ID
 Requirement type or description.
 Test Case ID linked to that requirement.
 Result or the status. Whether the requirement was met or
not.

6.Defect/Bug Report
 A defect report is a document that is created once
all the test cases are executed and the results are
recorded. It enlists all the defects or bugs
identified during the testing process. This makes
identified during the testing process. This makes
the task to fix the bugs easier for the developer
team.

7.Test summary report
 At the end of each of the complete testing cycles,
a final report is created. This report includes the
details of the whole testing process. For example
– details about test cases, the results obtained,
bugs fixed, the current status of the project, etc.
bugs fixed, the current status of the project, etc.
This document is important and has to be
presented to the stakeholders to keep them
informed about the progress made in the project.
This is a formal document and everything is
enlisted clearly so that anyone can understand
the report.

8.User guide
 Once the whole software is developed and is
ready to be deployed into the market, a user
guide is created in the end. This guide is helpful
to the end-users and gives detailed information
to the end-users and gives detailed information
about the software and its usage.
 With this, we have come to an end of this article
on – Test Artifacts. I hope this will help you in
further enhancing your knowledge of software
testing.

Test Plan Test Strategy
A test plan for software project can be
defined as a document that defines the
scope, objective, approach and emphasis
on a software testing effort
Test strategy is a set of guidelines that
explains test design and determines
how testing needs to be done
Test plan is carried out by a testing
manager or lead that describes how to
test, when to test, who will test and
what to test
A test strategy is carried out by the
project manager. It says what type of
technique to follow and which module to
test
Test plan narrates about the
specification
Test strategy narrates about the
general approaches
specification general approaches
Test plan can change Test strategy cannot be changed
Test planning is done to determine
possible issues and dependencies in
order to identify the risks.
It is a long-term plan of action. You can
abstract information that is not project
specific and put it into test approach
A test plan exists individually
In smaller project, test strategy is often
found as a section of a test plan
It is defined at project level
It is set at organization level and can be
used by multiple projects

TYPES OF TEST STRATEGY
 Methodological Strategy
 Reactive Strategy
 Analytical Strategy
 Process Compliant Strategy
Model based Strategy
 Model based Strategy
 Regression averse Strategy
 Consultative Strategy

1. METHODICAL STRATEGY
 The first part of test strategy document
is Methodical strategy.
 In this, the test teams follow a set of test
conditions, pre-defined quality
standard(like ISO25000), checklists.
standard(like ISO25000), checklists.
 The Standard checklists is occurred for precise
types of testing, such as security testing.

2. REACTIVE STRATEGY
 The next type of test strategy is known
as Reactive strategy.
 In this, we can design the test and execute them
only after the real software is delivered,
Therefore, the testing is based upon the
Therefore, the testing is based upon the
identified defectsin the existing system.
 Suppose, we have used the exploratory testing,
and the test approvals are established derived
from the existing aspects and performances.
 These test approvals are restructured based on
the outcome of the testing which is implemented
by the test engineer.

3. ANALYTICAL STRATEGY
 Another type of test strategy is Analytical
strategy, which is used to perform testing based
on requirements, and requirements are analyzed
to derive the test conditions. And then tests are
designed, implemented, and performedto
designed, implemented, and performedto
encounter those requirements. For example,
risk-based testing or requirements-based
testing.
 Even the outcomes are recorded in terms
of requirements, such as requirements tested
and passed.

4. STANDARDS COMPLIANT OR PROCESS
COMPLIANT STRATEGY
 In this type of test strategy, the test engineer will
follow the procedures or guidelines created by a
panel of industry specialists or committee
standards to find test conditions, describe test cases,
and put the testing team in place.
 Suppose any project follows the ScrumAgile
 Suppose any project follows the ScrumAgile
technique. In that case, the test engineer will
generate its complete test strategy, beginning from
classifying test criteria, essential test cases,
performing tests, report status, etc., around
each user story.
 Some good examplesof the standards-compliant
process are Medical systems following US FDA
(Food and Drugs Administration) standards.

5. MODEL-BASED STRATEGY
 The next type of test strategy is a model-based
strategy. The testing team selects the current
or expected situation and produces a model for
it with the following aspects: inputs, outputs,
processes, and possible behavior.
processes, and possible behavior.
 And the models are also established based on the
current data speeds, software, hardware,
infrastructure, etc.

6. REGRESSION AVERSE STRATEGY
 In the regression averse strategy, the test
engineer mainly emphasizes decreasing
regression risks for functional or non-
functional product shares.
 For example, suppose we have one web
 For example, suppose we have one web
application to test the regressionissues for the
particular application. The testing team can
develop the test automation for both typical and
exceptional use cases for this scenario.
 And to facilitate the tests can be run whenever
the application is reformed, the testing team can
use GUI-based automation tools.

7. CONSULTATIVE STRATEGY
 The consultative strategy is used to consultkey
investors as input to choose the scope of test
conditions as in user-directed testing.
 In order of priority, the client will provide a list
of browsers and their versions, operating
of browsers and their versions, operating
systems, a list of connection types, anti-
malware software, and also the contradictory
list, which they want to test the application.
 As per the need of the items given in provided
lists, the test engineer may use the various
testing techniques, such as equivalence
partitioning

TEST MANAGEMENT
 Test Management Process is a procedure of
managing the software testing activities from
start to end. The test management process
provides planning, controlling, tracking, and
monitoring facilities throughout the whole project
monitoring facilities throughout the whole project
cycle. The process involves several activities like
test planning, designing, and test execution. It
gives an initial plan and discipline to the
software testing process.

TEST MANAGEMENT PHASES/PARTS
 There are two main parts of Test Management
Process: –
 Planning
 Risk Analysis
 Test Estimation
 Test Estimation
 Test Planning
 Test Organization
 Execution
 Test Monitoring and Control
 Issue Management
 Test Report and Evaluation

PART 1 - PLANNING
 Risk Analysis and Solution
 Risk is the potential loss (an undesirable
outcome, however not necessarily so) resulting
from a given action or an activity.
 Risk Analysis is the first step that Test Manager
 Risk Analysis is the first step that Test Manager
should consider before starting any project.
Because all projects may contain risks, early risk
detection and identification of its solution will
help Test Manager to avoid potential loss in the
future & save on project costs.

 Test Estimation
 An estimate is a forecast or prediction. Test
Estimation is approximately determining how
long a task would take to complete. Estimating
effort for the test is one of
the major and important tasks in Test
the major and important tasks in Test
Management.
 Benefits of correct estimation:
 Accurate test estimates lead to better planning,
execution, and monitoring of tasks under a test
manager’s attention.
 Allow for more accurate scheduling and help
realize results more confidently.

 Test Planning
A Test Plan can be defined as a document describing
the scope, approach, resources, and schedule of
intended Testing activities.
 A project may fail without a complete Test Plan. Test
planning is particularly important in large software
system development.
system development.
 In software testing, a test plan gives detailed testing
information regarding an upcoming testing effort,
including:
 Test Strategy
 Test Objective
 Exit /Suspension Criteria
 Resource Planning
 Test Deliverables

TEST ORGANIZATION
 Test Organization in Software Testing is a
procedure of defining roles in the testing process.
It defines who is responsible for which activities
in the testing process. The same process also
explains test functions, facilities, and activities.
explains test functions, facilities, and activities.
The competencies and knowledge of the people
involved are also defined. However, everyone is
responsible for the quality of the testing process.

PART 2 - EXECUTION
 Test Monitoring and Control
 What will you do when your project runs out of
resources or exceeds the time schedule? You
need to Monitor and Control Test activities to
bring it back on schedule.
bring it back on schedule.
 Test Monitoring and Control is the process of
overseeing all the metrics necessary to ensure
that the project is running well, on schedule, and
not out of budget.

 Monitoring
 Monitoring is a process of collecting, recording,
and reporting information about the project activity
that the project manager and stakeholder needs to
know
 To Monitor, Test Manager does the following
activities
 Define the project goal, or project performance
standard
 Observe the project performance, and compare the
actual and the planned performance expectations
 Record and report any detected problem which
happens to the project

 Controlling
 Project Controlling is a process of using data
from monitoring activity to bring actual
performance to planned performance.
 In this step, the Test Manager takes action to
 In this step, the Test Manager takes action to
correct the deviations from the plan. In some
cases, the plan has to be adjusted according to
project situation.

 Issue Management
 All projects may have potential risks. When the risk
happens, it becomes an issue.
For example:
 The company cuts down your project budget
 Your project team lacks the skills to complete the project
 Your project team lacks the skills to complete the project
 The project schedule is too tight for your team to finish the
project at the deadline.
Risks to be avoided while testing:
 Missing the deadline
 Exceed the project budget
 Lose the customer’s trust
 When these issues arise, you have to be ready to deal with
them – or they can potentially affect the project’s outcome.

 Test Report & Evaluation
 The project has already been completed. It’s now
time to look back at what you have done.
The purpose of the Test Evaluation Reports is:
“Test Evaluation Report” describes the results of
 “Test Evaluation Report” describes the results of
the Testing in terms of Test coverage and exit
criteria. The data used in Test Evaluation are
based on the test results data and test result
summary.

ROLES OF TESTER
 In the test planning and preparation phases of
the testing, testers should review and contribute
to test plans, as well as analyzing, reviewing and
assessing requirements and design specifications.
 They may be involved in or even be the primary
 They may be involved in or even be the primary
people identifying test conditions and creating
test designs, test cases, test procedure
specifications and test data, and may automate
or help to automate the tests.
 They often set up the test environments or assist
system administration and network management
staff in doing so.

 As test execution begins, the number of testers
often increases, starting with the work required
to implement tests in the test environment.
 Testers execute and log the tests, evaluate the
results and document problems found.
results and document problems found.
 They monitor the testing and the test
environment, often using tools for this task, and
often gather performance metrics.
 Throughout the software testing life cycle,
they review each other’s work, including test
specifications, defect reports and test results.

TEST PLAN PURPOSE
 Test plan is the project plan for the testing
work to be done. It is not a test
design specification, a collection
of test cases or a set of test procedures; in fact,
most of our test plans do not address that level of
detail. Many people have different definitions for
detail. Many people have different definitions for
test plans.
Why it is required to write test plans? We have
three main reasons to write the test plans:
 First, by writing a test plan it guides our
thinking. Writing a test plan forces us to
confront the challenges that await us and focus
our thinking on important topics.
:

 Second, the test planning process and the plan
itself serve as the means of communication with
other members of the project team, testers,
peers, managers and other stakeholders.
 Third, the test plan helps us to manage change.
 Third, the test plan helps us to manage change.
During early phases of the project, as we gather
more information, we revise our plans. As the
project evolves and situations change, we adapt
our plans.

TEST APPROACH
 A test approach is the test strategy
implementation of a project, defines how testing
would be carried out. Test approach has two
techniques:
 Proactive - An approach in which the test
 Proactive - An approach in which the test
design process is initiated as early as possible in
order to find and fix the defects before the build
is created.
 Reactive - An approach in which the testing is
not started until after design and coding are
completed.

 Different Test approaches:
 There are many strategies that a project can adopt
depending on the context and some of them are:
1. Dynamic and heuristic approaches
2. Consultative approaches
2. Consultative approaches
3. Model-based approach that uses statistical
information about failure rates.
4. Approaches based on risk-based testing where the
entire development takes place based on the risk
5. Methodical approach, which is based on failures.
6. Standard-compliant approach specified by industry-
specific standards.

 Factors to be considered:
1. Risks of product or risk of failure or the
environment and the company.
2. Expertise and experience of the people in the
proposed tools and techniques.
proposed tools and techniques.
3. Regulatory and legal aspects, such as external
and internal regulations of the development
process.
4. The nature of the product and the domain.

TEST DATA
 Test Data in Software Testing is the input
given to a software program during test
execution.
 Test Data Technique
 Test Data Technique
1. Manual Test Data Creation
2. Automated Test Data Creation
3. Backend Injection
4. Third-party Tools

1. Manual Test Data Creation
 Manual test data generation is creating sample
data for manual testing. One approach is to
prepare a list of items used for testing, generate
sample data using your QA team members or
sample data using your QA team members or
developers, and then validate that it works as
expected.
 Manual test data is the most straightforward
way to create test data. It is often created at the
beginning of project implementation and includes
all possible combinations of inputs and outputs.

2.Automated Test Data Creation
 Automated test data generation effectively
reduces the time taken to develop, maintain, and
execute tests compared to manual test data. It is
performed with the help of automation testing
performed with the help of automation testing
tools like LambdaTest that automate the whole
process from start to finish. These tools are faster
and more accurate than a human-driven
approach, which results in greater efficiency over
time.

3.Backend Injection
 Backend injection is one method of providing test
data to a database. A tester writes relevant SQL
queries, then injects them into the database to
create large amounts of test data. It is easier
than automated data generation methods but
than automated data generation methods but
needs to be more accurate.
 It can be used in the following scenarios:
 To test and debug your application without the hassle
of user interaction.
 To be able to test the accuracy of a system under a
variety of circumstances.
 To avoid the time and expense of manual data
generation.

 Third-party Tools
 Third-party tools can help build up your test data
effectively. These tools thoroughly understand back-
end applications and can pump in data like a real-
time scenario. Hence, the test data is diverse and
voluminous, enabling comprehensive test data
voluminous, enabling comprehensive test data
coverage.
 These tools are more accurate than manual methods
because they thoroughly understand the system and
domain. The tools are designed so that even non-
technical people can use them with little expertise in
the domain. The tools' design makes them ideal for
populating real-time data into the system, thus
allowing users to perform necessary tests on historical
data.

ENTRY EXIT CRITERIA
 Entry Criteria for STLC phases can be defined as
specific conditions; or, all those documents which are
required to start a particular phase of STLC should
be present before entering any of the STLC phase.
 Entry criteria is a set of conditions that permits a
task to perform, or in absence of any of these
conditions, the task cannot be performed.
conditions, the task cannot be performed.
 While setting the entry criteria, it is also important to
define the time-frame when the entry criteria item is
available to start the process.
 For Instance, to start the Test Cases development
phase, the following conditions should be met −
 The requirement document should be available.
 Complete understanding of the application flow is
required.
 The Test Plan Document should be ready.

 Exit Criteria
 Exit Criteria for STLC phases can be defined as
items/documents/actions/tasks that must be
completed before concluding the current phase and
moving on to the next phase.
 Exit criteria is a set of expectations; this should be
met before concluding the STLC phase.
 For Instance, to conclude the Test Cases development
phase, following expectations should be met −
 Test Cases should be written and reviewed.
 Test Data should be identified and ready.
 Test automation script should be ready if applicable.

TEST EXECUTION
 Test execution is the process of executing the code
and comparing the expected and actual results.
Following factors are to be considered for a test
execution process:
1. Based on a risk, select a subset of test suite to be
executed for this cycle.
executed for this cycle.
2. Assign the test cases in each test suite to testers for
execution.
3. Execute tests, report bugs, and capture test status
continuously.
4. Resolve blocking issues as they arise.
5. Report status, adjust assignments, and reconsider
plans and priorities daily.
6. Report test cycle findings and status.

USE CASE TESTING
 Use Case Testing is a functional black box testing
technique that helps testers to identify test
scenarios that exercise the whole system on each
transaction basis from start to finish.
 Use Case Testing is a software testing
 Use Case Testing is a software testing
technique that helps to identify test cases that
cover entire system on a transaction by
transaction basis from start to end. Test cases
are the interactions between users and software
application. Use case testing helps to identify
gaps in software application that might not be
found by testing individual software components.

CHARACTERISTIC OF USE CASE TESTING
 Use Cases capture the interactions between
'actors' and the 'system'.
 'Actors' represents user and their interactions
that each user takes part into.
 Test cases based on use cases and are referred as
 Test cases based on use cases and are referred as
scenarios.
 Capability to identify gaps in the system which
would not be found by testing individual
components in isolation.
 Very effective in defining the scope of acceptance
tests.

THE BELOW EXAMPLE CLEARLY SHOWS THE
INTERACTION BETWEEN USERS AND POSSIBLE
ACTIONS.

SCENARIO TESTING
 Scenario Testing is a Software Testing
Technique that uses scenarios i.e. speculative
stories to help the tester work through a
complicated problem or test system. The ideal
scenario test is a reliable, complicated,
scenario test is a reliable, complicated,
convincing or motivating story the outcome of
which is easy to assess.

 Methods in Scenario Testing: There are two
methods in scenario testing:
1. System scenarios: Scenario tests used in this
method are only those sets of realistic, user
activities that cover various components in the
activities that cover various components in the
system.
2. Use-case and role-based scenarios In the
use-case and role-based scenario method the
focus is specifically on how the system is used
by a user with different roles and environment.

STRATEGIES TO CREATE GOOD SCENARIOS:
 Enumerate possible users their actions and
objectives
 Evaluate users with hacker's mindset and list
possible scenarios of system abuse.
 List the system events and how does the system
 List the system events and how does the system
handle such requests.
 List benefits and create end-to-end tasks to check
them.
 Read about similar systems and their behaviour.
 Studying complaints about competitor's products
and their predecessor.

SCENARIO TESTING RISKS:
 When the product is unstable, scenario testing
becomes complicated.
 Scenario testing are not designed for test
coverage.
 Scenario tests are often heavily documented and
 Scenario tests are often heavily documented and
used time and again

TEST MONITORING
 Test Monitoring in test execution is a process
in which the testing activities and testing efforts
are evaluated in order to track current progress
of testing activity, finding and tracking test
metrics, estimating the future actions based on
metrics, estimating the future actions based on
the test metrics and providing feedback to the
concerned team as well as stakeholders about
current testing process.

TEST CONTROL
 Test Control in test execution is a process of
taking actions based on results of the test
monitoring process. In the test control phase, test
activities are prioritized, test schedule is revised,
test environment is reorganized and other
test environment is reorganized and other
changes related to testing activities are made in
order to improve the quality and efficiency of
future testing process.

WHY DO WE MONITOR?
 Monitoring will allow you to make comparisons
between your original plan and your progress so
far. You will be able to implement changes,
where necessary, to complete the project
successfully.
This small example shows you why we need to
 This small example shows you why we need to
monitor and control test activity.
 After finishing the Test Estimation and test
planning, the management board agreed with
your plan and the milestones are set as per the
following figure.


AS A CONSEQUENCE, YOUR PROJECT FAILS AND YOUR COMPANY
LOSES THE CUSTOMER TRUST. YOU MUST TAKE FULL
RESPONSIBILITY FOR THE PROJECT’S FAILURE.

 No matter how much and carefully we plan, something will
go wrong. We need to actively monitor the project to
 Early detect and react appropriately to deviations and
changes to plans
 Let’s you communicate to stakeholders, sponsors, and team
members exactly where the project stands
and determine how closely your initial plan of action
and determine how closely your initial plan of action
resembles reality
 It will be helpful for the Manager to know whether the
project is going on the right track according to the project
goals. Allows you to make the necessary adjustments
regarding resources or your budget.
 Project monitoring helps you avoid disasters. Monitoring
can be compared to checking the gas gauge in your
car as you drive. It helps you see how much gas left
in the tank, monitoring your project helps you avoid
running out of gas before you reach your goal

SOFTWARE TESTING METRICS
 Software testing metrics are quantifiable
indicators of the software testing process
progress, quality, productivity, and overall health
 The purpose of software testing metrics is to
increase the efficiency and effectiveness of the
increase the efficiency and effectiveness of the
software testing process while also assisting in
making better decisions for future testing by
providing accurate data about the testing
process.
 A metric expresses the degree to which a system,
system component, or process possesses a certain
attribute in numerical terms.

METRICS IMPORTANCE IN SOFTWARE
TESTING
 Test metrics are essential in determining the
software’s quality and performance. Developers
may use the right software testing metrics to
improve their productivity.
1. Test metrics help to determine what types of
1. Test metrics help to determine what types of
enhancements are required in order to create a
defect-free, high-quality software product.
2. Make informed judgments about the testing
phases that follow, such as project schedule and
cost estimates.
3. Examine the current technology or procedure to
see if it need any more changes.

TYPES OF SOFTWARE TESTING METRICS
 Software testing metrics are divided into three
categories:
1. Process Metrics: A project’s characteristics
and execution are defined by process metrics.
These features are critical to the SDLC
These features are critical to the SDLC
process’s improvement and maintenance
(Software Development Life Cycle).
2. Product Metrics: A product’s size, design,
performance, quality, and complexity are
defined by product metrics. Developers can
improve the quality of their software
development by utilizing these features.

3. Project Metrics: Project Metrics are used to
assess a project’s overall quality. It is used to
estimate a project’s resources and deliverables,
as well as to determine costs, productivity, and
flaws.
flaws.

TEST METRICS LIFE CYCLE
Fig. - Test Metrics Lifecycle

Different stages of
Metrics life cycle
Steps during each stage
Analysis
1.Identification of the Metrics
2.Define the identified QA Metrics
Communicate
1.Explain the need for metric to stakeholder and
testing team
2.Educate the testing team about the data points
to need to be captured for processing the metric
Evaluation
1.Capture and verify the data
2.Calculating the metrics value using the data
captured
Report
1.Develop the report with an effective conclusion
2.Distribute the report to the stakeholder and
respective representative
3.Take feedback from stakeholder

#1. PROCESS METRICS
SOFTWARE TEST METRICS USED IN THE PROCESS OF TEST
PREPARATION AND TEST EXECUTION PHASE OF STLC.
1.1. Test Case Preparation Productivity
 It is used to calculate the number of Test Cases
prepared and the effort spent for the preparation
of Test Cases.
 Formula:
 Formula:
 Test Case Preparation Productivity = (No of Test
Case)/ (Effort spent for Test Case Preparation)
 Eg. No. of Test cases = 240
Effort spent for Test case preparation (in hours) = 10
 Test Case preparation productivity = 240/10 = 24 test
cases/hour

#1.2. TEST DESIGN COVERAGE
 It helps to measure the percentage of test case
coverage against the number of requirements
 Formula:
 Test Design Coverage = ((Total number of
requirements mapped to test cases) / (Total number of
requirements)*100
requirements)*100
E.g.:
 Total number of requirements: 100
 Total number of requirements mapped to test cases:
98
 Test Design Coverage = (98/100)*100 = 98%
 The following are generated during the Test
Execution phase of STLC:

#1.3. TEST EXECUTION PRODUCTIVITY
 It determines the number of Test Cases that can
be executed per hour
 Formula:
 (No of Test cases executed)/ (Effort spent for
execution of test cases)E.g.:
execution of test cases)E.g.:
 No of Test cases executed = 180
 Effort spent for execution of test cases = 10
 Test Execution Productivity = 180/10 = 18 test
cases/hour

#1.4. TEST EXECUTION COVERAGE
 It is to measure the number of test cases
executed against the number of test cases planed.
 Formula:
 Test Execution Coverage = (Total no. of test cases
executed / Total no. of test cases planned to
executed / Total no. of test cases planned to
execute)*100E.g.:
 Total no. of test cases planned to execute = 240
 Total no. of test cases executed = 160
 Test Execution Coverage = (180/240)*100 = 75%

#1.5. TEST CASES PASSED
 It is to measure the percentage no. of test cases
passed
 Formula:
 Test Cases Pass = (Total no. of test cases passed)
/ (Total no. of test cases executed) * 100E.g.:
 Test Cases Pass = (80/90)*100 = 88.8 = 89%

#1.6. TEST CASES FAILED
failed
 Formula:
 Test Cases Failed = (Total no. of test cases failed)
 Test Cases Failed= (10/90)*100 = 11.1 = 11%

#1.7. TEST CASES BLOCKED
blocked
 Formula:
 Test Cases Blocked = (Total no. of test cases
blocked) / (Total no. of test cases executed) * 100
blocked) / (Total no. of test cases executed) * 100
E.g.:
 Test Cases Blocked = (5/90)*100 = 5.5 = 6%
Check below video to see “Test Metrics”

#2. PRODUCT METRIC
SOFTWARE TEST METRICS USED IN THE PROCESS OF DEFECT
ANALYSIS PHASE OF STLC.
 #2.1. Error Discovery Rate
 It is to determine the effectiveness of the test
cases.
 Formula:
Error Discovery Rate = (Total number of defects
 Error Discovery Rate = (Total number of defects
found /Total no. of test cases executed)*100
E.g.:
 Total no. of test cases executed = 240
 Total number of defects found = 60
 Error Discovery Rate = (60/240)*100 = 25%

2.2. DEFECT FIX RATE
 It helps to know the quality of a build in terms of
defect fixing.
 Formula:
 Defect Fix Rate = (Total no of Defects reported as
fixed - Total no. of defects reopened) / (Total no of
Defects reported as fixed + Total no. of new Bugs due
Defects reported as fixed + Total no. of new Bugs due
to fix)*100
E.g.:
 Total no of defects reported as fixed = 10
 Total no. of defects reopened = 2
 Total no. of new Bugs due to fix = 1
 Defect Fix Rate = ((10 – 2)/(10 + 1))*100 = (8/11)100 =
72.7 = 73%

#2.3. DEFECT DENSITY
 It is defined as the ratio of defects to
requirements.
 Defect density determines the stability of the
application.
 Formula:
 Formula:
 Defect Density = Total no. of defects identified /
Actual Size (requirements)
E.g.:
 Total no. of defects identified = 80
 Actual Size= 10
 Defect Density = 80/10 = 8

#2.4. DEFECT LEAKAGE
 It is used to review the efficiency of the testing
process before UAT.
 Formula:
 Defect Leakage = ((Total no. of defects found in
UAT)/(Total no. of defects found before UAT)) *
UAT)/(Total no. of defects found before UAT)) *
100
E.g.:
 No. of defects found in UAT = 20
 No. of Defects found before UAT = 120
 Defect Leakage = (20 /120) * 100 = 16.6 = 17%

#2.5. DEFECT REMOVAL EFFICIENCY
 It allows us to compare the overall (defects found
pre and post-delivery) defect removal efficiency
 Formula:
 Defect Removal Efficiency = ((Total no. of defects
found pre-delivery) /( (Total no. of defects found
found pre-delivery) /( (Total no. of defects found
pre-delivery )+ (Total no. of defects found post-
delivery)))* 100
E.g.: Total no. of defects found pre-delivery = 80
 Total no. of defects found post-delivery = 10
 Defect Removal Efficiency = ((80) / ((80) +
(10)))*100 = (80/90)*100 = 88.8 = 89%

TEST EFFORTS
 In software development, test effort refers to the
expenses for (still to come) tests. There is a
relation with test costs and failure costs (direct,
indirect, costs for fault correction). Some factors
which influence test effort are: maturity of
which influence test effort are: maturity of
the software development
process, quality and testability of the testobject,
test infrastructure, skills of staff members,
quality goals and test strategy.

QUALITY ASSURANCE PROCESS
 What is Quality?
 Quality is extremely hard to define, and it is
simply stated: “Fit for use or purpose.” It is all
about meeting the needs and expectations of
customers with respect to functionality, design,
reliability, durability, & price of the product.
reliability, durability, & price of the product.
 What is Assurance?
 Assurance is nothing but a positive declaration
on a product or service, which gives confidence. It
is certainty of a product or a service, which it will
work well. It provides a guarantee that the
product will work without any problems as per
the expectations or requirements.

CONTINUE…..
 Quality software refers to a software which is
reasonably bug or defect free, is delivered in time
and within the specified budget, meets the
requirements and/or expectations, and is
maintainable.
Software Quality Assurance (SQA) is simply
 Software Quality Assurance (SQA) is simply
a way to assure quality in the software. It is the
set of activities which ensure processes,
procedures as well as standards are suitable for
the project and implemented correctly.
 It offers a warranty that the product will perform
faultlessly in accordance with expectation or
needs.

WHAT IS QUALITY ASSURANCE IN
SOFTWARE TESTING(CONTINUED…….)
 Quality Assurance in Software Testing is
defined as a procedure to ensure the quality of
software products or services provided to the
customers by an organization. Quality assurance
focuses on improving the software development
focuses on improving the software development
process and making it efficient and effective as
per the quality standards defined for software
products. Quality Assurance is popularly known
as QA Testing.

HOW TO DO QUALITY ASSURANCE:
COMPLETE PROCESS
 Quality Assurance methodology has a defined
cycle called PDCA cycle or Deming cycle. The
phases of this cycle are:
 Plan
 Do
 Do
 Check
 Act

THESE ABOVE STEPS ARE REPEATED TO ENSURE THAT
PROCESSES FOLLOWED IN THE ORGANIZATION ARE
EVALUATED AND IMPROVED ON A PERIODIC BASIS.
 Plan – Organization should plan and establish the
process related objectives and determine the processes
that are required to deliver a high-Quality end product.
 Do – Development and testing of Processes and also “do”
changes in the processes
changes in the processes
 Check – Monitoring of processes, modify the processes,
and check whether it meets the predetermined
objectives
 Act – A Quality Assurance tester should implement
actions that are necessary to achieve improvements in
the processes

WHAT IS QUALITY CONTROL?
 It is a Software Engineering process used to ensure
quality in a product or a service. It does not deal
with the processes used to create a product;
rather it examines the quality of the “end
products” and the final outcome.
 The main aim of Quality control is to check whether
 The main aim of Quality control is to check whether
the products meet the specifications and
requirements of the customer. If an issue or problem
is identified, it needs to be fixed before delivery to the
customer.
 QC also evaluates people on their quality level skill
sets and imparts training and certifications. This
evaluation is required for the service based
organization and helps provide “perfect” service to the
customers.

QUALITY ASSURANCE FUNCTIONS:
 There are 5 primary Quality Assurance Functions:
1. Technology transfer: This function involves getting a
product design document as well as trial and error data and
its evaluation. The documents are distributed, checked and
approved
2. Validation: Here validation master plan for the entire
system is prepared. Approval of test criteria for validating
system is prepared. Approval of test criteria for validating
product and process is set. Resource planning for execution
of a validation plan is done.
3. Documentation: This function controls the distribution and
archiving of documents. Any change in a document is made
by adopting the proper change control procedure. Approval
of all types of documents.
4. Assuring Quality of products
5. Quality improvement plans

DOCUMENTATION RISK AND ISSUES
 You identify them, record them, monitor
them and plan for them: risks are an
inherent part of every project.
 Risk management is an arm of project
management that deals with managing potential
management that deals with managing potential
project risks.
 A risk management plan defines how your
project’s risk management process will be
executed. That includes the funds, tools and
approaches that will be used to perform risk
identification, assessment, mitigation and
monitoring activities.

 1. Technical risks
 Technical risks refer to anything that could go
wrong with your software, hardware, or any
manuals or other process documents related to
your project.
When listing your technical risks, consider
 When listing your technical risks, consider
whether you have enough computers, tablets, or
other devices for everyone on your team. Ask if
you have experts on your staff to resolve any
software glitches that may arise or if you have
access to external vendors who could help. Also,
review whether you’ve created user-friendly
reference guides for your project’s
implementation.

 2. External risks
 External risks are things that could impact your
project that are outside of your organization’s
direct control.
 When listing your external risks, analyze the
 When listing your external risks, analyze the
current state of your market. Consider what
problems might occur with your subcontractors
or suppliers. Review related local, state, and
federal regulations that impact your company’s
field. Ask if your customers might change over
time and how that would affect your project.

 3. Organizational risks
 Organizational risks refer to aspects of your
company’s overall resources and culture which could
impact your project’s implementation.
 When listing your organizational risks, see if you
 When listing your organizational risks, see if you
have enough staff available to cover the time and
effort it will take to complete your project. Review
whether your financial processes are functioning well
enough to pay subcontractors in a timely fashion.
 Ask whether you have the budget available to
implement your project as intended. Consider
whether you have policies in place to know who will
make decisions on critical project issues.

 4. Project management risks
 Project management risks involve how the team
directly working on your project operates and what
internal aspects of your team could impact your
project’s success.
 When listing your project management risks, take a
 When listing your project management risks, take a
look at the culture and morale of your team and
whether interpersonal issues could impact results.
Review whether you have clear communication
channels established between team members and if
people know whom to turn to for specific issues.
 Consider whether you have included everyone you
need to in the planning phase of your project or if
there are other voices you need to consult.

QUALITY METHODS
Portability A software device is said to be portable, if it can be
freely made to work in various operating system
environments, in multiple machines, with other
software products, etc.
Usability A software product has better usability if various
categories of users can easily invoke the functions of
the product.
Reusability A software product has excellent reusability if different
Reusability A software product has excellent reusability if different
modules of the product can quickly be reused to
develop new products.
Correctness A software product is correct if various requirements as
specified in the SRS document have been correctly
implemented.
Maintainability A software product is maintainable if bugs can be
easily corrected as and when they show up, new tasks
can be easily added to the product, and the
functionalities of the product can be easily modified,
etc.

WHAT IS SOFTWARE QUALITY MANAGEMENT?
 Software Quality Management ensures that the
required level of quality is achieved by
submitting improvements to the product
development process. SQA aims to develop a
culture within the team and it is seen as
culture within the team and it is seen as
everyone's responsibility.
 Software Quality management should be
independent of project management to ensure
independence of cost and schedule adherences. It
directly affects the process quality and indirectly
affects the product quality.

ACTIVITIES OF SOFTWARE QUALITY
MANAGEMENT:
 Quality Assurance - QA aims at developing
Organizational procedures and standards for
quality at Organizational level.
 Quality Planning - Select applicable procedures
and standards for a particular project and modify
and standards for a particular project and modify
as required to develop a quality plan.
 Quality Control - Ensure that best practices
and standards are followed by the software
development team to produce quality products.

EVALUATION OF QUALITY MANAGEMENT
SYSTEM
 Quality systems have increasingly evolved over the
last five decades. Before World War II, the usual
function to produce quality products was to inspect
the finished products to remove defective devices.
Since that time, quality systems of organizations have
undergone through four steps of evolution, as shown
in the fig. The first product inspection task gave
undergone through four steps of evolution, as shown
in the fig. The first product inspection task gave
method to quality control (QC).
 Quality control target not only on detecting the
defective devices and removes them but also on
determining the causes behind the defects. Thus,
quality control aims at correcting the reasons for bugs
and not just rejecting the products. The next
breakthrough in quality methods was the
development of quality assurance methods.

 BPR aims at reengineering the method business is carried
out in an organization. From the above conversation, it can
be stated that over the years, the quality paradigm has
changed from product assurance to process assurance, as
shown in fig.

 The primary premise of modern quality assurance is
that if an organization's processes are proper and are
followed rigorously, then the products are obligated to
be of good quality. The new quality functions include
guidance for recognizing, defining, analyzing, and
improving the production process.
improving the production process.
 Total quality management (TQM) advocates that the
procedure followed by an organization must be
continuously improved through process
measurements. TQM goes stages further than quality
assurance and aims at frequently process
improvement. TQM goes beyond documenting steps to
optimizing them through a redesign. A term linked to
TQM is Business Process Reengineering (BPR).

QUALITY BEST PRACTICES
 1. Include Risk Management with Quality
assurance : Most people think that QA is a
synonym to testing but actually, quality
assurance is a much broader term. Risk
management, as well as other processes and
management, as well as other processes and
activities, should be considered a part of assuring
the quality of your product. It is one of the
building blocks of adequate quality assurance. A
good quote that sums it up is:
 Good Risk Management Includes a Real
Improvement of Software Development to
Organize Quality Assurance Activities.

2. Cover entire SDLC
 Software Quality Assurance is a concept that should
span across the entire lifecycle of software
development and the entire self-development process.
3. Focus on improvement in quality
3. Focus on improvement in quality
 The QA testing should focus on improving the process
of development of software in order to optimize the
end products' quality. The aim of the quality
assurance process is to provide assurance to climb
senior management and other stakeholders that the
processes and activities used through the
development of your software are designed to
maintain the high quality of the end product.

4. Continuous monitoring
 It involves the continuous monitoring of the
process and making sure that the agreed-upon
standards and procedures are being followed all
along the development process.
5. Unbiased procedures
5. Unbiased procedures
 Software QA also needs to be unbiased and the
Quality Assurance team should be given some
freedom and authority for the process to work
correctly. Through this way, the company's
reputation is also affected, positively if it can
consistently deliver reliable and high-quality
products.

6. Follow two basic principles
 Regardless of what product you're developing,
there are two principles the Quality Assurance
follows. These are "fit for purpose" and "right
first time".
first time".
7. Apply Fit for Purpose
 The "fit for purpose" means that the product does
what it is supposed to do and is suitable for its
intended purpose.

ppppppppppppppppppppppp[;';;;;;;;;;;;;;;;;;;;;;;;;;

ppppppppppppppppppppppp[;';;;;;;;;;;;;;;;;;;;;;;;;;

More Related Content

Similar to ppppppppppppppppppppppp[;';;;;;;;;;;;;;;;;;;;;;;;;;

Recently uploaded

ppppppppppppppppppppppp[;';;;;;;;;;;;;;;;;;;;;;;;;;