Chapter 1

Testing Fundamentals
  i. Software Testing - Introduction - Importance

  ii. Seven Fundamental Principles of Testing

  iii. SDLC Vs STLC

  iv. Software Testing Life Cycle - STLC explained

Chapter 2

Types of Testing
  I. Unit Testing

  II. Integration Testing

  III. System Testing

  IV. Regression Testing

  V. Non - Functional Testing

Created by:-Prafull Thite Page 1

 Chapter 3

Defect Life Cycle

  i. Defect, Error, Bug

  ii. Defect Life Cycle

  iii. Defect report template

iv. Severity / priority

v. Testing Tools

Chapter 4

Test Case Development

  i. First Steps Test Case Development

  ii. Test Scenario

  iii. Test Case Specifications

  iv. Test Basis

Created by:-Prafull Thite Page 2

   v. Traceability Matrix

  vi. Practical Tips and Tricks to Create Test Data

  vii. Sample Test Case Template with Explanation of important Fields

Chapter 5

Testing Techniques
  i. Equivalence Partitioning & Boundary Value Analysis

  ii. Decision Table Testing

  iii. State Transition Diagram

  iv. Use Case Testing

Chapter 4

Test Management & Control

  i. There are 3 principle documents in Testing.

  ii. Test case and template with example.

  iii. Test cases/ test plan/Test Strategy/Scenarios?

  iv. Test plan and test plan templates.

Created by:-Prafull Thite Page 3

Chapter 6

Testing Methodology
  i. Agile Testing Methodology

  ii. How to Test in Agile?

  iii. Scrum Testing and Waterfall Vs. Agile:

Chapter 7

Difference between
  Defect Severity in Software Testing

  Test Plan V/s Test Strategy

  Static Vs Dynamic Testing

  Re-testing Vs Regression Testing

  Quality Assurance Vs Quality Control

  Verification v/s Validation in a Software Testing

  Positive Vs Negative Testing

Created by:-Prafull Thite Page 4

   Defect Density: Software Testing Terminology

  Globalization Vs Localization Testing

  Test Scenario Vs Test Condition

  Unit Test Vs Integration Test

Smoke Vs Sanity Testing

Chapter 9

Chapter 10

Performance Testing
  i. Performance Testing

  ii. Load Testing

  iii. Stress Testing

  iv. Volume Testing

  v. Scalability Testing

  vi. What is Soak Testing?

  vii. Stability Testing - Concepts in Software Testing

Created by:-Prafull Thite Page 5

   viii. Spike Testing

Chapter 11

Testing Types – API

What is Software Testing?

Software testing is a process of executing a program or application with the intent of finding
the software bugs and improve quality of application.

 It can also be stated as the process of validating and verifying that a software program

or application or product:

o Meets the business and technical requirements that guided it’s design and
development
o Works as expected
o Can be implemented with the same characteristic.

Let’s break the definition of Software testing into the following parts:

1)  Process:  Testing is a process rather than a single activity.

2)  All Life Cycle Activities: Testing is a process that’s take place throughout the Software
Development Life Cycle (SDLC).

 The process of designing tests early in the life cycle can help to prevent defects from
being introduced in the code. Sometimes it’s referred as “verifying the test basis via
the test design”.
 The test basis includes documents such as the requirements and design specifications.
 3)  Static Testing:  It can test and find defects without executing code. Static Testing is
done during verification process. This testing includes reviewing of the documents

Created by:-Prafull Thite Page 6

 (including source code) and static analysis. This is useful and cost effective way of
testing.  For example: reviewing, walkthrough, inspection, etc.
 4)  Dynamic Testing:  In dynamic testing the software code is executed to demonstrate
the result of running tests. It’s done during validation process. For example: unit
testing, integration testing, system testing, etc.
  5)  Planning:  We need to plan as what we want to do. We control the test activities, we
report on testing progress and the status of the software under test.
 6)  Preparation:  We need to choose what testing we will do, by selecting test conditions
and designing test cases.
 7)  Evaluation:  During evaluation we must check the results and evaluate the software
under test and the completion criteria, which helps us to decide whether we have finished
testing and whether the software product has passed the tests.
 8)  Software products and related work products:  Along with the testing of code the
testing of requirement and design specifications and the related documents like operation,
user and training material is equally important.

7 FUNDAMENTAL PRINCIPLES OF SOFTWARE TESTING

AS PER ISTQB

