UNIT 2

Software Testing – Test Strategy

The Test strategy document is a high-level document that outlines the testing technique
used in the Software Development Life Cycle and confirms the test kinds or levels that
will be performed on the product. One can’t change the test strategy once it’s been
written, and it’s been accepted by the Project Manager and development team.
In addition, the test strategy provides the following details, which are required while
writing the test document:
 What technique must be used in addition to this?
 Which of the modules will be examined?
 What criteria apply for entry and exit?
 What kind of testing is necessary?
To put it another way, it’s a document that explains the process of product evaluation.
And the approaches can be developed using the following factors:
 Whether or not to automate
 From the standpoint of a resource
On the basis of the development design papers, we may write the test strategy.
The following documents are included in the development design document:
 Documents pertaining to the system design: These documents will mostly be used
to build the test strategy.
 Design Documents: These are used to outline the software features that will be
enabled in a future version.
 Documents relating to conceptual design: These are the documents that we don’t
utilize very often.
Here, we will discuss the following points:
1. Components of Test Strategy.
2. Test Strategy vs Test Plan.
3. Types of Test Strategies.
4. Test Strategy Selection.
5. Details Included in Test Strategy Document.
6. Conclusion.

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.
The following are the components of the test strategy:
1. Scope and Overview.
2. Testing Methodology.
3. Testing Environment Specifications.
4. Testing Tools.
5. Release Control.
6. Risk Analysis.
7. Review and Approvals.

Let’s discuss each of these in detail.

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.

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 behavior. 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.

Details Included in Test Strategy Document

The test strategy document includes the following important details:

 Overview and Scope.
 Software and testing work products that can be reused.
 Details about the various test levels, their relationships, and the technique for
integrating the various test levels.
 Techniques for testing the environment.
 Level of testing automation.
 Various testing tools.
 Risk Assessment.
 For each level of the test Conditions for both entry and exit.
 Reports on test results.
 Each test’s degree of independence.
 During testing, metrics and measurements will be analyzed.
 Regression and confirmation testing.
 Taking care of discovered flaws.
 Configuring and managing test tools and infrastructure.
 Members of the Test team’s roles and responsibilities.

Conclusion

The test strategy document presents a bright vision of what the test team will do for the
entire project. Because the test strategy document will drive the entire team, only
individuals with extensive experience in the product area should prepare. Because it is a
static document, it cannot be edited or changed throughout the project life cycle. The
Test strategy document can be sent to the complete testing team before any testing
operations begin. If the test strategy document is properly created, it will result in the
development of a high-quality system and the expansion of the entire testing process.

TEST SCHEDULE
In software testing, documentation is very important. Testing should be documented to
provide efficient resource control monitoring. For successful testing, a test plan plays a
very important role. Here, we will discuss the following points:
1. Introduction to Test Plan.
1. Objectives of Test Plan.
1. Importance of Test Plan.
1. Types of Test Plans.
1. Test Plan Components/ Attributes.
1. How to Write a Test Plan.
Introduction to Test Plan
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 involves 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.
Who? Roles
Who writes Test Plans? Test lead, Test Manager, Test Engineer

Who reviews the Test Test Lead, Test Manager, Test Engineer, Customer,
Plan? Development Team

Who approves Test

Customer, Test Manager
Plan?

Who writes Test Cases? Test Lead, Test Engineer

Who reviews Test

Test Engineer, Test Lead, Customer, Development Team
Cases?

Who approves Test

Test Manager, Test Lead, Customer
Cases?

Objectives of the Test Plan

 Overview of testing activities: The test plan provides an overview of the testing
activities and where to start and stop the work.
 Provides timeline: The test plan helps to create the timeline for the testing activities
based on the number of hours and the workers needed.
 Helps to estimate resources: The test plan helps to create an estimate of the number
of resources needed to finish the work.
 Serves as a blueprint: The test plan serves as a blueprint for all the testing activities,
it has every detail from beginning to end.
 Helps to identify solutions: A test plan helps the team members to consider the
project’s challenges and identify the solutions.
 Serves as a rulebook: The test plan serves as a rulebook for following rules when the
