Unit Lecture

2 8
No No
Topic The Goal of Test Planning, High Level Expectations
Bloom’sKnowledge
Learning Outcome (LO) At the end of this lecture, students will be able to
Level
LO1 Identify the objective of Test planning. K2
LO2 Analyse the need for Test plan. K2
LO3 Describe the expectations of test planning. K2

The Goal of Test Planning, High Level Expectations

In successful testing, a test plan plays a very important role.
A test plan is a document that consists of all future testing-related activities. It is prepared at the
project level and in general, it defines work products to be tested, how they will be tested, and test
type distribution among the testers. Before starting testing there will be a test manager who will
be preparing a test plan. In any company whenever a new project is taken up before the tester is
involved in the testing the test manager of the team would prepare a test Plan.
 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.

The following are some of the key benefits of making a test plan:
 Quick guide for the testing process: The test plan serves as a quick guide for the testing
process as it offers a clear guide for QA engineers to conduct testing activities.
 Helps to avoid out-of-scope functionalities: The test plan offers detailed aspects such as test
scope, test estimation, strategy, etc.
 Helps to determine the time, cost, and effort: The Test serves as the blueprint to conduct
testing activities thus it helps to deduce an estimate of time, cost, and effort for the testing
activities.
 Provide a schedule for testing activities: A test plan is like a rule book that needs to be
followed, it thus helps to schedule activities that can be followed by all the team members.
 Test plan can be reused: The test plan documents important aspects like test estimation, test
scope, and test strategy which are reviewed by the Management Team and thus can be reused
for other projects.
Objectives of the Test Plan:
1. Overview of testing activities: The test plan provides an overview of the testing activities
and where to start and stop the work.
2. Provides timeline: The test plan helps to create the timeline for the testing activities based on
the number of hours and the workers needed.
3. Helps to estimate resources: The test plan helps to create an estimate of the number of
resources needed to finish the work.
4. Serves as a blueprint: The test plan serves as a blueprint for all the testing activities, it has
every detail from beginning to end.
5. Helps to identify solutions: A test plan helps the team members They consider the project’s
challenges and identify the solutions.
6. Serves as a rulebook: The test plan serves as a rulebook for following rules when the project
is completed phase by phase.
Types of Test Plans:
The following are the three types of test plans:
 Master Test Plan: In this type of test plan, includes multiple test strategies and has multiple
levels of testing. 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. It includes a list of tests that must be executed, test coverage, the connection
between various test levels, 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. Information like testing
schedules, benchmarks, activities, templates, and other information that is not included in the
master test plan is included in the phase test 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.

Components and Attributes of Test Plan :

There is no hard and fast rule for preparing a test plan but it has some standard 15 attributes that
companies follow:
[Link]: 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. The overall objective of the test is to
find as many defects as possible and to make software bug-free. The test objective must be broken
into components and sub-components. In every component following activities should be
performed.
 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.
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.
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.
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.
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.
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.
Exit Condition:
 There should not be any major bugs.
 Most test cases should be passed.
 When all test cases are executed.
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.
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.

Assessment questions to the lecture

Bloom’s
Qn. No. Question Answer Knowledge
Level
The test plan serves as the _________that changes
according to the progressions in the project and stays
1 blueprint K2
current at all times.

Which is not a method of defect tracking?

a. Information Capture: In this, we take basic
information to begin the process.
b. Prioritize: The task is prioritized based on severity
2 d K2
and importance.
c. Communication: Communication between the
identifier of the bug and the fixer of the bug.
d. Analysis: Requirement analysis

Students have to prepare answers for the following questions at the end of the lecture
Bloom’s
Mark
Qn. No Question CO Knowledge
s
Level
1 What are the objectives of test plan? 2 1 K1
 2 List the types of test plan. 2 1 K1
3 When is defect tracking needed? 2 1 K2
4 Describe the goal of test planning in detail. 13 1 K2

Reference Book

Author(s) Title of the book Page numbers

Yogesh Singh “Software Testing”, Cambridge University Press, 2012 37-100

Unit Lecture
2 9
No No
Topic Intergroup Responsibilities, Test Phases
Bloom’sKnowledge
Learning Outcome (LO) At the end of this lecture, students will be able to
Level
LO1 Identify the members and responsibilities of testing group. K2
LO2 Describe the phases of testing. K2

Popular Software Testing Roles & Responsibilities

The term comes from the manufacturing industry. QC in the

software industry is responsible for testing new products and
determining whether those products meet business
Quality Control Engineer
requirements in reliability and functionality. Implements the
test program established by QA procedures, testing efforts are
concentrated on finding defects.

Determines test procedures that can enable to test of a