In software testing industry, there are 7 principles of testing. It’s very important to
learn about this principle because these are nothing but the pillars of your testing
efforts.
But let me ask you one question. Do you really know the meaning of principle? If
yes, then please skip next paragraphs and start reading about the principle from
“What is Software Testing Principle?” section. If you don’t know the meaning of
principle, then please continue with this post.
What is Principle?
Basically, the principle is nothing but the rules or law which must be followed.
Or you can say principles are the essential characteristic of the system which
needs to follow for developing the best system. Ignoring any one principle may
cost the effectiveness towards the performance of the system. A principle of
software testing refers to the brief mentioned and proven concepts which guide
testing professionals during software testing process.

1st Principle: Testing Shows Defects Are Present In The Software

As per this principle, testing is a process which shows defects are present is
software. Defects are identified by using different software testing execution
techniques. At the same time, testing doesn’t prove that after finding defects that

Created by:-Prafull Thite Page 7

there are no defects present in the system. In many cases, it is identified that
defects are present is software even after undergone through the rigorous testing
activity. This principle talks about the reduction of several defects in software.
There are always chances that the software has undiscovered defects, testing
should not be considered as a proof of defect free software.
2nd Principle: Exhaustive Testing Is Not Practically Possible
If we talk about this principle, it says it is not possible to test complete software.
Test with all combinations of inputs and outputs. Test with all possible scenarios
is not possible. Then you must be thinking how we will test the complete
software. See, instead of performing complete or exhaustive testing we go for
risk-based testing. Identifying the impact can help us to identify the module which
are on high risk.
Don’t think much about it, at this moment it is enough for you to know exhaustive
testing is not possible. Later on you will come to know, why principle itself says it
not possible.
3rd Principle: Start Testing In Early Stage of SDLC
This principle asks to start testing software in the early stage of software
development life cycle. As we are starting testing activity in early stage, this helps
us to identify defects and fixed early with a low budget and within assigned time
period. It allows to handover ordered software on time with expected quality.
4th Principle: Defects Clustering
Usually, maximum defects in software lie within the limited set of software areas.
If you successfully identify this area, it’s become quite a simple task for you to
bring that sensitive area under the focus of testing. It is considered as one of the
most efficient ways to perform testing efficiently.
5th Principle: The Pesticide Paradox
If you are using the same set of test cases repeatedly, then after some time
those test cases do not find any new defects. The effectiveness of test cases
starts degrading after some round executions, so it is always recommended to
review and revise the test cases on a regular interval in order to find new defects.
It can add new scenario or test cases even after the execution of particular test
set.
6th Principle: Testing is dependent on context

According to this principle; if you are testing web application and mobile
application using same testing strategy, then it is wrong. This principle says the
testing approach should be different and that’s depending on the application.
Strategy for testing web application would be different from android mobile app
testing.

Created by:-Prafull Thite Page 8

7th Principle: Absence of errors – fallacy
This principle points towards the usefulness of the system. In other words finding
the defects and fixing it will not help user unless and until the software is not
developed according to the requirement.

SDLC
Software Development Life Cycle (SDLC) is a process used by the software
industry to design, develop and test high quality softwares. The SDLC aims
to produce a high-quality software that meets or exceeds customer
expectations, reaches completion within times and cost estimates.

 SDLC is the acronym of Software Development Life Cycle.

 It is also called as Software Development Process.
 SDLC is a framework defining tasks performed at each step in the software
development process.
 ISO/IEC 12207 is an international standard for software life-cycle processes. It
aims to be the standard that defines all the tasks required for developing and
maintaining software.

What is SDLC?
SDLC is a process followed for a software project, within a software
organization. It consists of a detailed plan describing how to develop,
maintain, replace and alter or enhance specific software. The life cycle
defines a methodology for improving the quality of software and the overall
development process.

The following figure is a graphical representation of the various stages of a

typical SDLC.

Created by:-Prafull Thite Page 9

A typical Software Development Life Cycle consists of the following stages −

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in
SDLC. It is performed by the senior members of the team with inputs from
the customer, the sales department, market surveys and domain experts in
the industry. This information is then used to plan the basic project
approach and to conduct product feasibility study in the economical,
operational and technical areas.

Planning for the quality assurance requirements and identification of the

risks associated with the project is also done in the planning stage. The
outcome of the technical feasibility study is to define the various technical
approaches that can be followed to implement the project successfully with
minimum risks.

Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and
document the product requirements and get them approved from the
customer or the market analysts. This is done through an SRS (Software

Created by:-Prafull Thite Page 10

Requirement Specification) document which consists of all the product
requirements to be designed and developed during the project life cycle.