project is completed phase by phase.
Importance of Test Plan
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: 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.
Type of Test Plan
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: In this type of test plan, it is designed for specific types of testing
especially non-functional testing for example plans for conducting performance tests
or security tests.
Test Plan Components/ Attributes
There is no hard and fast rule for preparing a test plan but it has some standard 15
attributes that companies follow:

1. Objective: It describes the aim of the test plan, whatever the good process and
procedure they are going to follow in order 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 with respect to 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 each and 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 and 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 which 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 in order 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.
Example: If the team member reports 45% of the test cases failed, then testing will be
suspended until the developer team fixes all defects.
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 need 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: It 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.
How to Write a Test Plan
Below are the eight steps that can be followed to write a test plan:
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.
 Risks and issues that will list all the possible risks that may occur during testing.
 Test logistics mentions the name 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: There are two main testing criteria that govern all the activities
in the testing project:
 Suspension criteria: Suspension criteria defines the benchmarks for suspending all
the tests.
 Exit criteria: Exit criteria defines the benchmarks that signify the successful
completion of the test phase or project. These are expected results and must match
before moving to the next stage of development.
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: This phase is very important as the test environment is
where the QAs run their tests. It is important that the test environments are 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.
Deliverables required Deliverables required Deliverables required
before testing during testing after testing
Test Plan Test Scripts Test Results

Test Design Simulators Defect Reports

Test Data Release Notes

Error and Execution Logs

RESOURSE REQUIREMENTS
Project resources simply mean resources that are required for successful development
and completion of project. These resources can be capital, people, material, tool, or
supplies that are helpful to carry out certain tasks in project. Without these resources, it
is impossible to complete project. In project planning phase, identification of resources
that are required for completion of project and how they will be allocated is key
element and very important task to do. In project management, some resources that are
required are assigned to each task of project to get job done.
There are three types of resources that are considered and are very essential for
execution of project and completion of project on time and on budget. These resources
can be denoted by pyramid which is also known as Resource Pyramid. At base of
pyramid i.e. last layer, hardware and software tools are present, then at middle layer,
reusable components are present, and at top of pyramid i.e. top layer, human resources
are present. This is shown in following diagram :
When software planner wants to specify resources, they specify it using four
characteristics :

 Description of resource
 Resource availability
 Time of resource when it will be available
 Duration of resource availability
Types of resources :
1. HumanResource –
Human plays an important role in software development process. No matter what size is and
how much complexity is there in project, if you want to perform project task in an effective
manner, then human resources are very essential. In software industry, people are assigned
some organizational positions such as manager, software developer, software testing, engineer,
and so on. These positions are according to their skills and specialty.
For small project only, single individual can perform all these roles. But for large project, team
of people works on it. The total number of people that are required for project is estimated by
calculating development effort inters of person-months.
2. ReusableComponents –
For bringing ease in software development process or to accelerate development process
software, industry prefers to use some ready software components. The components can be
defined as the software building blocks that can be created and reused in software development
process. Generally, regardless of their type, size, or complexity, all projects need money.
Managing budget for project is one of most important tasks that all project managers have to
do. The reusable resources also known as cost resources are very helpful as they help in
reducing overall cost of development. The use of components emphasizes reusability. This is
also termed as Component-Based Software Engineering.
3. Hardware and Software tools –
These are actually material resources that are part of project. This type of resource should be
planned before starting development of project otherwise it way causes problems for the
project.
For example, if you require certain software elements during performing task and somehow you
can’t manage to get them on time, even they could take few weeks to ship from manufacturer
and this will cause delay to your project.

Software Testing – Test Case

Software testing is known as a process for validating and verifying the working of a
software/application. It makes sure that the software is working without any errors,
bugs, or any other issues and gives the expected output to the user. The software testing
process doesn’t limit to finding faults in the present software but also finding measures
to upgrade the software in various factors such as efficiency, usability, and accuracy.
So, to test software the software testing provides a particular format called a Test Case.
This article focuses on discussing the following topics in Test Case:
1. What is a Test Case?
2. Test Case vs Test Scenario.
3. When do we write Test Cases?
4. Why write Test Cases?
5. Test Case Template.
6. Best practice for writing Test Cases.
7. Test Case management tools.
8. Formal and Informal Test Case.
9. Types of Test Cases.
10. Example.

