Unit-2

TEST PLANNING
The goal of test Planning, High Level Expectations,
Intergroup Responsibilities, Test Phases, Test Strategy,
Resource Requirements, Tester Assignments, Test
Schedule, Test Cases, Bug Reporting, Metrics and
Statistics.
The goal of Test Planning:
• The test plan is a base of every software's testing. It is the most crucial
activity which ensures availability of all the lists of planned activities
in an appropriate sequence.
• A test plan is a detailed document which describes software testing
areas and activities.
• The test plan is a template for conducting software testing activities as a
defined process that is fully monitored and controlled by the testing
manager.
• The test plan is prepared by the Test Lead (60%), Test
Manager(20%), and by the test engineer(20%).
Goals:
• To reach 100% correct code.
• To identify the test methodologies for Unit and System Testing.
• To provide a procedure for Unit and System Testing.
• To ensure all Functional and Design Requirements are implemented as
clarified in the documentation.
• To identify the documentation process for Testing.
Types:
1. Master Test Plan
2. Phase Test Plan
3. Specific Test Plans
Master test plan:
• Master Test Plan is a type of test plan that has multiple levels of testing.
• It includes a complete test strategy.
Phase test plan:
• It addresses any one phase of the testing strategy.

Specific est plan:

• A specific test plan designed for non-functional testing.

Procedure to write a test plan:

1. First, analyze the product or application structure and architecture.
2. Then design the test strategy.
3. Define all the test objectives.
4. Define the testing area.
5. Define all the useable resources from the document.
6. Schedule all activities in an appropriate manner.
7. And finally determine all the Test Deliverables.
Intergroup Responsibilities
Test lead/manager: A test lead is responsible for:
• Defining the testing activities for subordinates – testers or test engineers.
• To check if the team has all the necessary resources to execute the testing
activities.
• To check if testing is going hand in hand with the software development
in all phases.
• Prepare the status report of testing activities.
• Required Interactions with customers.
• Updating project manager regularly about the progress of testing activities.
Test engineers responsible for:
• To read all the documents and understand what needs to be tested.
• Based on the information procured in the above step decide how it is to be
tested.
• Inform the test lead about what all resources will be required for software
testing.
• Develop test cases and prioritize testing activities.
• Execute all the test case and report defects, define severity and priority for
each defect.
• Carry out regression testing every time when changes are made to the code
to fix defects.
Test Phases:
The main goal of the test phase is to identify and document any defects or
issues in the software application as early as possible in the development
process.
It is an important process that helps to ensure the quality of software
applications and provides a systematic approach to testing.
Requirement Phase: The test team studies the requirements from a testing
point of view to identify testable requirements and the QA team may
interact with various stakeholders to understand requirements in detail.
Requirements could be either functional or non-functional. Automation
feasibility for the testing project is also done in this stage.
Test Planning: It is a phase in which a Senior QA manager determines the
test plan strategy along with efforts and cost estimates for the project.
Moreover, the resources, test environment, test limitations and the testing
schedule are also determined. The Test Plan gets prepared and finalized in
the same phase.
Test Case Development Phase: It involves the creation, verification and
rework of test cases & test scripts after the test plan is ready.

Initially, the Test data is identified then created and reviewed and then
reworked based on the preconditions. Then the QA team starts the
development process of test cases for individual units.
Test Environment: It decides the software and hardware conditions under
which a work product is tested. It is one of the critical aspects of the testing
process and can be done in parallel with the Test Case Development Phase.
The process consists of test script execution, test script maintenance and bug
reporting. If bugs are reported then it is reverted back to development team for
correction and retesting will be performed.

Test Execution Phase: It is carried out by the testers in which testing of

the software build is done based on test plans and test cases prepared.
Test Cycle Closure phase: It is completion of test execution which
involves several activities like test completion reporting, collection of test
completion matrices and test results.
Testing team members meet, discuss and analyze testing artifacts to identify
strategies that have to be implemented in future.
 Test Strategy:
A high-level document is used to validate the test types or levels to be
executed for the product and specify the Software Development Life Cycle's
testing approach is known as Test strategy document.
Once the test strategy has been written, we cannot modify it, and it is approved
by the Project Manager, development team.
The test strategy also specifies the following details,
1. What is the other procedure having to be used?
2. Which module is going to be tested?
3. Which entry and exit criteria apply?
4. Which type of testing needs to be implemented?
 Features of Test Strategy Document:
It includes various significant aspects, such as who will implement the
testing, what will be tested, how it will be succeeded, and what risks and
incidents will be are related to it.
The test strategy document is approved & reviewed by the following's people,
• Test Team Lead
• Development Manager
• Quality Analyst Manager
• Product Manager
For different testing activities, the test strategy document specifies the
resources, scope, plan, methodology, etc.
Primarily, it is obtained from the BRS (Business Requirements
Specifications) documents.
Components of Test Strategy Document:
Scope and Overview:
• The overview of any product contains the information on who should
approve, review and use the document.

• The test strategy document also specified the testing activities and phases
that are needed to be approved.
Testing Methodology:
• which is mainly used to specify the levels of testing, testing procedure,
roles, and responsibilities of all the team members.

• The testing approach also contains the change management process

involving the modification request submission, pattern to be used, and
activity to manage the request.
Testing Environment Specifications:
• This module specifies the information related to the number of
environments and the setup demanded.
• The backup and restore strategies are also offered to ensure that there is no
data loss because of the coding or programming issues.
Testing Tools:
• Testing tools are another vital component of the test strategy document,
as it stipulates the complete information about the test management and
automation tools necessary for test execution activity.
Release Control:
• It is used to ensure that the correct and effective test execution and release
management strategies should be systematically developed.
 Risk Analysis:
