UNIT –II TEST PLANNING

The Goal of test planning , High level Expectations,Intergroup Responsibilities,Test

phases,Test strategy,Resource requirements,Tester Assignments,Test Schedule,Test case,Bug
reporting,Metrics and statistics

The Goal of Test Planning:

 The main goal of the test plan document is to describe in detail how the testing will be
done for a specific product.
 A test plan is a detailed document which describes software testing areas and activities. It
outlines the test strategy, objectives, test schedule, required resources (human resources,
software, and hardware), test estimation and test deliverables.
 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.
 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%).

Types of Test Plan

There are three types of the test plan
 Master Test Plan
 Phase Test Plan
 Testing Type Specific Test Plans
1. Master Test Plan
Master Test Plan is a type of test plan that has multiple levels of testing. It includes a complete
test strategy.
2. Phase Test Plan
A phase test plan is a type of test plan that addresses any one phase of the testing strategy. For
example, a list of tools, a list of test cases, etc.
3. Specific Test Plans
Specific test plan designed for major types of testing like security testing, load testing,
performance testing, etc. In other words, a specific test plan designed for non-functional testing.
HIGH LEVEL EXPECTATIONS
High Level Test Cases:-
These test cases define the functionality of a software/product in a broader way without going into
deep functionality. Like if we have to write high level test cases for login functionality we’ll test
that ‘User should be able to login success full with valid credentials’.
Advantages :-Its advantage is that a tester is not bound to follow the test cases step by step and
thus it gives a chance to explore more edge cases. This also increases the chance to find new bugs.

Disadvantages:- Its disadvantage is that its not sure that all scenarios are covered and its difficult
for an inexperienced tester to work with these test cases.
 INTERGROUP RESPONSIBILITIES

Software Tester Role

A Software tester (software test engineer) should be capable of designing test suites and should
have the ability to understand usability issues. Such a tester is expected to have sound knowledge
of software test design and test execution methodologies. It is very important for a software
tester to have great communication skills so that he can interact with the development team
efficiently. The roles and responsibilities for a usability software tester are as follows:
1. A Software Tester is responsible for designing testing scenarios for usability testing.
2. He is responsible for conducting the testing, thereafter analyze the results and then submit
his observations to the development team.
3. He may have to interact with the clients to better understand the product requirements or
in case the design requires any kind of modifications.
4. Software Testers are often responsible for creating test-product documentation and also
has to participate in testing related walk through.

Responsibilities of a Test Manager:

− Manage the Testing Department.
− Allocate resource to projects.
− Review weekly Testers' status reports and take necessary actions
− Escalate Testers' issues to the Sr. Management.
− Estimate for testing projects.
− Enforce the adherence to the company's Quality processes and procedures.
− Decision to procure Software Testing tools for the organization.
− Inter group co-ordination between various departments.
− Provide technical support to the Testing team.
− Continuous monitoring and mentoring of Testing team members.
− Review of test plans and test cases.
− Attend weekly meeting of projects and provide inputs from the Testers' perspective.
− Immediate notification/escalation of problems to the Sr. Test Manager / Senior Management.
− Ensure processes are followed as laid down.

Responsibilities of a Test Lead:

− Prepare the Software Test Plan.

− Check / Review the Test Cases document
- System Integration and User Acceptance prepared by test engineers.
− Analyze requirements during the requirements analysis phase of projects.
− Keep track of the new requirements from the Project.
− Forecast / Estimate the Project future requirements.
− Arrange the Hardware and software requirement for the Test Setup.
− Develop and implement test plans.

TEST PHASES

To perform this QA, testers can follow six key phases of the software testing lifecycle.
6 key phases of software testing lifecycle:
Many QA professionals follow well-established software testing lifecycle phases to ensure an
application performs as expected.

1) Requirement Analysis
2) Test Planning
3) Test case development
4) Test case environment
5) Test Execution
6) Test Reporting
1)Requirement Phase Testing also known as Requirement Analysis in which 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.
Activities in Requirement Phase Testing

 Identify types of tests to be performed.

 Gather details about testing priorities and focus.
 Prepare Requirement Traceability Matrix (RTM).
 Identify test environment details where testing is supposed to be carried out.
 Automation feasibility analysis (if required).

Deliverables of Requirement Phase Testing

 RTM
 Automation feasibility report. (if applicable)