What is Test Case?

A test case is a defined format for software testing required to check if a particular
application/software is working or not. A test case consists of a certain set of conditions
that need to be checked to test an application or software i.e. in more simple terms
when conditions are checked it checks if the resultant output meets with the expected
output or not. A test case consists of various parameters such as Id, condition, steps,
input, expected result, result, status, and remarks.
Parameters of a Test Case:
 Module Name: Subject or title that defines the functionality of the test.
 Test Case Id: A unique identifier assigned to every single condition in a test case.
 Tester Name: The name of the person who would be carrying out the test.
 Test scenario: The test scenario provides a brief description to the tester, as in
providing a small overview to know about what needs to be performed and the small
features, and components of the test.
 Test Case Description: The condition required to be checked for a given software.
for eg. Check if only numbers validation is working or not for an age input box.
 Test Steps: Steps to be performed for the checking of the condition.
 Prerequisite: The conditions required to be fulfilled before the start of the test
process.
 Test Priority: As the name suggests gives the priority to the test cases as in which
had to be performed first, or are more important and which could be performed
later.
 Test Data: The inputs to be taken while checking for the conditions.
 Test Expected Result: The output which should be expected at the end of the test.
 Test parameters: Parameters assigned to a particular test case.
 Actual Result: The output that is displayed at the end.
 Environment Information: The environment in which the test is being performed,
such as operating system, security information, the software name, software version,
etc.
 Status: The status of tests such as pass, fail, NA, etc.
 Comments: Remarks on the test regarding the test for the betterment of the
software.
Test Case vs Test Scenario

Below are some of the points of difference between a test case and a test scenario:

S
No
. Test Case Test Scenario

A test case is a defined

format for software
testing required to
check if a particular Test Scenario provides a small description of what needs
1. application/software/mo to be performed based on the use case.
dule is working or not.
Here we check for
different conditions
regarding the same.

Test cases are more

Test Scenario provides a small description, mostly one-
2. detailed with a number
line statements.
of parameters.

Test cases are low-level

3. Test scenarios are high-level actions.
actions.

Test cases are mostly

Test scenarios are derived from documents like BRS,
4. derived from test
SRS, etc.
scenarios.

It focuses on “What to
5. It focuses more on ‘What to test”.
test” and “How to test”.

Test cases require more

resources for
6.
documentation and
execution.

When Do We Write Test Cases?

Test cases are written in different situations:

 Before development: Test cases could be written before the actual coding as that
would help to identify the requirement of the product/software and carry out the test
later when the product/software once gets developed.
 After development: Test cases are also written directly after coming up with a
product/software or after developing the feature but before the launching of a
product/software as needed to test the working of that particular feature.
 During development: Test cases are sometimes written during the development time,
parallelly. so whenever a part of the module/software gets developed it gets tested as
well.
So, test cases are written in such cases, as test cases help in further development and
make sure that we are meeting all the needed requirements.

Why Write Test Cases?

Test cases are one of the most important aspects of software engineering, as they define
the way in which the testing would be carried out. Test cases are carried out for a very
simple reason, to check if the software actually works or not. There are many
advantages of writing test cases:
 Test cases help to check if a particular module/software is meeting the specified
requirement or not.
 Test cases determine if a particular module/software work with a given set of
conditions.
 Test cases help to narrow down the software needs and required updates.
 Test cases are easy, simple, and clear as they are step by step and well documented.
 Test cases are detailed which makes them helpful during the maintenance phase.

Test Case Template

Let’s look at a basic test case template for the login functionality.
The Test case template contains the header section which has a set of parameters that
provides information about the test case such as the tester’s name, test case description,
Perquisite, etc. The body section contains the actual test case content, such as test Id,
test steps, test input, expected result, etc.
In the given template below it’s clearly identifiable that the section from module name
to test scenario is the header section while the table that lies below the test scenario
(from test case id to comments) is the body of the test case template.
Here a test case template for login functionality has been created with its parameters
and values.
Test Case Template

Best practice for writing test case