Stage 3: Designing the Product Architecture

SRS is the reference for product architects to come out with the best
architecture for the product to be developed. Based on the requirements
specified in SRS, usually more than one design approach for the product
architecture is proposed and documented in a DDS - Design Document
Specification.

This DDS is reviewed by all the important stakeholders and based on

various parameters as risk assessment, product robustness, design
modularity, budget and time constraints, the best design approach is
selected for the product.

A design approach clearly defines all the architectural modules of the

product along with its communication and data flow representation with the
external and third party modules (if any). The internal design of all the
modules of the proposed architecture should be clearly defined with the
minutest of the details in DDS.

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built.
The programming code is generated as per DDS during this stage. If the
design is performed in a detailed and organized manner, code generation
can be accomplished without much hassle.

Developers must follow the coding guidelines defined by their organization

and programming tools like compilers, interpreters, debuggers, etc. are
used to generate the code. Different high level programming languages
such as C, C++, Pascal, Java and PHP are used for coding. The
programming language is chosen with respect to the type of software being
developed.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC
models, the testing activities are mostly involved in all the stages of SDLC.
However, this stage refers to the testing only stage of the product where

Created by:-Prafull Thite Page 11

product defects are reported, tracked, fixed and retested, until the product
reaches the quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally
in the appropriate market. Sometimes product deployment happens in
stages as per the business strategy of that organization. The product may
first be released in a limited segment and tested in the real business
environment (UAT- User acceptance testing).

Then based on the feedback, the product may be released as it is or with

suggested enhancements in the targeting market segment. After the
product is released in the market, its maintenance is done for the existing
customer base.

SDLC Models
There are various software development life cycle models defined and
designed which are followed during the software development process.
These models are also referred as Software Development Process Models".
Each process model follows a Series of steps unique to its type to ensure
success in the process of software development.

Following are the most important and popular SDLC models followed in the
industry & minus ;

 Waterfall Model

 Iterative Model

 Spiral Model

 V-Model

 Big Bang Model

Other related methodologies are Agile Model, RAD Model, Rapid Application
Development and Prototyping Models.

Created by:-Prafull Thite Page 12

 STLC
STLC stands for Software Testing Life Cycle. STLC is a sequence of different
activities performed by the testing team to ensure the quality of the
software or the product.

 STLC is an integral part of Software Development Life Cycle (SDLC). But, STLC
deals only with the testing phases.
 STLC starts as soon as requirements are defined or SRD (Software Requirement
Document) is shared by stakeholders.
 STLC provides a step-by-step process to ensure quality software.
 In the early stage of STLC, while the software or the product is developing, the
tester can analyze and define the scope of testing, entry and exit criteria and
also the Test Cases. It helps to reduce the test cycle time along with better
quality.
 As soon as the development phase is over, the testers are ready with test cases
and start with execution. This helps to find bugs in the initial phase.

STLC Phases
STLC has the following different phases but it is not mandatory to follow all
phases. Phases are dependent on the nature of the software or the product,
time and resources allocated for the testing and the model of SDLC that is
to be followed.

There are 6 major phases of STLC −

 Requirement Analysis − When the SRD, FRD is ready and shared with the
stakeholders, the testing team starts high level analysis concerning the AUT
(Application under Test).
 Test Planning − Test Team plans the strategy and approach.
 Test Case Designing − Develop the test cases based on scope and criteria’s.

Created by:-Prafull Thite Page 13

  Test Environment Setup − When integrated environment is ready to validate
the product.
 Test Execution − Real-time validation of product and finding bugs.
 Test Closure − Once testing is completed, matrix, reports, results are
documented.

In this chapter, we will understand the factors of comparison between STLC

and SDLC. Let us consider the following points and thereby, compare STLC
and SDLC.

 STLC is part of SDLC. It can be said that STLC is a subset of the SDLC set.

 STLC is limited to the testing phase where quality of software or product

ensures. SDLC has vast and vital role in complete development of a software or
product.

 However, STLC is a very important phase of SDLC and the final product or the
software cannot be released without passing through the STLC process.

 STLC is also a part of the post-release/ update cycle, the maintenance phase of
SDLC where known defects get fixed or a new functionality is added to the
software.

Created by:-Prafull Thite Page 14

Interview Question

