PRESIDENCY UNIVERSITY,

BENGALURU

Course Code : CSE3043

Presidency University, Bengaluru

2
What is Test Plan?
• A test plan is a document that consists of all future testing-
related activities.
• The test plan serves as the blueprint that changes
according to the progressions in the project and stays
current at all times.
• It serves as a base for conducting testing activities and
coordinating activities among a QA team.
• It is shared with Business Analysts, Project Managers, and
anyone associated with the project.

3
Factors Roles
• Who writes Test Plans? Test lead, Test Manager, Test
Engineer
• Who reviews the Test Plan? Test Lead, Test Manager,
Test Engineer, Customer, Development Team
• Who approves the Test Plan? Customer, Test Manager
• Who writes Test Cases? Test Lead, Test Engineer
• Who reviews Test Cases? Test Engineer, Test Lead,
Customer, Development Team
• Who approves Test Cases? Test Manager, Test Lead,
Customer

4
Why are Test Plans Important?
• Quick guide for the testing process
• Helps to avoid out-of-scope functionalities
• Helps to determine the time, cost, and effort
• Provide a schedule for testing activities
• Test plan can be reused

5
Objectives of the Test Plan
• Overview of testing activities
• Provides timeline
• Helps to estimate resources
• Serves as a blueprint
• Helps to identify solutions
• Serves as a rulebook: The test plan serves as a rulebook for
following rules when the project is completed phase by phase.

6
 Types of Test Plans
• Master Test Plan: It goes into great depth on the planning and
management of testing at the various test levels and thus provides a
bird’s eye view of the important decisions made, tactics used, etc.
• Phase Test Plan: In this type of test plan, emphasis is on any one phase
of testing. It includes further information on the levels listed in the master
testing plan.
• Specific Test Plan: This type of test plan, is designed for specific types
of testing especially non-functional testing for example plans for
conducting performance tests or security tests.

7
Components and Attributes of Test Plan:

8
1. Objective: It describes the aim of the test plan, whatever the good
process and procedure they are going to follow to give quality software
to customers.
-List all the functionality and performance to be tested.
-Make goals and targets based on the application feature.
2. Scope: It consists of information that needs to be tested concerning an
application. The scope can be divided into two parts:
-In-Scope: The modules that are to be tested rigorously.
-Out Scope: The modules that are not to be tested rigorously.
Example: In an application A, B, C, and D features have to be developed,
but the B feature has already been designed by other companies. So the
development team will purchase B from that company and perform only
integrated testing with A, B, and C.

9
3. Testing Methodology: The methods that are going to be used for testing
depend on application to application. The testing methodology is
decided based on the feature and application requirements.
-Since the testing terms are not standard, one should define what kind of
testing will be used in the testing methodology. So that everyone can
understand it.
4. Approach: The approach of testing different software is different. It deals
with the flow of applications for future reference. It has two aspects:
-High-Level Scenarios: For testing critical features high-level scenarios are
written. For Example, login to a website, and book from a website.
-The Flow Graph: It is used when one wants to make benefits such as
converging and merging easy.

10
5. Assumption: In this phase, certain assumptions will be made.
Example:
The testing team will get proper support from the development team.
-The tester will get proper knowledge transfer from the development team.
-Proper resource allocation will be given by the company to the testing
department.
6. Risk: All the risks that can happen if the assumption is broken. For
Example, in the case of wrong budget estimation, the cost may overrun.
Some reason that may lead to risk is:
-Test Manager has poor management skills.
-Hard to complete the project on time.
-Lack of cooperation.

11
7. Mitigation Plan: If any risk is involved then the company must have a
backup plan, the purpose is to avoid errors. Some points to
resolve/avoid risk:
-Test priority is to be set for each test activity.
-Managers should have leadership skills.
-Training course for the testers.
8. Roles and Responsibilities: All the responsibilities and role of every
member of a particular testing team has to be recorded.
Example:
-Test Manager: Manages the project, takes appropriate resources, and
gives project direction.
-Tester: Identify the testing technique, verify the test approach, and save
project costs.

12
9. Schedule: Under this, it will record the start and end date of every
testing-related activity. For Example, writing the test case date and
ending the test case date.
10. Defect Tracking: It is an important process in software engineering as
lots of issue arises when you develop a critical system for business. If
there is any defect found while testing that defect must be given to the
developer team. There are the following methods for the process of
defect tracking:
-Information Capture: In this, we take basic information to begin the
process.
-Prioritize: The task is prioritized based on severity and importance.
-Communication: Communication between the identifier of the bug and the
fixer of the bug.
-Environment: Test the application based on hardware and software.
Example: The bug can be identified using bug-tracking tools such as Jira,
Mantis, and Trac.

13
11. Test Environments: It is the environment that the testing team will use
i.e. the list of hardware and software, while testing the application, the
things that are said to be tested will be written under this section. The
installation of software is also checked under this.
Example:
-Software configuration on different operating systems, such as Windows,
Linux, Mac, etc.
-Hardware Configuration depends on RAM, ROM, etc.
12. Entry and Exit Criteria: The set of conditions that should be met to start
any new type of testing or to end any kind of testing.
Entry Condition:
-Necessary resources must be ready.
-The application must be prepared.
-Test data should be ready.

14
Exit Condition:
-There should not be any major bugs.
-Most test cases should be passed.
-When all test cases are executed.
Example: If the team member reports that 45% of the test cases failed,
then testing will be suspended until the developer team fixes all defects.