There are certain practices which one could follow while writing the test cases that
would be considered as beneficial.
1. Simple and clear: Test cases need to be very concise, clear, and transparent. They
should be easy and simple to understand not only for oneself but for others as well.
2. Maintain the uniqueness: While writing the test cases, it’s necessary to make sure
that they aren’t being written over and over again and each case is different from
the other.
3. Zero Assumptions: Test cases should not contain assumed data, don’t come up with
features/modules that don’t exist.
4. Traceability: – Test cases should be traceable for the future reference, so while
writing it’s important to keep that in mind,
5. Different input data: While writing test cases, all types of data must be taken into
consideration.
6. Strong module name: The module name should be self-explanatory while writing
the test case.
7. Minimal Description: The description of a test case should be small, one or two
lines are normally considered good practice but it should give the basic overview
properly.
8. Maximum conditions: All kinds of conditions should be taken into consideration
while writing a test, increasing the effectiveness.
9. Meeting requirements: While writing the test case it’s important that the
client/customer/end-user requirements are met.
10. Repetitive Results: The test case must be written in such a way that it should
provide the same result.
11. Different Techniques: Sometimes testing all conditions might not be possible but
using different testing with different test cases could help to check every aspect of a
software.

Test Case Management Tools

Test management tools help to manage the test cases. These tools are automated tools
that decrease the time and effort of a tester as compared to the traditional way. Some
test case management tools include advanced dashboards, easier bug, and progress
tracking as well as management, custom test case templates, integration of test cases,
inviting guest testers, managing team requirements and plans, and much more.
A few of the tools are listed below:
 Testpad: Testpad is a simple tool that makes test case management easier. The
software’s main motto says that it aims to find a bug that matters. Few features of
Testpad include manual testing, reports of the test cases and software, dragging and
dropping to make testing easier, inviting guest testers by email, building custom
templates, and much more.
 TestCaseLab: TestCaseLab is easily manageable for the test cases and could swiftly
integrate them with bug trackers. The features of TestCaseLab include Custom test
cases, Test Runs, Integrations of test cases, Test Plans, tags and priority for test
cases, search by name of test cases, description and tags, etc.
 TestRail: TestRail is another platform that aims to make test case management
easier, it streamlines the software testing processes and along with more visibility
into QA. The basic features of TestRail include management for test cases, plans,
and runs, more test coverage, real-time insights into the QA progress, etc.
 TestLodge: TestLodge is a test case management tool that helps the entire team to
manage their requirements, test plans, test cases, and test runs all in one single place
and also with no user limit. The basic features of TestLodge include Test Plans, Test
Runs, Dashboard, Test Suite, and many more.

Formal and Informal Test Case

 Formal Test Cases: Formal test cases are test cases that follows the basic test case
format. It contains the test case parameters such as conditions, Id, Module name, etc.
Formal Test cases have set input data and expected results, they are performed as
per the given order of steps.
 Informal Test Cases: Informal test cases are test cases that don’t follow the basic test
case format. In these, as the tests are performed the test case are written in real-time
then pre-writing them and the input and expected results are not predefined as well.
Types of Test Cases
 Functionality Test Case: The functionality test case is to determine if the interface of
the software works smoothly with the rest of the system and its users or not. Black
box testing is used while checking for this test case, as we check everything
externally and not internally for this test case.
 Unit Test Case: In unit test case is where the individual part or a single unit of the
software is tested. Here each unit/ individual part is tested and we create a different
test case for each unit.
 User Interface Test Case: The UI test or user interface test is when every component
of the UI that the user would come in contact with is tested. It is to test if the UI
components requirement made by the user are fulfilled or not.
 Integration Test Case: Integration testing is when all the units of the software are
combined together and then they are tested. It is to check that each component and
its units work together without any issues.
 Performance Test Case: The performance test case helps to determine response time
as well as the overall effectiveness of the system/software. It’s to see if the
application will actually handle the real-world expectations.
 Database Test Case: Also known as back-end testing or data testing checks that
everything works fine with respect to the database. Testing cases for tables, schema,
triggers, etc. are done.
 Security Test Case: The security test case helps to determine that the application