2)Test Planning in STLC 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 Planning Activities

 Preparation of test plan/strategy document for various types of testing

 Test tool selection
 Test effort estimation
 Resource planning and determining roles and responsibilities.
 Training requirement

Deliverables of Test Planning

 Test plan/strategy document.

 Effort estimation document.
3) Test Case Development Phase 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 Case Development Activities

 Create test cases, automation scripts (if applicable)

 Review and baseline test cases and scripts
 Create test data (If Test Environment is available)

Deliverables of Test Case Development

 Test cases/scripts
 Test data
4)Test Environment Setup 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. Test team may not be involved in this activity if the
development team provides the test environment. The test team is required to do a readiness
check (smoke testing) of the given environment.
Test Environment Setup Activities

 Understand the required architecture, environment set-up and prepare hardware and
software requirement list for the Test Environment.
 Setup test Environment and test data
 Perform smoke test on the build

Deliverables of Test Environment Setup

 Environment ready with test data set up

 Smoke Test Results.

5) Test Execution Phase is carried out by the testers in which testing of the software build is
done based on test plans and test cases prepared. 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 Activities

 Execute tests as per plan

 Document test results, and log defects for failed cases
 Map defects to test cases in RTM
 Retest the Defect fixes
 Track the defects to closure

Deliverables of Test Execution

 Completed RTM with the execution status

 Test cases updated with results
 Defect reports
6)Test Cycle Closure
Test Cycle Closure phase 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, taking lessons from current test cycle. The idea is to remove process
bottlenecks for future test cycles.

Test Cycle Closure Activities

 Evaluate cycle completion criteria based on Time, Test coverage, Cost,Software, Critical
Business Objectives, Quality
 Prepare test metrics based on the above parameters.
 Document the learning out of the project
 Prepare Test closure report
 Qualitative and quantitative reporting of quality of the work product to the customer.
 Test result analysis to find out the defect distribution by type and severity.

Deliverables of Test Cycle Closure

 Test Closure report

 Test metrics

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, which are necessary while we write the test
document:

o What is the other procedure having to be used?

o Which module is going to be tested?
o Which entry and exit criteria apply?
o Which type of testing needs to be implemented?

OBJECTIVE:

A Test strategy objective is to support various quality assurance stockholders in respect

of planning of resources, language, test and integration levels, traceability, roles and
responsibilities, etc.
 o The test strategy document is approved and reviewed by the following's peoples:
o Test Team Lead
o Development Manager
o Quality Analyst Manager
o Product Manager

Components of Test Strategy Document

o Scope and Overview

o Testing Methodology
o Testing Environment Specifications
o Testing Tools
o Release Control
o Risk Analysis
o Review and Approvals

Scope and Overview

o The first component of the test strategy document is Scope and Overview.
o The overview of any product contains the information on who should approve, review
and use the document.
o The test strategy document also specified the testing activities and phases that are needed
to be approved.
2. Testing Methodology

o The next module in the test strategy document is Testing methodology, which is mainly
used to specify the levels of testing, testing procedure, roles, and responsibilities of all
the team members.
o The testing approach also contains the change management process involving the
modification request submission, pattern to be used, and activity to manage the request.
o Above all, if the test strategy document is not established appropriately, then it might lead
to errors or mistakes in the future.

3. Testing Environment Specifications

o Another component of the test strategy document is Testing Environment

Specification.
o As we already aware of the specification of the test datarequirements is exceptionally
significant. Hence, clear guidelines on how to prepare test data are involved in the testing
environment specification of the test strategy document.

4. Testing Tools

o 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.;
o For security, performance, load testing, the necessary methodologies, and tools are
defined by the details of the open-source or commercial tool and the number of users
that can be kept by it.

5. Release Control

o Another important module of the test strategy document is Release Control.

o It is used to ensure that the correct and effective test executionand release management
strategies should be systematically developed.

6. Risk Analysis

o The next component of the test strategy document is Risk Analysis.

o In the test strategy document, all the possible risks are described linked to the project,
which can become a problem in test execution.
o Furthermore, for inclining these risks, a clear strategy is also formed in order to make
sure that they are undertaking properly.
o We also create a contingency plan if the development team faces these risks in real-time.
7. Review and Approvals