The following table lists down the factors of comparison between SDLC and
STLC based on their phases −

Phase SDLC STLC

 Business Analyst gathers  Testing team reviews

requirements. and analyzes the FRD,

 Development team BRD document.

analyzes the  Identifies the testing

requirements. requirements - Scope,

 After high level, the Verification and

Requirement development team starts Validation key points.

Gathering
analyzing from the  Reviews the
architecture and the requirements for logical
design perspective. and functional
relationship among
various modules. This
helps in the
identification of gaps at
an early stage.

 The architecture of SDLC  In STLC, either the Test

helps you develop a Architect or a Test Lead
high-level and low-level usually plan the test
design of the software strategy.
based on the  Identifies the testing
requirements. points.
Design
 Business Analyst works  Resource allocation and
on the mocker of UI timelines are finalized
design. here.
 Once the design is
completed, it is signed
off by the stakeholders.

Created by:-Prafull Thite Page 15

  Development team starts  Testing team writes the
developing the software. test scenarios to validate

 Integrate with different the quality of the

systems. product.

 Once all integration is  Detailed test cases are

done, a ready to test written for all modules

Development
software or product is along with expected

provided. behavior.

 The prerequisites and

the entry and exit
criteria of a test module
are identified here.

 Development team sets  The Test team confirms

up a test environment the environment set up
with developed product based on the

Environment to validate. prerequisites.

Set up  Performs smoke testing
to make sure the
environment is stable for
the product to be tested.

Testing  The actual testing is  System Integration

carried out in this phase. testing starts based on
It includes unit testing, the test cases.
integration testing,  Defects reported, if any,
system testing, defect get retested and fixed.
retesting, regression
 Regression testing is
testing, etc.
performed here and the
 The Development team product is signed off
fixes the bug reported, if once it meets the exit
any and sends it back to criteria.
the tester for retesting.

 UAT testing performs

Created by:-Prafull Thite Page 16

 here after getting sign
off from SIT testing.

 Once sign-off is received  Smoke and sanity

from various testing testing in production
team, application is environment is
deployed in prod completed here as soon
Deployment/
Product environment for real end as product is deployed.
Release users.  Test reports and matrix
preparation are done by
testing team to analyze
the product.

 It covers the post  In this phase, the

deployment supports, maintaining of test
enhancement and cases, regression suits
Maintenance updates, if any. and automation scripts
take place based on the
enhancement and
updates.

Created by:-Prafull Thite Page 17

Chapter 2

Types of Testing

There are different levels during the process of testing. In this chapter, a
brief description is provided about these levels.

Levels of testing include different methodologies that can be used while

conducting software testing. The main levels of software testing are:

 Functional Testing

 Non-functional Testing

Functional Testing
This is a type of black -box testing that is based on the specifications of the
software that is to be tested. The application is tested by providing input
and then the results are examined that need to conform to the functionality
it was intended for. Functional testing of software is conducted on a
complete, integrated system to evaluate the system's compliance with its
specified requirements.

Non-functional testing (Testing of software product

characteristics)

In non-functional testing the quality characteristics of the component or

system is tested. Non-functional refers to aspects of the software that may
not be related to a specific function or user action such as scalability or
security. E.g. how many people can log in at once? Non-functional testing is
also performed at all levels like functional testing.

                  Functional Testing                Non- Functional Testing

Created by:-Prafull Thite Page 18

 1. In functional Testing tester tests how well the 1. In Non-Functional Testing tester tests how well
system performs. the system responds.

2. Functional Testing is based on client 2. Non- Functional Testing is based on client

requirements. expectations.

3. Functional Testing means Testing the 3. Non- Functional Testing means Testing the
application against business requirements. application against clients and performance
requirements.

5. Functional Testing Validating the behavior of 5. Non- Functional Testing Validating the
application. characteristics performance of application.

6. This Testing covers Unit Testing, Integration 6. This Testing covers Load/Performance Testing,
Testing, Smoke Testing, Sanity Testing, Stress/Volume Testing, Security Testing,
Regression Testing and so on. Installation Testing and so on.

7. It is always concentrating on customer 7. It is always concentrating on customer

requirements. expectations.

8. Functional Testing means how is your system 8. Non- Functional Testing means how well your
is doing. system is doing example usability, performance
and stress testing.

Created by:-Prafull Thite Page 19

Software Testing - Levels

Created by:-Prafull Thite Page 20

Unit testing