restricts actions as well as permissions wherever necessary. Encryption and
authentication are considered as main objectives with regard to the security test
case. The security test case is done to protect and safeguard the data of the software.
 Usability Test Case: Also known as a user experience test case, it checks how user-
friendly or easy to approach a software would be. Usability test cases are designed
by the User experience team and performed by the testing team.
 User Acceptance Test Case: The user acceptance case are prepared by the testing
team but the user/client does the testing and review if they work in the real world
environment.

Example

Below is an example for preparing various test cases for a login page with a username
and password.
Unit Test case: Here we are only checking if the username validates at least for the
length of eight characters.
Test Test
Tes Conditi Test Expected Actual Status Remarks
t Id on Steps Test Input Result Result

1. Checks if 1. geeksforgeeks Accepts Accepts Pass None

 the Give for for
username input thirteen thirteen
field character character
accepts s. s.
the input
of
thirteen
character
s.

Here it is only checked whether the passing of input of thirteen characters is valid or
not. So since thirteen character word ‘geeksforgeeks’ is entered then the test is being
successful else it would have failed for any other test case.
Functionality Test case: Here it is checked whether the username and password both
work together on the login click.
Te Test Test Steps Test
st Cond Test Input Expecte Actual Status Remarks
Id ition d Result Result

Chec
k that
with
the 1. Enter
corre username username:
ct geeksforgeeks
2. Enter the Login Login
1 usern Pas
password password: succes success None
. ame s
geeksforever sful ful
and 3. Click on
pass login
word
able
to log
in.

2 Chec 1. Enter username: Login Login Pas None

. k that username geeksforgeeks unsuc unsucc s
if cessfu essful
2. Enter password:
with l
password geekstogether
incorr
ect 3. Click on
usern login
ame
 and
pass
word
able
to not
login.

Here it is being checked whether on passing wrong and right inputs if the login
functionality is working or not, it’s showing login successful for right credentials and
unsuccessful for wrong once, hence both tests have passed otherwise would have failed.
User Acceptance Test Case: Here the user feedback is taken if the login page is loading
properly or not.
Test Test
Test Id Con Test Steps Test Input Expec
ditio ted Actual Status Remark
n Result Result s

The
Chec login
k if page
the is not
loadi loade
Wel Wel
ng d due
com com
page to a
e to e to
loadi 1. Click on brows
1. None logi logi Fail
ng login button. er
n n
effici comp
pag pag
ently atibili
e. e.
for ty
the issue
clien on the
t. user’s
side.

Here it is being checked if by clicking on the login button if the page is loaded and the
‘Welcome to login page’ message is displayed. The test has failed here as the page was
not loaded due to a browser compatibility issue, it would have loaded the test would
have passed.

What is a 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.

How to Report 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.

How to 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.
Essential Features in Bug Report
Various bug reporting tools, like Jira, Bugzilla, TFS, and Asana, are available in the market.
Depending on the project cost, one must select the bug reporting tool.
Excel or Word can also be used for reporting bugs for small projects. Irrespective of the tools
used for logging the bug, the tester must capture some details in the bug report.
Below are the essential details that should be mentioned while creating a bug report:
1. Bug ID:
Each bug should be given a unique identification number. Bug reporting tools automatically
provide a unique number to the newly raised bugs. This field helps to identify the bug easily.

Software Testing Roles and Responsibilities

In case of software testing every company defines its own level of hierarchy, roles and
responsibilities but on a broader level, if you take a look you will always find the following two
levels in a software testing team:

Test lead/manager: A test lead is responsible for:

 Defining the testing activities for subordinates – testers or test engineers.

 All responsibilities of test planning.
 To check if the team has all the necessary resources to execute the testing activities.
 To check if testing is going hand in hand with the software development in all phases.
 Prepare the status report of testing activities.
 Required Interactions with customers.
 Updating project manager regularly about the progress of testing activities.

Test engineers/QA testers/QC testers are responsible for:

 To read all the documents and understand what needs to be tested.

 Based on the information procured in the above step decide how it is to be tested.
 Inform the test lead about what all resources will be required for software testing.
 Develop test cases and prioritize testing activities.
 Execute all the test case and report defects, define severity and priority for each defect.
 Carry out regression testing every time when changes are made to the code to fix defects.