o The last component of the Testing strategy document is Review and Approval.
o When all the related testing activities are specified in the test strategy document, it is
reviewed by the concerned people like:
o System Administration Team
o Project Management Team
o Development Team
o Business Team
o Together with the correct date, approver name, comment, andsummary of the
reviewed variations should be followed while starting the document.
o Likewise, it should be constantly reviewed and updated with the testing process
improvements.

o Methodical strategy
o Reactive strategy
o Analytical strategy
o Standards compliant or Process compliant strategy
o Model-based strategy
o Regression averse strategy
o Consultative strategy

RESOURCE REQUIREMENTS
 Resource requirement 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 requirement and 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.
Some of the following factors need to be considered:
 Machine configuration (RAM,processor,disk)needed to run the product under test.
 Overheads required by test automation tools, if any
 Supporting tools such as compilers, test data generators, configuration management tools.
 The different configurations of the supporting software(e.g. OS)that must be present
 Special requirements for running machine-intensive tests such as load tests and
performance tests.
 Appropriate number of licenses of all the software
Tester Assignments

a)Test Schedule
b)Test plan (Master test plan, Phase test plan, specific test plan)
c)Test case
d)Bug reporting
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.

It is used to explain the timing to work, which needs to be done or this attribute covers
when exactly each testing activity should start and end? And the exact data is also
mentioned for every testing activity for the particular date.
 Therefore as we can see in the below image that for the particular
activity, there will be a starting date and ending date; for each testing to a
specific build, there will be the specified date.

For example

1)Writing test cases 2) Execution process

Sample Test Schedule Template

Test Schedule ID: Describe the Test Schedule ID

Product ID / Describe the Name of the Product / Project

Name:

Product Version Describe the Current Version or Build of the

or Build: Product

Present Owner : Describe the Name of the owner of the Test

Schedule Document at present.

Created On: Describe the Date on which Test Schedule

Document was created initially

Review On: Describe the Date on which Test Schedule

Document was last Reviewed & Updated

Review By: Describe the Name & Position of the Reviewer.

Review Describe the Comments if any, whether

Comments: comments have been incorporated or Not

Current Version: Describe the Current Version of the Test

Schedule Document

Change Details: Describe the Description of Change, Affected

Section of the Test Plan

Current Status: Draft / In Process / Approved

Signing Off Name Position Signature

Authority: , Date
 Describe E.g. QA Manager,
the Name Dev. Manager,
Product Manager,
Release Team
Manager

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 designing
includes preconditions, case name, input conditions, and expected result. A test case is a first
level action and derived from test scenarios.


 It is an in-details document that contains all possible inputs (positive as well as negative)
and the navigation steps, which are used for the test execution process. Writing of test
cases is a one-time attempt that can be used in the future at the time of regression testing.
 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.
 Test case helps the tester in defect reporting by linking defect with test case ID. Detailed
test case documentation works as a full proof guard for the testing team because if
developer missed something, then it can be caught during execution of these full-proof
test cases.
 To write the test case, we must have the requirements to derive the inputs, and the test
scenarios must be written so that we do not miss out on any features for testing. Then we
should have the test case template to maintain the uniformity, or every test engineer
follows the same approach to prepare the test document.
 Generally, we will write the test case whenever the developer is busy in writing the code.

When do we write a test case?

We will write the test case when we get the following:

o When the customer gives the business needs then, the developer
starts developing and says that they need 3.5 months to build this
product.
 o And In the meantime, the testing team will start writing the test
cases.
o Once it is done, it will send it to the Test Lead for the review process.
o And when the developers finish developing the product, it is handed
over to the testing team.

TEST CASE TEMPLATE :

The primary purpose of writing a test case is to achieve the efficiency of the
application.

Types of test cases

We have a different kind of test cases, which are as follows:

o Function test cases

o Integration test cases
o System test cases

Bug Reporting in software testing

  A Bug Report in Software Testing is a detailed document about bugs found in the
software application.
 Bug report contains each detail about bugs like description, date when bug was found,
name of tester who found it, name of developer who fixed it, etc.
 Bug report helps to identify similar bugs in future so it can be avoided.
While reporting the bug to developer, your Bug Report should contain the following information

 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 in 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 , more on this later

 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

Bug Tracking Tools:

 1) JIRA: It is a tracking tool for manual testing.Atlassian is the owner of this tool.