• In the test strategy document, all the possible risks are described and
linked to the project, which can become a problem in test execution.
• Furthermore, for inclining these risks, a clear strategy is also formed in
order to make sure that they are undertaking properly.
Review and Approvals:
• When all the related testing activities are specified in the test strategy
document, it is reviewed by the concerned people like:

System Administration Team

Project Management Team
Development Team
Business Team
Resource Requirement:
• Resource requirements are defined by the Project manager to establish
the resources needed to execute the work on the project.

Test Schedule:
A test schedule includes the testing steps or tasks, the target start and end
dates, and responsibilities. It should also describe how the test will be
reviewed, tracked, and approved.
Sample template:
Test Cases:
• The test case is defined as a group of conditions under which a tester
determines whether a software application is working as per the
customer's requirements or not.
• Test case gives detailed information about testing strategy, testing
process, preconditions, and expected output. These are executed during
the testing process to check whether the software application is
performing the task for that it was developed or not.

Why we write the test cases?

• To make sure a better test coverage
• It depends on the process rather than on a person
• To avoid training for every new test engineer on the product
Types of test cases:
1. Function test cases
2. Integration test cases
3. System test cases
The functional test cases:
Firstly, we check for which field we will write test cases and then describe
accordingly.
Integration test case:
In this, we should not write something which we already covered in the
functional test cases, and something we have written in the integration test
case should not be written in the system test case again.
System test cases:
We will write the system test cases for the end-to-end business flows. And we
have the entire modules ready to write the system test cases.
The process of test case: System study

Identfy all test case

scenario

Write test case

Review test case

Fix the review

Test case approval

Store the test case

in repository
System study:
In this, we will understand the application by looking at the requirements or ,
which is given by the customer.
Identify all scenarios:
In this section , we will identify all the possible scenarios of the project we do.
And all the scenarios are documented well for the future use.
Write test case:
Write test cases by applying test case design techniques and use the standard
test case template, which means that the one which is decided for the project.
Review the test cases:
Review the test case by giving it to the head of the team, after that, fix the
review feedback given by the reviewer.
Test case approval:
After fixing the test case based on the feedback, send it again for the approval.
Store in the test case repository:
After the approval of the particular test case, store in the familiar place that is
known as the test case repository.
Bug reporting:
A Bug Report is a detailed document about bugs found in the software
application. Bug report contains each detail about bugs like description, date
when bug was found, name of tester who found it, name of developer who
fixed it, etc. Bug report helps to identify similar bugs in future so it can be
avoided.
Defect_ID: Unique identification number for the defect.
Defect Description: Detailed description of the Defect including information
about the module in which Defect was found.
Version: Version of the application in which defect was found.
Steps: Detailed steps along with screenshots with which the developer can
reproduce the defects.
Date Raised: Date when the defect is raised.
Reference: where you Provide reference to the documents like .
requirements, design, architecture or maybe even screenshots of the
error to help understand the defect
Detected By: Name/ID of the tester who raised the defect
Status: Status of the defect.
Fixed by: Name/ID of the developer who fixed it
Date Closed: Date when the defect is closed
Severity: which describes the impact of the defect on the application
Priority: which is related to defect fixing urgency. Severity Priority could be
High/Medium/Low based on the impact urgency at which the defect should
be fixed respectively
Metrics:
The purpose of software testing metrics is to 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.
Importance of Metrics:
• Test metrics help to determine what types of enhancements are required in
order to create a defect-free, high-quality software product.
• Make informed judgments about the testing phases that follow, such as
project schedule and cost estimates.
• Examine the current technology.
Types of Metrics:
Process Metrics:
A project’s characteristics and execution are defined by process metrics.
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.
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.
Test metrics life cycle:
Analysis:
• Define the QA metrics that have been identified.
Communicate:
• Stakeholders and the testing team should be informed about the
requirement for metrics.
• Educate the testing team on the data points that must be collected in order
to process the metrics.
Evaluation:
• Data should be captured and verified.
• Using the data collected to calculate the value of the metrics
Report:
• Create a strong conclusion for the paper.
• Distribute the report to the appropriate stakeholder and representatives.
• Gather input from stakeholder representatives.
Formula for Test Metrics:
1.Test Case Effectiveness:
Test Case Effectiveness = (Number of defects detected / Number of test
cases run) x 100
2. Passed Test Cases Percentage:
Passed Test Cases Percentage = (Total number of tests ran / Total number of
tests executed) x 100
3.Failed Test Cases Percentage:
Failed Test Cases Percentage = (Total number of failed test cases / Total
number of tests executed) x 100
4. Blocked Test Cases Percentage:
Blocked Test Cases Percentage = (Total number of blocked tests / Total
number of tests executed) x 100
5.Fixed Defects Percentage:
Fixed Defects Percentage = (Total number of flaws fixed / Number of
defects reported) x 100
6. Rework Effort Ratio:
Rework Effort Ratio = (Actual rework efforts spent in that phase/ Total
actual efforts spent in that phase) x 100
7.Accepted Defects Percentage:
Accepted Defects Percentage = (Defects Accepted as Valid by Dev Team /
Total Defects Reported) x 100

8. Defects Deferred Percentage:

Defects Deferred Percentage = (Defects deferred for future releases / Total
Defects Reported) x 100
Example for calculating metrics:

S No Testing Metric Data retrieved during test case development

1. No. of requirements 5
2. The average number of test cases written per requirement 40
3. Total no. of Test cases written for all requirements 200
4. Total no. of Test cases executed 164
5. No. of Test cases passed 100
6. No. of Test cases failed 60
7. No. of Test cases blocked 4
8. No. of Test cases unexecuted 36
9. Total no. of defects identified 20
10. Defects accepted as valid by the dev team 15
11. Defects deferred for future releases 5
12. Defects fixed 12