15
13. Test Automation: It consists of the features that are to be automated
and which features are not to be automated.
-If the feature has lots of bugs then it is categorized as Manual Testing.
-If the feature is frequently tested then it can be automated.
14. Effort Estimation: This involves planning the effort that needs to be
applied by every team member.
15. Test Deliverables: It is the outcome from the testing team that is to be
given to the customers at the end of the project.
-Before the testing phase:
Test plan document.
Test case document.
Test design specification.
-During the testing phase:
Test scripts.
Test data.
Error logs. 16
After the testing phase:
-Test Reports.
-Defect Report.
-Installation Report.
-It contains a test plan, defect report, automation report, assumption report,
tools, and other components that have been used for developing and
maintaining the testing effort.
16. Template: This is followed by every kind of report that is going to be
prepared by the testing team. All the test engineers will only use these
templates in the project to maintain the consistency of the product.

17
How to create a Test Plan:

• Below are the eight steps that can be followed to write a test
plan:

18
1. Analyze the product: This phase focuses on analyzing the
product, Interviewing clients, designers, and developers, and
performing a product walkthrough. This stage focuses on
answering the following questions:
-What is the primary objective of the product?
-Who will use the product?
-What are the hardware and software specifications of the
product?
-How does the product work?
2. Design the test strategy: The test strategy document is
prepared by the manager and details the following information:
-Scope of testing which means the components that will be
tested and the ones that will be skipped.
-Type of testing which means different types of tests that will
be used in the project.
19
 -Risks and issues that will list all the possible risks that may
occur during testing.
-Test logistics mentions the names of the testers and the tests
that will be run by them.
3. Define test objectives: This phase defines the objectives and
expected results of the test execution. Objectives include:
-A list of software features like functionality, GUI, performance
standards, etc.
-The ideal expected outcome for every aspect of the software
that needs testing.
4. Define test criteria: Two main testing criteria determine all the
activities in the testing project:
-Suspension criteria: Suspension criteria define the
benchmarks for suspending all the tests.
-Exit criteria: Exit criteria define the benchmarks that signify the
successful completion of the test phase or project.
20
 5. Resource planning: This phase aims to create a detailed list
of all the resources required for project completion. For
example, human effort, hardware and software requirements,
all infrastructure needed, etc.
6. Plan test environment:The test environments must be real
devices, installed with real browsers and operating systems so
that testers can monitor software behavior in real user
conditions.
7. Schedule and Estimation: Break down the project into smaller
tasks and allocate time and effort for each task. This helps in
efficient time estimation. Create a schedule to complete these
tasks in the designated time with a specific amount of effort.
8. Determine test deliverables: Test deliverables refer to the list
of documents, tools, and other equipment that must be
created, provided, and maintained to support testing activities
in the project.

21
• Deliverables required before testing: Test Plan, Test Design
• Deliverables required during testing: Test Scripts, Simulators,
Test data, Error and Execution Logs.
• Deliverables required after testing: Test results, Defect reports,
Release Notes.

22
 Bug Life Cycle in Software Development
What is a Bug/Defect?
• A defect is an error or bug in an application that is created during the
building or designing of software and due to which software starts to
show abnormal behaviors during its use.
What is Defect Life Cycle?
• In the Software Development Process, Defect Life Cycle is the life cycle
of a defect or bug which it goes through covering a specific set of states
in its entire life. Mainly bug life cycle refers to its entire state starting
from a new defect detected to the closing off of that defect by the tester.
Alternatively, it is also called a Bug Life Cycle.
Defect Status
• Defect status or Bug status is the current state from which the defect is
currently going through. The number of states the defect goes through
varies from project to project. The below diagram illustrates all the
possible states of the defect:

23
1. New: When any new defect is identified by the tester, it falls in
the ‘New’ state. It is the first state of the Bug Life Cycle.
2. Assigned: When the defect is assigned to the developer team
the status of the bug changes to the ‘Assigned’ state.
3. Open: In this ‘Open’ state the defect is being addressed by the
developer team and the developer team works on the defect
for fixing the bug. Based on some specific reason if the
developer team feels that the defect is not appropriate then it is
transferred to either the ‘Rejected’ or ‘Deferred’ state.
4. Fixed: After necessary changes of codes or after fixing
identified bug developer team marks the state as ‘Fixed’.
5. Pending Request: During the fixing of the defect is completed,
the developer team passes the new code to the testing team
for retesting. And the code/application is pending for retesting
on the Tester side so the status is assigned as ‘Pending
Retest’.
25
6. Retest: At this stage, the tester starts work of retesting the
defect to check whether the defect is fixed by the developer or
not, and the status is marked as ‘Retesting’.
7. Reopen: After ‘Retesting’ if the tester team found that the bug
continues like previously even after the developer team has
fixed the bug, then the status of the bug is again changed to
‘Reopened’. Once again bug goes to the ‘Open’ state and goes
through the life cycle again. This means it goes for Re-fixing by
the developer team.
8. Verified: The tester re-tests the bug after it got fixed by the
developer team and if the tester does not find any kind of
defect/bug then the bug is fixed and the status assigned is
‘Verified’.
9. Closed: It is the final state of the Defect Cycle, after fixing the
defect by the developer team when testing found that the bug
has been resolved.

26
Defect Lifecycle

27
Consider the flow chart below to understand the defect lifecycle.
• The tester finds a defect.
• The defect status is changed to New.
• The development manager will then analyze the defect.
• The manager determines if the defect is valid or not.
• If the defect is not valid then the development manager
assigns the status Rejected to defect.
• If the defect is valid then it is checked whether the defect is in
scope or not. If no then the defect status is changed to
Deferred.

28
• If the defect is in scope then the manager checks whether a
similar defect was raised earlier. If yes then the defect is
assigned a status duplicate.
• If the defect is not already raised then the manager starts
fixing the code and the defect is assigned the status In-
Progress.
• Once the defect is fixed the status is changed to fixed.
• The tester retests the code if the test is passed then the defect
status is changed to closed.
• If the test fails again then the defect is assigned status
reopened and assigned to the developer.

29