Organisation such as NASA,Twitter are using this tool for bug tracking and
reporting.
2) Bugzilla:It is a popular bug tracking tool with a web based interface.

3) Trac: It is a web based ,,open source tool specialized for issue tracking and
project management.

4) Redmine: It is an issue tracking tool that provides solutions for bugs and d
defects. It has several integrations with source code management systems (eg
GIT,CVS) .It supports different platforms and databases.

5) Backlog: This bug tracking tools offers software development with effective
bug-capturing and tracking activities.

METRICS AND STATISTICS

 Metric is a quantitative measure of the degree to which a system, system

component, or process possesses a given attribute.
 Metrics can be defined as “STANDARDS OF MEASUREMENT”.
 Software Metrics are used to measure the quality of the project. Simply, a Metric is a
unit used for describing an attribute. Metric is a scale for measurement.

Suppose, in general, “Kilogram” is a metric for measuring the attribute “Weight”. Similarly, in
software, “How many issues are found in a thousand lines of code?”, here No. of issues is one
measurement & No. of lines of code is another measurement. Metric is defined from these
two measurements.

Test metrics example:

 How many defects exist within the module?
 How many test cases are executed per person?
 What is Test coverage %?

What Is Software Test Measurement?

  Measurement is the quantitative indication of extent, amount, dimension, capacity,
or size of some attribute of a product or process.
 Test Measurement example: Total number of defects.
Why Test Metrics?
Generation of Software Test Metrics is the most important responsibility of the Software Test
Lead/Manager.

Test Metrics are used to,

1. Take the decision for the next phase of activities such as, estimate the cost & schedule of
future projects.
2. Understand the kind of improvement required to success the project
3. Take a decision on the Process or Technology to be modified etc.

Importance of Software Testing Metrics:

As explained above, Test Metrics are the most important to measure the quality of the software.

Now, how can we measure the quality of the software by using Metrics?
Suppose, if a project does not have any metrics, then how the quality of the work done by a Test
Analyst will be measured?

For Example, A Test Analyst has to,

1. Design the test cases for 5 requirements
2. Execute the designed test cases
3. Log the defects & need to fail the related test cases
4. After the defect is resolved, we need to re-test the defect & re-execute the corresponding
failed test case.
In the Test Report, we can publish:
1. How many test cases have been designed per requirement?
2. How many test cases are yet to design?
3. How many test cases are executed?
4. How many test cases are passed/failed/blocked?
5. How many test cases are not yet executed?
6. How many defects are identified & what is the severity of those defects?
7. How many test cases are failed due to one particular defect? etc.
Based on the project needs we can have more metrics than an above-mentioned list, to know the
status of the project in detail.

Based on the above metrics, the Test Lead/Manager will get the understanding of the below
mentioned key points.
 %ge of work completed
 %ge of work yet to be completed
 Time to complete the remaining work
 Whether the project is going as per the schedule or lagging? etc.
Types Of Test Metrics:
Product Metrics
Product metrics are those which are used to build the artifacts, i.e.,
requirement specification documents, system design documents, etc. These
metrics help in the assessment if the product is right sufficient through
records on attributes like usability, reliability, maintainability & portability. In
these measurements are taken from the actual body of the source code.

2.Project Metrics
Project metrics define project characteristics and execution. If there is proper
management of the project by the programmer, then this helps us to achieve
better products. A relationship exists between the development process and
the ability to complete projects on time and within the desired quality
objectives. Cost increase when developers use inadequate methods. Higher
reliability can be achieved by using a better development process, risk
management process, configuration management process.

These metrics are:

 o Number of software developers
o Staffing pattern over the life-cycle of the software
o Cost and schedule
o Productivity

3.Process Metrics
Process metrics quantify useful attributes of the software development
process & its environment. They tell if the process is functioning optimally as
they report on characteristics like cycle time & rework time. The goal of
process metric is to do the right job on the first time through the process.
The quality of the product is a direct function of the process. So process
metrics can be used to estimate, monitor, and improve the reliability and
quality of software. Process metrics describe the effectiveness and quality of
the processes that produce the software product.

Examples are:

o The effort required in the process

o Time to produce the product
o Effectiveness of defect removal during development
o Number of defects found during testing
o Maturity of the process