Overview Of Software Engineering Team

How a software application shapes up during the development process entirely depends on the how
the software engineering team organizes work and implements various methodologies. For an
application to develop properly, it is important that all processes incorporated during the software
development are stable and sustainable. Many times developers come under pressure as the delivery
date approaches closer this often affects the quality of the software. Rushing through the processes to
finish the project on time will only produce a software application which has no or minimal use for
the customers. Hence, work organization and planning is important and sticking to the plan is very
important. The project manager should ensure that there are no obstacles in the development process
and if at all there is an issue it must be resolved with immediate attention.
Overview Of Software Testing Team
How soon and how well you can achieve your testing goals depends solely on the capabilities of the
testing team. Within the testing team itself it is important to have the correct blend of testers who can
efficiently work together to achieve the common testing goals. While forming a team for testing, it is
important to ensure that the members of the team jointly have a combination of all the relevant
domain knowledge that is required to test the software under development.
It is very important to ensure that the software testing team has a proper structure. The hierarchy and
roles should be clearly defined and responsibilities too should be well defined and properly
distributed amongst the team members. When the team is well organized the work can be handled
well. If every team member knows what duties he or she has to perform then they will be able to
finish their duties as required well within the time limit. It is important to keep track of the testers’
performance. It is very important to check what kind of defects the tester is able to uncover and what
kind of detects he tends to miss. This will give you a fair idea about how serious your team is about
the work.
All the team members should work together to prepare a document that clearly defines the roles and
responsibilities of all the team members. Once the document is prepared the role of each member
should be communicated clearly to everyone. Once the team members are clear about who is going to
handle which area of the project, then in case of any issue it will be easy to determine who needs to
be contacted.
Each member of the team should be provided with the necessary documents that provide information
on how the task would be organized, what approach will be followed, how things are scheduled, how
many hours have been allocated to each member and all details related to applicable standards and
quality processes.
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.

A software tester has different sets of roles and responsibilities. He should have in depth knowledge
about software testing. He should have a good understanding about the system which means
technical (GUI or non-GUI human interactions) as well as functional product aspects. In order to
create test cases it is important that the software tester is aware of various testing techniques and
which approach is best for a particular system. He should know what are various phases of software
testing and how testing should be carried out in each phase. The responsibilities of the software tester
include:
 1. Creation of test designs, test processes, test cases and test data.
2. Carry out testing as per the defined procedures.
3. Participate in walkthroughs of testing procedures.
4. Prepare all reports related to software testing carried out.
5. Ensure that all tested related work is carried out as per the defined standards and procedures.

Software Test Manager Role

Managing or leading a test team is not an easy job. The company expects the test manager to know
testing methodologies in detail. A test manager has to take very important decisions regarding the
testing environment that is required, how information flow would be managed and how testing
procedure would go hand in hand with development. He should have sound knowledge about both
manual as well as automated testing so that he can decide how both the methodologies can be put
together to test the software. A test manager should have sound knowledge about the business area
and the client’s requirement, based on that he should be able to design a test strategy, test goal and
objectives. He should be good at project planning, task and people coordination, and he should be
familiar with various types of testing tools. Many people get confused between the roles and
responsibilities of a test manager and test lead.For a clarification, a test lead is supposed to have a
rich technical experience which includes, programming, handling database technologies and various
operating systems, whereas he may not be as strong as Software Test Manager regarding test project
management and coordination. The responsibilities of the test manager are as follows:

1. Since the test manager represents the team he is responsible for all interdepartmental
meetings.
2. Interaction with the customers whenever required.
3. A test manager is responsible for recruiting software testing staff. He has to supervise all
testing activities carried out by the team and identify team members who require more
training.
4. Schedule testing activities, create budget for testing and prepare test effort estimations.
5. Selection of right test tools after interacting with the vendors. Integration of testing and
development activities.
6. Carry out continuous test process improvement with the help of metrics.
7. Check the quality of requirements, how well they are defined.
8. Trace test procedures with the help of test traceability matrix.

Software Test Automator Role