particular software app in the beat particular manner.
Designing test suites, create test cases and test documentation.
Quality Assurance Engineer Executes all levels of testing. Run tests according to the test
standards within various testing techniques. Analyzes and
reports test results. To help troubleshoot errors, before the
product will be pushed into production.

Test Analyst Focuses on the business problem. Should have the ability to
see the big picture, good planning and organizational skills.
Analyzes requirements and acceptance criteria, designes
software testing documentation including test plans, links tests
 to req, run tests, analyzes and documents results.

Involved in all (SDLC) phases of an IT project where they can

improve all needed aspects of software development. They
ought to be interested in the current trend in software
Test Consultant
development (including Agile and DevOps). Should own an
analytical mindset and of course excellent communication
skills.

Primarily is focused on coding test framework and then

quality. Set up a test environment, and develops test scripts
Test Automation Engineer
using the testing tools like Selenium, Codecept or others to
design and run automated test cases.

Works with the project infrastructure, prepares test strategy

and implements test automation tools to support product code
Test Architect and test code. Sometimes performs low-level testing like unit
testing, module testing, performance testing, acceptance
testing. Should have strong knowledge of backend services.

QA manager acts a little like a project manager. Design test

Test Manager strategy, organize test processes, track test progress and
supervises the teamwork through test planning.

One senior manager who manages Test managers. Should set