Created by:-Prafull Thite Page 21

A unit test is the smallest testable part of an application like functions, classes, procedures,
interfaces. Unit testing is a method by which individual units of source code are tested to
determine if they are fit for use.

 Unit tests are basically written and executed by software developers to make sure that
code meets its design and requirements and behaves as expected.
 The goal of unit testing is to segregate each part of the program and test that the
individual parts are working correctly.
 This means that for any function or procedure when a set of inputs are given then it
should return the proper values. It should handle the failures gracefully during execution
when any invalid input is given.
 A unit test provides a written contract that the piece of code must assure. Hence it has
several benefits.
 Unit testing is basically done before integration as shown in the image below.

Method Used for unit testing: White Box Testing method is used for executing the unit test.

When Unit testing should be done?

Unit testing should be done before Integration testing.

By whom unit testing should be done?

Unit testing should be done by the developers.

4. Unit testing helps in simplifying the debugging process. If suppose a test fails then only latest
changes made in code needs to be debugged.

Component testing

Component testing is a method where testing of each component in an application is done

separately.  Suppose, in an application there are 5 components. Testing of each 5 components
separately and efficiently is called as component testing.

 Component testing is also known as module and program testing. It finds the defects in
the module and verifies the functioning of software.
 Component testing is done by the tester.
 Component testing may be done in isolation from rest of the system depending on the
development life cycle model chosen for that application. In such case the missing

Created by:-Prafull Thite Page 22

 software is replaced by Stubs and Drivers and simulate the interface between the
software components in a simple manner.
 Let’s take an example to understand it in a better way. Suppose there is an application
consisting of three modules say, module A, module B and module C. The developer has
developed the module B and now wanted to test it. But in order to test the module B
completely few of it’s functionalities are dependent on module A and few on module C.
But the module A and module C has not been developed yet. In that case to test the
module B completely we can replace the module A and module C by stub and drivers as
required.
 Stub: A stub is called from the software component to be tested. As shown in the
diagram below ‘Stub’ is called by ‘component A’.
 Driver: A driver calls the component to be tested. As shown in the diagram below
‘component B’ is called by the ‘Driver’.

Below is the diagram of the component testing:

As discussed in the previous article of the ‘Unit testing’ it is done by the developers where they
do the testing of the individual functionality or procedure. After unit testing is executed,
component testing comes into the picture. Component testing is done by the testers.

Component testing plays a very important role in finding the bugs. Before we start with the
integration testing it’s always preferable to do the component testing in order to ensure that each
component of an application is working effectively.

Integration testing

Integration testing tests integration or interfaces between components, interactions to different

parts of the system such as an operating system, file system and hardware or interfaces between
systems.

Created by:-Prafull Thite Page 23

  Also after integrating two different components together we do the integration testing. As
displayed in the image below when two different modules ‘Module A’ and ‘Module B’ are
integrated then the integration testing is done.

 Integration testing is done by a specific integration tester or test team.

 Integration testing follows two approach known as ‘Top Down’ approach and ‘Bottom Up’
approach as shown in the image below:

Below are the integration testing techniques:

1. Big Bang integration testing:

In Big Bang integration testing all components or modules are integrated simultaneously, after
which everything is tested. As per the below image all the modules from ‘Module 1’ to ‘Module

Created by:-Prafull Thite Page 24

6’ are integrated simultaneously then the testing is carried out.

2. Top-down integration testing: Testing takes place from top to bottom, following the control
flow or architectural structure (e.g. starting from the GUI or main menu). Components or
systems are substituted by stubs. Below is the diagram of  ‘Top down Approach’:

3. Bottom-up integration testing: Testing takes place from the bottom of the control flow
upwards. Components or systems are substituted by drivers. Below is the image of ‘Bottom up
approach’:

Created by:-Prafull Thite Page 25

Created by:-Prafull Thite Page 26
System testing
 In system testing the behavior of whole system/product is tested as defined by the scope of the
development project or product.
 It may include tests based on risks and/or requirement specifications, business process, use
cases, or other high level descriptions of system behavior, interactions with the operating
systems, and system resources.
 System testing is most often the final test to verify that the system to be delivered meets the
specification and its purpose.
 System testing is carried out by specialist’s testers or independent testers.
 System testing should investigate both functional and non-functional requirements of the
testing.

Acceptance testing or User Acceptance