Software test automator or an automated test engineer should have very good understanding of what
he needs to test- GUI designs, load or stress testing. He should be proficient in automation of
software testing, and he should be able to design test suites accordingly. A software test automator
should be comfortable using various kinds of automation tools and should be capable of upgrading
their skills with changing trends. He should also have programming skills so that he is able to write
test scripts without any issues. The responsibilities of a tester at this position are as follows:

1. He should be able to understand the requirement and design test procedures and test cases for
automated software testing.
2. Design automated test scripts that are reusable.
 3. Ensure that all automated testing related activities are carried out as per the standards defined
by the company.

Interactions between Software Test Team And Business Teams

If at all a customer has any issues related to testing activities and operational matters of the project
then it is the software testing manager who is responsible for communicating the details to the client
regarding how things are being managed. The software testing manager not only answers the queries
of the customers but also ensures that the project is completed on time as per the requirement of the
customer.
Interactions between Software Test Team And Development Teams

In order to produce good software applications, it is important that software testing and software
development teams work together with good understanding. For this it is important that the testers
and developers are comfortable with each other’s role and understand well that they have a common
goal and it is wise to listen each other. A good communication skill is very important both for testers
and developers.
Before getting started with testing work it is important to discuss the basic guidelines and
expectations so that there is no confusion in later stages. Criticism should be taken in a positive
sense. It is important to understand that developers and testers have a common goal of producing
high quality software. A tester is not discovering bugs to show someone down, the idea is to learn
from mistakes and avoid repeating them in future. A culture of constructive criticism can be of great
help.
Interactions between Software Test Team And Release Management Teams

The release management teams are responsible for moving the software from development into
production. This team is responsible for planning the releases for hardware, software and testing. It is
also responsible for development of software development procedures and for coordinating
interactions and training of releases. Software testing is considered to be a very important aspect of
software engineering life cycle but it does not get over with development. Testing and verification is
a very important part of release management exercise.
Interactions between Software Test Manager And Software Project Manager

The job of a software test manager is not an easy one. He has to recruit testing team and take
responsibility for getting them trained. A software manager has to perform ongoing analysis of
various testing processes and ensure that the testing team is carrying out all the processes correctly.
This job is of great responsibility as the software testing manager is the one who selects, introduces
and implement various tools for testing. A software test manager is responsible for finalizing
templates for testing documents, test reports and other procedures.
Since a software tester manager has to deal with all the details of various testing activities, it is very
important for him to be in constant touch with the project manager and provide necessary support in
project planning and scheduling so that the project can be successfully completed in time within the
specified financial budget limits.
(Sample Bug)