QA strategy and approach for all the company`s products and
Director of test be ultimately responsible for quality. Guarantee the success of
manual and automation testing efforts of all testing teams in
the organization.
TESTing PHASES
Software Testing Life Cycle (STLC)
The Software Testing Life Cycle (STLC) is a systematic approach to testing a software
application to ensure that it meets the requirements and is free of defects. It is a process that
follows a series of steps or phases, and each phase has specific objectives and deliverables. The
STLC is used to ensure that the software is of high quality, reliable, and meets the needs of the
end-users.
The main goal of the STLC is to identify and document any defects or issues in the software
application as early as possible in the development process. This allows for issues to be addressed
and resolved before the software is released to the public.
The stages of the STLC include Test Planning, Test Analysis, Test Design, Test Environment
Setup, Test Execution, Test Closure, and Defect Retesting. Each of these stages includes specific
activities and deliverables that help to ensure that the software is thoroughly tested and meets the
requirements of the end users.
Characteristics of STLC
 STLC is a fundamental part of the Software Development Life Cycle (SDLC) but STLC
consists of only the testing phases.
 STLC starts as soon as requirements are defined or software requirement document is shared
by stakeholders.
 STLC yields a step-by-step process to ensure quality software.
Phases of STLC
1. Requirement Analysis: Requirement Analysis is the first step of the Software Testing Life
Cycle (STLC). In this phase quality assurance team understands the requirements like what is to
be tested. If anything is missing or not understandable then the quality assurance team meets with
the stakeholders to better understand the detailed knowledge of requirements.
The activities that take place during the Requirement Analysis stage include:
 Reviewing the software requirements document (SRD) and other related documents
 Interviewing stakeholders to gather additional information
 Identifying any ambiguities or inconsistencies in the requirements
 Identifying any missing or incomplete requirements
 Identifying any potential risks or issues that may impact the testing process
Creating a requirement traceability matrix (RTM) to map requirements to test cases
At the end of this stage, the testing team should have a clear understanding of the software
requirements and should have identified any potential issues that may impact the testing process.
This will help to ensure that the testing process is focused on the most important areas of the
software and that the testing team is able to deliver high-quality results.
2. Test Planning: Test Planning is the most efficient phase of the software testing life cycle
where all testing plans are defined. In this phase manager of the testing, team calculates the
estimated effort and cost for the testing work. This phase gets started once the requirement-
gathering phase is completed.
The activities that take place during the Test Planning stage include:
 Identifying the testing objectives and scope
 Developing a test strategy: selecting the testing methods and techniques that will be used
 Identifying the testing environment and resources needed
 Identifying the test cases that will be executed and the test data that will be used
 Estimating the time and cost required for testing
 Identifying the test deliverables and milestones
 Assigning roles and responsibilities to the testing team
 Reviewing and approving the test plan
At the end of this stage, the testing team should have a detailed plan for the testing activities that
will be performed, and a clear understanding of the testing objectives, scope, and deliverables.
This will help to ensure that the testing process is well-organized and that the testing team is able
to deliver high-quality results.
3. Test Case Development: The test case development phase gets started once the test planning
phase is completed. In this phase testing team notes down the detailed test cases. The testing team
also prepares the required test data for the testing. When the test cases are prepared then they are
reviewed by the quality assurance team.
 Identifying the test cases that will be developed
 Writing test cases that are clear, concise, and easy to understand
 Creating test data and test scenarios that will be used in the test cases
 Identifying the expected results for each test case
 Reviewing and validating the test cases
 Updating the requirement traceability matrix (RTM) to map requirements to test cases
4. Test Environment Setup: Test environment setup is a vital part of the STLC. Basically, the
test environment decides the conditions on which software is tested. This is independent activity
and can be started along with test case development. In this process, the testing team is not
involved. either the developer or the customer creates the testing environment.
5. Test Execution: After the test case development and test environment setup test execution
phase gets started. In this phase testing team starts executing test cases based on prepared test
cases in the earlier step.
The activities that take place during the test execution stage of the Software Testing Life
Cycle (STLC) include:
 Test execution: The test cases and scripts created in the test design stage are run against the
software application to identify any defects or issues.
 Defect logging: Any defects or issues that are found during test execution are logged in a
defect tracking system, along with details such as the severity, priority, and description of the
issue.
 Test data preparation: Test data is prepared and loaded into the system for test execution
 Test environment setup: The necessary hardware, software, and network configurations are
set up for test execution
 Test execution: The test cases and scripts are run, and the results are collected and analyzed.
 Test result analysis: The results of the test execution are analyzed to determine the
software’s performance and identify any defects or issues.
 Defect retesting: Any defects that are identified during test execution are retested to ensure
that they have been fixed correctly.
 Test Reporting: Test results are documented and reported to the relevant stakeholders.
It is important to note that test execution is an iterative process and may need to be repeated
multiple times until all identified defects are fixed and the software is deemed fit for release.
6. Test Closure: Test closure is the final stage of the Software Testing Life Cycle (STLC) where
all testing-related activities are completed and documented. The main objective of the test closure
stage is to ensure that all testing-related activities have been completed and that the software is
ready for release.
At the end of the test closure stage, the testing team should have a clear understanding of the
software’s quality and reliability, and any defects or issues that were identified during testing
should have been resolved. The test closure stage also includes documenting the testing process
and any lessons learned so that they can be used to improve future testing processes

Assessment questions to the lecture

Bloom’s
Qn. No. Question Answer Knowledge
Level
Who is not involved in Testing team?
Test Manager
Test
1 Test Analyst K2
Designer
Test automation engineer
Test designer
Test consultant Involved in all (SDLC) phases of an IT
2 True K2
project. (True /False)
Identify which of the following life cycle contains the
phases: test case design, test execution, defect tracking,
maintenance.
3  SDLC STLC K2
 STLC
 SQLC
 BLC
Identify the incorrect phase of STLC(Software Testing
Life cycle).
 Test closure
4 CODING K2
 Coding
 Requirement analysis
 Test planning
ITG stands for
a) instantaneous test group
5 b) integration testing group d K2
c) individual testing group
d) independent test group

Students have to prepare answers for the following questions at the end of the lecture
Bloom’s
Mark
Qn. No Question CO Knowledge
s
Level
1 Who are all involved in testing process? 2 2 K1
2 List the types of test plan. 2 2 K1
3 When is defect tracking needed? 2 2 K2
4 Describe the goal of test planning in detail. 13 2 K2
5 List the characteristics of STLC. 2 2 K1
6 Describe in detail about the Testing phases. 13 2 K2
Reference Book

Author(s) Title of the book Page numbers

Yogesh Singh “Software Testing”, Cambridge University Press, 2012 232-270

Unit Lecture
2 10
No No
Topic Test Strategy, Resource Requirements
Bloom’sKnowledge
Learning Outcome (LO) At the end of this lecture, students will be able to
Level
LO1 Explain the testing strategy K2
LO2 Differentiate Test Strategy and Test Plan K2
LO3 Identify the Resource requirements for testing K2

Test Strategy
A test strategy is a plan for defining an approach to the Software Testing Life Cycle (STLC)
What is a Test Strategy Document?
A test strategy document is a well-described document that is derived from actual business
requirements that guide the whole team about the software testing approach and objectives for
each activity in the software testing process.
 The test strategy document is approved and reviewed by the test team lead, development
manager, quality analyst manager, and product manager.
 The test strategy document specifies the resources, scope, plan, and methodology for different
testing activities.
 It answers all the questions like what needs to get done, how to accomplish it, etc.
Components of a Test Strategy
The test effort, test domain, test setups, and test tools used to verify and validate a set of functions
are all outlined in a Test Strategy. It also includes schedules, resource allocations, and employee
utilization information. This data is essential for the test team (Test) to be as structured and
efficient as possible. A Test Strategy differs from a Test Plan, which is a document that gathers
and organizes test cases by functional areas and/or types of testing in a format that can be
presented to other teams and/or customers. Both are critical components of the Quality Assurance
process since they aid in communicating the breadth of the test method and ensuring test coverage
while increasing the testing effort’s efficiency.
1. Scope and Overview: Scope and Overview is the first section of the test strategy paper. Any
product’s overview includes information about who should approve, review, and use the
document. The testing activities and phases that must be approved were also described in the test
strategy paper.
 An overview of the project, as well as information on who should utilize this page.
 Include information such as who will evaluate and approve the document.
 Define the testing activities and phases that will be performed, as well as the timetables that
will be followed in relation to the overall project timelines stated in the test plan.
2. Testing Methodology: Testing methodology is the next module in the test strategy document,
and it is used to specify the degrees of testing, testing procedures, roles, and duties of all team
members. The change management process, which includes the modification request submission,
pattern to be utilized, and activity to manage the request, is also included in the testing strategy.
Above all, if the test plan document is not properly established, it may result in future errors or
blunders. This module is used to specify the following information-
 Define the testing process, testing level, roles, and duties of each team member.
 Describe why each test type is defined in the test plan (for example, unit, integration, system,
regression, installation/uninstallation, usability, load, performance, and security testing)
should be performed, as well as details such as when to begin, test owner, responsibilities,
testing approach, and details of automation strategy and tool (if applicable).
3. Testing Environment Specifications: Testing Environment Specification is another section of
the test strategy paper. The specification of the test data requirements, as we well know, is quite
important. As a result, the testing environment specification in the test strategy document includes
clear instructions on how to produce test data. This module contains information on the number of
environments and the required setup. The strategies for backup and restoration are equally
important.
 The information about the number of environments and the needed configuration for each
environment should be included in the test environment setup.

 For example, the functional test team might have one test environment and the UAT team
might have another.
 Define the number of users supported in each environment, as well as each user’s access roles
and software and hardware requirements, such as the operating system, RAM, free disc space,
and the number of systems.
 It’s just as crucial to define the test data needs.
 Give specific instructions on how to generate test data (either generate data or use production
data by masking fields for privacy).
 Define a backup and restoration strategy for test data.
 Due to unhandled circumstances in the code, the test environment database may encounter
issues.
 The backup and restoration method should state who will take backups when backups should
be taken, what should be included in backups, when the database should be restored, who will
restore it, and what data masking procedures should be implemented if the database is
restored.
4. Testing Tools: Testing tools are an important part of the test strategy document since it
contains all of the information on the test management and automation tools that are required for
test execution. The necessary approaches and tools for security, performance and load testing are
dictated by the details of the open-source or commercial tool and the number of users it can
support.
 Define the tools for test management and automation that will be utilized to execute the tests.
 Describe the test approach and tools needed for performance, load, and security testing.
 Mention whether the product is open-source or commercial, as well as the number of
individuals it can accommodate, and make suitable planning.
5. Release Control: Release Control is a crucial component of the test strategy document. It’s
used to make sure that test execution and release management strategies are established in a
systematic way. It specifies the following information-
 Different software versions in test and UAT environments can occur from unplanned release
cycles.
 All adjustments in that release will be tested using the release management strategy, which
includes a proper version history.
 Set up a build management process that answers questions like where the new build should be
made available, where it should be deployed when to receive the new build, where to acquire
the production build, who will give the go signal for the production release, and so on.
6. Risk Analysis: Risk Analysis is the next section of the test strategy paper. All potential hazards
associated with the project are described in the test strategy document and can become an issue
during test execution. Furthermore, a defined strategy is established for inclining these risks in
order to ensure that they are carried out appropriately. If the development team is confronted with
these hazards in real-time, we establish a contingency plan. Make a list of all the potential
dangers. Provide a detailed plan to manage these risks, as well as a backup plan in case the
hazards materialize.
7. Review and Approval: Review and Approval is the last section of the Testing strategy paper.
When all of the testing activities are stated in the test strategy document, it is evaluated by the
persons that are involved, such as:
 System Administration Team.
 Project Management Team.
 Development Team.
 Business Team.
Starting the document with the right date, approver name, comment, and summary of the
reviewed modifications should be followed.
It should also be evaluated and updated on a regular basis as the testing procedure improves.
Test Strategy vs Test Plan
Below are the differences between Test Strategy and Test Plan:
S
No. Test Plan Test Strategy

It’s developed from a set of software It comes from a Business Requirement

1.
requirements (SRS). paper (BRS).

The test lead or manager is in charge of The project manager or the business
2.
preparing it. analyst creates it.

The test plan’s components include the test The components of a test strategy include
plan’s id, features to be tested, test techniques, objectives and scope, documentation
3. testing tasks, features pass or fail criteria, test formats, test processes, team reporting
deliverables, responsibilities, and timetable, structure, client communication strategy,
among others. and so on.

After the requirements have been approved, The test strategy comes first, followed by
4.
the test plan is written. the test plan.

The test plan should be simple and The test approach serves as a general
5.
straightforward. guide for the project at hand.

Types of Test Strategies

The following are the different types of test strategies:
1. Analytical strategy: For instance, risk-based testing and requirements-based testing are two
types of testing. After examining the test premise, such as risks or requirements, the testing
team sets the testing circumstances to be covered. In the instance of requirements-based
testing, the requirements are examined to determine the test circumstances. Then tests are
created, implemented, and run to ensure that the requirements are met. Even the findings are
kept track of in terms of requirements, such as those who were tested and passed, those that
were tested but failed, those that were not fully tested, and so on.
2. Model-based strategy: The testing team selects an actual or anticipated circumstance and
constructs a model for it, taking into account inputs, outputs, processes, and possible
behaviour. Models are also created based on existing software, technology, data speeds,
 infrastructure, and other factors. Let’s look at a case where you’re testing a mobile app.
Models to simulate outgoing and receiving traffic on a mobile network, the number of
active/inactive users, predicted growth, and other factors may be constructed to conduct
performance testing.
3. Methodical strategy: In this case, test teams adhere to a quality standard (such as ISO25000),
checklists, or just a set of test circumstances. Specific types of testing (such as security) and
application domains may have standard checklists. For example, while performing
maintenance testing, a checklist describing relevant functions, their properties, and so on is
sufficient.
4. Standards or process-compliant strategy: This method is well-exemplified by medical
systems that adhere to US Food and Drug Administration (FDA) guidelines. The testers
follow the methods or recommendations established by the standards committee or a panel of
enterprise specialists to determine test conditions, identify test cases, and assemble the testing
team. In the case of an Agile program, testers will create a complete test strategy for each user
story, starting with establishing test criteria, developing test cases, conducting tests, reporting
status, and so on.
5. Reactive strategy: Only when the real program is released are tests devised and implemented.
As a result, testing is based on faults discovered in the real system. Consider the following
scenario: you’re conducting exploratory testing. Test charters are created based on the features
and functionalities that already exist. The outcomes of the testing by testers are used to update
these test charters. Agile development initiatives can also benefit from exploratory testing.
6. Consultative strategy: In the same way, that user-directed testing uses input from key
stakeholders to set the scope of test conditions, this testing technique does as well. Let’s
consider a scenario in which the browser compatibility of any web-based application is being
evaluated. In this section, the app’s owner would provide a list of browsers and their versions
in order of preference. They may also include a list of connection types, operating systems,
anti-malware software, and other requirements for the program to be tested against.
Depending on the priority of the items in the provided lists, the testers can use various
strategies such as pairwise or equivalence splitting.
7. Regression-averse strategy: In this case, the testing procedures are aimed at lowering the
risk of regression for both functional and non-functional product aspects. Using the web
application as an example, if the program needs to be tested for regression issues, the testing
team can design test automation for both common and unusual use cases. They can also
employ GUI-based automation tools to conduct tests every time the application is updated.
Any of the strategies outlined above does not have to be used for any testing job. Two or more
strategies may be integrated depending on the needs of the product and the organization.
Test Strategy Selection
The following factors may influence the test approach selection:
 The test strategy chosen is determined by the nature and size of the organization.
 One can choose a test strategy based on the project needs; for example, safety and security
applications necessitate a more rigorous technique.
 The test strategy can be chosen based on the product development model.
 Is this a short-term or long-term strategy?
 Organization type and size.
 Project requirements, Safety and security applications necessitate a well-thought-out strategy.
 Product development model.
Assessment questions to the lecture

Bloom’s
Qn. No. Question Answer Knowledge
Level
Software Debugging is a set of activities that can be
planned in advance and conducted systematically.
1 b) K2
a) True
b) False
Which of the following is not a software testing generic
characteristics?
a) Different testing techniques are appropriate at different
points in time
2 b) Testing is conducted by the developer of the software or a) K2
an independent test group
c) Testing and debugging are different activities, but
debugging must be accommodated in any testing strategy
d) None of the mentioned
By collecting ________ during software testing, it is
3 possible to develop meaningful guidelines to halt the testing Metrics K2
process.
Which of the following issues must be addressed if a
successful software testing strategy is to be implemented?
a) Use effective formal technical reviews as a filter prior to
testing
4 d) K2
b) Develop a testing plan that emphasizes “rapid cycle
testing.”
c) State testing objectives explicitly
d) All of the mentioned

Students have to prepare answers for the following questions at the end of the lecture
Bloom’s
Mark
Qn. No Question CO Knowledge
s
Level
1 What is testing strategy? 2 2 K1
2 List the types of test plan. 2 2 K1
3 What are the factors that influence the test approach 2 2 K2
selection?
4 Differentiate Test Strategy and Test plan. 2 2 K2
5 State the requirements of Test plan. 2 2 K1
6 Describe in detail about the Testing Strategy. 13 2 K2
Reference Book

Author(s) Title of the book Page numbers

Yogesh Singh “Software Testing”, Cambridge University Press, 2012 232-270
 Unit Lecture
2 11
No No
Topic Tester Assignments, Test Schedule, Test Cases
Bloom’sKnowledge
Learning Outcome (LO) At the end of this lecture, students will be able to
Level
LO1 Define the Tester assignments. K2
LO2 Prepare the test schedule. K2
LO3 Find out the Test cases of the program to be tested and evaluate the K4
program.

Tester Assignments

The Test Assignment view is the second view of the Manual Execution Planning page. Here you
can organize the manual tests that are assigned to the selected testing cycle. Testing Cycles. A
testing cycle is a defined period in time consisting of a start date, an end date, and a list of manual
testers.

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.

Test scheduling: Test scheduling is the process of defining the timeline for the testing effort. It
involves determining when each test will be executed, who will execute it, and how long it is
expected to take. Test scheduling also includes any dependencies or constraints that may impact the
testing timeline.
 Test Case
A test case refers to the actions required to verify a specific feature or functionality in software
testing. The test case details the steps, data, prerequisites, and postconditions necessary to verify a
feature.
A test suite is a collection of test cases that are grouped for test execution purposes.
The Objective of Writing Test Cases in Software Testing
 To validate specific features and functions of the software.
 To guide testers through their day-to-day hands-on activity.
 To record a catalog of steps undertaken, which can be revisited in the event of a bug popping up.
 To provide a blueprint for future projects and testers so they don’t have to start work from scratch.
 To help detect usability issues and design gaps early on.
 To help new testers and devs quickly pick up testing, even if they join in the middle of an ongoing
project.
Standard Test Case Format
 Test Case ID
 Test Scenario
 Test Steps
 Prerequisites
 Test Data
 Expected/Intended Results
 Actual Results
 Test Status – Pass/Fail
How to write Test Cases (Test Case Example)
Let’s build a test case example based on a specific scenario. Here is a sample case.
 Test Case ID: #BST001
 Test Scenario: To authenticate a successful user login on [Link]
 Test Steps:
o The user navigates to [Link].
o The user enters a registered email address in the ’email’ field.
o The user clicks the ‘Next’ button.
o The user enters the registered password.
o The user clicks ‘Sign In.’
 Prerequisites: A registered Gmail ID with a unique username and password.
 Browser: Chrome v 86. Device: Samsung Galaxy Tab S7.
 Test Data: Legitimate username and password.
 Expected/Intended Results: Once username and password are entered, the web page redirects to
the user’s inbox, displaying and highlighting new emails at the top.
 Actual Results: As Expected
 Test Status – Pass/Fail: Pass
Assessment questions to the lecture

Bloom’s
Qn. No. Question Answer Knowledge
Level
Which is one of the objective of Test case?
a. To validate specific features and functions of the
software.
1 b. To find error a. K2
c. To prepare input
d. To identify output

A test suite is a collection of __________ that are

2 test cases K2
grouped for test execution purposes.
Test schedule should describe how the test will be
3 False K2
reviewed, tracked, and approved.

Students have to prepare answers for the following questions at the end of the lecture
Bloom’s
Mark
Qn. No Question CO Knowledge
s
Level
1 What is test assignment? 2 2 K1
2 Define Test case. 2 2 K1
3 What is the need for test schedule? 2 2 K2
4 Prepare a test schedule for testing a simple bank transfer. 13 2 K3

Reference Book

Author(s) Title of the book Page numbers

Yogesh Singh “Software Testing”, Cambridge University Press, 2012 232-270
 Unit Lecture
2 12
No No
Topic Bug Reporting, Metrics and Statistics.
Bloom’sKnowledge
Learning Outcome (LO) At the end of this lecture, students will be able to
Level
LO1 Prepare the Bug report. K2
LO2 Elaborate the steps in Bug report preparation. K2
LO3 Find out the Metrics needed to measure the quality of Testing K3
LO4 Calculate the statistics on software testing K4

Bug Report/Defect Report

A bug report is a document that communicates information regarding a software or hardware
fault or malfunction. It typically includes details such as the steps necessary to reproduce the
issue, the expected behavior, and the observed behavior. The primary purpose of a bug report
is to provide an accurate description of the problem to the development team to facilitate its
resolution. Bug reports must be clear, concise, and correct to assist developers in
understanding and quickly resolving the issue. All bugs must be documented in a bug-
reporting system to identify, prioritize, and fix them promptly. Failure to do so may lead to
the developer not understanding or disregarding the issue, as well as management not
recognizing the severity of it and leaving it in production until customers make them aware.

Benefits of a Good Software Bug Report

A good bug report should provide clear and detailed information about the issue, enabling the
development team to understand and reproduce it. It should include details such as an
accurate description of the problem, steps taken to reproduce it, expected results, actual
results, screenshots or video recordings, if applicable, device configuration, and other relevant
data. Such information allows for a more efficient resolution of the issue.

1. It can help you figure out precisely what’s wrong with a bug, so you can find the best
way to fix it.
2. Saves you time and money by helping you catch the bug before it worsens.
3. Stops bugs from making it into the final product and ruining someone’s experience.
4. Plus, it helps ensure the same bug doesn’t appear again in future versions.
5. Finally, everyone involved will know what’s happening with the bug so they can do
something about it.
Reporting a Bug
Effectively reporting a bug is essential for the development team to resolve the issue promptly
and accurately. A well-constructed bug report should be concise, comprehensive, and
comprehensible. The following steps can be taken to submit a bug report:

1. Attempt to replicate the bug consistently and systematically.

2. Gather data on the environment, such as the browser type, operating system, and
applicable software versions.
3. Construct explicit instructions outlining how to reproduce the bug.
4. Include screenshots or videos that may assist in illustrating the issue to developers.
5. Articulate what outcome was anticipated and differentiate it from what occurred in
reality.
6. Outline the severity and priority of the bug: Describe how the bug impacts the
software’s functionality and determine its level of urgency.
7. Check for duplicates: Investigate the bug tracking system to ascertain if it has already
been reported.
8. Assign the bug to a relevant developer or team and follow up
9. Monitor progress on the bug to ensure it is being addressed and provide any extra
information that may be necessary.

Write a Bug Report

A good bug report should enable the developer and management to comprehend the issue.
Guidelines to consider include:
1. All the relevant information must be provided with the bug report
Simple sentences should be used to describe the bug. Expert testers consider bug reporting
nothing less than a skill. We have compiled some tips that will help testers master them
better:
2. Report reproducible bugs:
While reporting a bug, the tester must ensure that the bug is reproducible. The steps to
reproduce the bug must be mentioned. All the prerequisites for the execution of steps and any
test data details should be added to the bug.
3. Be concise and clear:
Try to summarize the issue in a few words, brief but comprehensive. Avoid writing lengthy
descriptions of the problem.
Describe the issue in pointers and avoid paragraphs. It’s essential to provide all the relevant
information, and it helps the developers to understand the issue without any additional to and
fro of the bug. The developer must clearly understand the underlying problem with the bug
report.
4. Report bugs early:
It is important to report bugs as soon as you find them. Reporting the bug early will help the
team to fix the bug early and will help to deliver the product early.
5. Avoid Spelling mistakes and language errors:
Proofread all the sentences and check the issue description for spelling and grammatical
errors.
If required, one can use third-party tools, for eg. Grammarly. It will help the developer
understand the bug without ambiguity and misrepresentation.
6. Documenting intermittent issues:
Sometimes all bugs are not reproducible. You must have observed that sometimes a mobile
app crashes, and you must restart the app to continue. These types of bugs are not
reproducible every time.
Testers must try to make a video of the bug in such scenarios and attach it to the bug report.
A video is often more helpful than a screenshot because it will include details of steps that are
difficult to document.
For example, a mobile app crashes while switching between applications or sending an app to
the background and bringing it to the front.
7. Avoid duplication of bugs:
While raising a bug, one must ensure that the bug is not duplicating an already-reported bug.
Also, check the list of known and open issues before you start raising bugs. Reporting
duplicate bugs could cost duplicate efforts for developers, thus impacting the testing life cycle.
8. Create separate bugs for unrelated issues:
If multiple issues are reported in the same bug, it can’t be closed unless all the issues are
resolved. So, separate bugs should be created if issues are not related to each other.
For example, Let’s say a tester comes across two issues in an application in different modules.
One issue is in compose email functionality, where the user cannot compose an email, and
another issue is that the user cannot print an email. These issues must be raised separately as
they are independent of each other.
9. Don’t use an authoritative tone:
While documenting the bug, avoid using a commanding tone, harsh words, or making fun of
the developer.
The objective of a good bug report is to help the developer and the management to
understand the bug and its impact on the system. The more accurate and detailed the bug
report is, the more quickly and effectively the bug can be resolved.
What should be in a bug report?
A bug report should include a detailed description of the issue, the steps taken to reproduce
the issue, the expected outcome, and the actual outcome. It should also include any relevant
screenshots or other supporting evidence that can help illustrate what is happening.
Additionally, it should include information on the device type, operating system version, and
browser version being used when the issue occurred.
How do you write a bug report?
A bug report is a document that describes a problem in software or hardware and provides
information to help developers fix the issue. A bug report should include the following:
1. A descriptive title that summarizes the issue
2. A detailed description of the problem, including steps to reproduce it
3. The expected behavior and actual behavior
4. The type of device or system affected
5. The version of the software or hardware affected
6. Any error messages or screenshots associated with the issue
7. Your contact information in case developers have questions about your report

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 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. A weekly mileage of an automobile compared to its ideal mileage
specified by the manufacturer is an excellent illustration of metrics.

Importance of Metrics 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.
 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 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 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.
Test Metrics Life Cycle

The below diagram illustrates the different stages in the test metrics life cycle.

The various stages of the test metrics lifecycle are:

1. Analysis:
 The metrics must be recognized.
 Define the QA metrics that have been identified.
2. 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.
3. Evaluation:
 Data should be captured and verified.
 Using the data collected to calculate the value of the metrics
4. 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

To get the percentage execution status of the test cases, the following formula can be used:
Percentage test cases executed = (No of test cases executed / Total no of test cases written) x
100
Similarly, it is possible to calculate for other parameters also such as test cases that were not
executed, test cases that were passed, test cases that were failed, test cases that were blocked, and
so on. Below are some of the formulas:
1. Test Case Effectiveness:
Test Case Effectiveness = (Number of defects detected / Number of test cases run) x 100
2. Passed Test Cases Percentage: Test Cases that Passed Coverage is a metric that indicates the
percentage of test cases that pass.
Passed Test Cases Percentage = (Total number of tests ran / Total number of tests executed)
x 100
3. Failed Test Cases Percentage: This metric measures the proportion of all failed test cases.
Failed Test Cases Percentage = (Total number of failed test cases / Total number of tests
executed) x 100
4. Blocked Test Cases Percentage: During the software testing process, this parameter
determines the percentage of test cases that are blocked.
Blocked Test Cases Percentage = (Total number of blocked tests / Total number of tests
executed) x 100
5. Fixed Defects Percentage: Using this measure, the team may determine the percentage of
defects that have been fixed.
Fixed Defects Percentage = (Total number of flaws fixed / Number of defects reported) x 100
6. Rework Effort Ratio: This measure helps to determine the 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: This measures the percentage of defects that are accepted out
of the total accepted defects.
Accepted Defects Percentage = (Defects Accepted as Valid by Dev Team / Total Defects
Reported) x 100
8. Defects Deferred Percentage: This measures the percentage of the defects that are deferred
for future release.
Defects Deferred Percentage = (Defects deferred for future releases / Total Defects
Reported) x 100
Assessment questions to the lecture

Bloom’s
Qn. No. Question Answer Knowledge
Level
1. A software bug is an ?
A. error
1 B. fault D K2
C. flaw
D. All of the above
The process of finding and fixing bugs is termed?
A. Exception
B. Bugs handling
2 C K2
C. Debugging
D. Error handling

Which of the following is an informal name of defect?

A. Defect
B. Bug
3 B K2
C. Error
D. Issue

In software testing, the bug can occur for the?

A. Wrong coding
B. Missing coding
4 D K2
C. Extra coding
D. All of the above

Students have to prepare answers for the following questions at the end of the lecture
Bloom’s
Mark
Qn. No Question CO Knowledge
s
Level
1 What is Bug report? 2 2 K1
2 List the basic metrics of software testing? 2 2 K1
3 State the steps involved in bug report preparation. 6 2 K1
4 13 2 K3
Data retrieved
S during test
No. Testing Metric case

1 No. of requirements 5

The average number of test

2 cases written per 40
requirement

3 Total no. of Test cases 200

 written for all requirements

Total no. of Test cases

4 164
executed

5 No. of Test cases passed 100

6 No. of Test cases failed 60

7 No. of Test cases blocked 4

No. of Test cases

8 36
unexecuted

Total no. of defects

9 20
identified

Defects accepted as valid by

10 15
the dev team

Defects deferred for future

11 5
releases

12 Defects fixed 12

By using the basic data, calculate the Percentage of test

cases executed, Test Case Effectiveness, Failed Test
Cases Percentage, Fixed Defects Percentage, Accepted
Defects Percentage.

Reference Book

Author(s) Title of the book Page numbers

Yogesh Singh “Software Testing”, Cambridge University Press, 2012 232-270