Testing (UAT)
After the system test has corrected all or most defects, the system will be delivered to the user
or customer for Acceptance Testing or User Acceptance Testing (UAT).

 Acceptance testing is basically done by the user or customer although other stakeholders may
be involved as well.
 The goal of acceptance testing is to establish confidence in the system.
 Acceptance testing is most often focused on a validation type testing.

Created by:-Prafull Thite Page 27

Chapter 3

Defect Life Cycle

Definition: A defect is an error or a bug, in the application which is created. A programmer

while designing and building the software can make mistakes or error. These mistakes or errors
mean that there are flaws in the software. These are called defects.

 When actual result deviates from the expected result while testing a software application
or product then it results into a defect. Hence, any deviation from the specification
mentioned in the product functional specification document is a defect. In different
organizations it’s called differently like bug, issue, incidents or problem.
 When the result of the software application or product does not meet with the end user
expectations or the software requirements then it results into a Bug or Defect. These
defects or bugs occur because of an error in logic or in coding which results into
the failure or unpredicted or unanticipated results.

Additional Information about Defects / Bugs:

While testing software application or product if large number of defects is found then it’s called
Buggy.

When a tester finds a bug or defect it’s required to convey the same to the developers. Thus they
report bugs with the detail steps and are called as Bug Reports, issue report, problem report, etc.

What is a Bug?
A Bug is the result of a coding Error or Fault in the program which causes the program
to behave in an unintended or unanticipated manner. It is an evidence of fault in the
program. Bugs arise from mistakes and errors, made by people, in either a program’s
source code or its design. Normally, there are bugs in all useful computer programs,
but well-written programs contain relatively few bugs, and these bugs typically do not
prevent the program from performing its task.
 

What is a Defect or Fault?

A Defect is a deviation from the Requirements. A Software Defect is a condition in a
software product which does not meet a software requirement (as stated in the
requirement specifications) or end-user expectations. In other words, a defect is an
error in coding or logic that causes a program to malfunction or to produce
incorrect/unexpected result. This could be hardware, software, network, performance,
format, or functionality.
 
 

Created by:-Prafull Thite Page 28

What is a Failure?
Failure is a deviation of the software from its intended purpose. It is the inability of a
system or a component to perform its required functions within specified performance
requirements. Failure occurs when fault executes.
 

Defect Life Cycle or a Bug lifecycle 

Effect life cycle is a cycle which a defect goes through during its lifetime. It starts when defect
is found and ends when a defect is closed, after ensuring it’s not reproduced. Defect life cycle is
related to the bug found during testing.

The bug has different states in the Life Cycle. The Life cycle of the bug can be shown
diagrammatically as follows:

Bug or defect life cycle includes following steps or status:

1. New:  When a defect is logged and posted for the first time. It’s state is given as new.
2. Assigned:  After the tester has posted the bug, the lead of the tester approves that the bug is
genuine and he assigns the bug to corresponding developer and the developer team. It’s state
given as assigned.
3. Open:  At  this state the developer has started analyzing and working on the defect fix.
4. Fixed:  When developer makes necessary code changes and verifies the changes then he/she
can make bug status as ‘Fixed’ and the bug is passed to testing team.
5. Pending retest:  After fixing the defect the developer has given that particular code for retesting
to the tester. Here the testing is pending on the testers end. Hence its status is pending retest.
6. Retest:  At this stage the tester do the retesting of the changed code which developer has given
to him to check whether the defect got fixed or not.
7. Verified:  The tester tests the bug again after it got fixed by the developer. If the bug is not
present in the software, he approves that the bug is fixed and changes the status to “verified”.
8. Reopen:  If the bug still exists even after the bug is fixed by the developer, the tester changes
the status to “reopened”. The bug goes through the life cycle once again.
9. Closed:  Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer
exists in the software, he changes the status of the bug to “closed”. This state means that the
bug is fixed, tested and approved.
10. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug,
then one bug status is changed to “duplicate“.
11. Rejected/ Not a bug: If the developer feels that the bug is not genuine, he rejects the bug. Then
the state of the bug is changed to “rejected”.
12. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next
releases. The reasons for changing the bug to this state have many factors. Some of them
are priority of the bug may be low, lack of time for the release or the bug may not have major
effect on the software.

Created by:-Prafull Thite Page 29

Created by:-Prafull Thite Page 30
Created by:-Prafull Thite Page 31
:http://automationpractice.com/index.php
http://phptravels.com/demo/
http://newtours.demoaut.com/

Created by:-Prafull Thite Page 32