2. Summary:
A summary of the issue should be provided. The summary should be a concise statement that
helps to identify the problem. Bug titles should be easy to understand, which would help identify
the issue quickly.A good bug summary helps managers review the bugs quickly during the bug
review meetings.
A good bug summary helps managers review the bugs quickly during the bug review meetings.
3. Description:
The description should be provided in the bug to help the developer in understanding the bug. It
should be in simple language that a developer can understand easily.All the details about the
environment and the type of user privileges must be mentioned. For eg. any prerequisite for
executing test steps like any configuration or test data.Let’s look at another example: the Mobile
app crashes while switching to a module to which the user can’t access. In these scenarios, user
privileges details must be mentioned in the prerequisite along with the URL of the admin page to
modify the user permissions.
4. Test Steps:
Test steps are a detailed description of the exact steps taken to replicate an issue and should be
included when reporting a problem. They provide the necessary information for developers to
identify and debug any issues. Test steps should be written clearly and concisely, outlining each
step in detail so that it can be easily followed by the developer.
5. Actual Results:
The actual result of the test steps must be mentioned. Regardless of the outcome, documenting
what happened to conclude the result will help improve future scenarios.
6. Expected Results:
Expected results corresponding to failed steps must be mentioned, which would help the
developer to know the exact behavior to adapt while fixing the bug. This section will also be
helpful while retesting the bug.
7. Reporter:
The name and email of the reporter of the bug should be mentioned. In bug reporting tools, these
are automatically fetched from the user profile. It would help the developer or reviewer to
quickly identify who reported the bug. Developers can reach out to the reporter if any discussion
is required around the bug.
8. Reported date:
The date when the bug is raised should be mentioned. This will help in identifying the release in
which the bug occurred.
9. Assignee:
The bug should be assigned to the product owner or development manager. They can review the
bug and plan the fix as per the team member’s bandwidth and module expertise. In some cases,
bugs can be left unassigned and added to the bugs queue, where developers can pick them
according to priority.
10. Severity:
The tester defines it for bugs depending upon the impact on the application. Severity can be as
follows:i. Blocker: Blocks development and/or testing work and/or the actual use of the
system/product (e.g. crash upon starting the app)ii. Major: Major loss of function, with no
workaround, other parts of the product/system still workiii. Normal: Normal loss of function, or
other problem, where a difficult workaround is presentiv. Minor: Minor loss of function or other
problem where a workaround is present for the functionality
11. Priority:
It is defined as a bug by the tester/product owner, considering severity, probability, business
needs, time, and resources available.i. Critical: Bugs that are mission-critical to the application’s
core functionality and for which there are no workarounds.Note: These bugs should be sporadic,
and this category should only be used if encountering a team/user blocking situation.ii.
Urgent: Bugs related to the application’s core functionality and have to be fixed urgently within
the sprint.iii. High: Bugs that do not affect critical user functionality and have workarounds.
These bugs can be fixed in the next sprint.iv. Normal: Bugs that do not interfere with core
functionality are just annoyances that may or may not ever be fixed.v. Low: Whatever gets
defined as low might be kept in the backlog and might be closed as a known issue.
12. Component:
Sometimes an application is classified into multiple modules, which are then mentioned under
the component field when a bug is reported. It becomes easier to analyze which module has
problems. When bugs are assigned with the corresponding components mentioned, it becomes
easier for the development manager to assign the bug to respective team members based on their
areas of expertise.
13. Affected Version:
It is the version of the application on which the bug is reported. Knowing the exact application
version can also provide valuable insight into how widespread the bug may be and what other
users may be experiencing. Having this information available can save time and resources when
working to resolve any potential issues with an application.
14. Fix Version:
It is the application’s version on which the bug is fixed. When a tester identifies a bug, they can
update the application version to fix it. This requires careful consideration of the code and any
potential changes that may be necessary. Once the bug is fixed, the tester retests the application
to ensure it works as expected. If there are any issues, they can be addressed and corrected before
releasing the new version of the software.
15. Date Closed:
It is the date the bug is closed by the testing team. Closing a bug is an integral part of the
software testing process. The date on which a bug is closed is recorded in the bug tracking
system, along with any notes regarding how it was resolved and who was responsible for
resolving it. This information can be used as reference material for future troubleshooting efforts
and as a record of progress toward improving software quality.
16. Target version:
It is the application’s version on which a bug is targeted to be fixed. When developers work on
fixing a bug, they usually target a specific application version. This allows them to focus on
resolving the issue in that particular version while ensuring other versions are not affected by any
changes they make. By targeting a specific version of an application, developers can ensure that
all users running that version will receive the bug fix and benefit from it.
17. Status:
A software bug follows a cycle. According to where it is in the cycle, a status is assigned. For eg.
When a new bug is created, its status is assigned as open. Later, it goes through various stages
like In Progress, Fixed, Won’t Fix, Accepted, Reopen, Verified, etc. These stages vary following
different bug reporting tools.

(Bug Life Cycle)

18. Attachments:
Screenshots, videos, and logs should be attached for the failed steps. Screenshots should be
highlighted for the issues, which help the developer to visualize the issue quickly. Videos and
logs will help to reproduce the issue with the required steps.
Best if suggestions to fix are incorporated if known.
Conclusion
Testers must create comprehensive bug reports for practical bug analysis and resolution. Testers
should incorporate all pertinent information to ensure the highest quality of reports and
communicate clearly with developers and managers. Best practices for bug reporting should be
shared to optimize report accuracy. Integrating test automation and bug-reporting tools, such
as Testsigma, can expedite the reporting process while conserving resources. Ultimately, well-
crafted bug reports foster positive collaboration between teams and reduce costs related to fixing
bugs.