Software Testing
Software Testing
Software Testing
Software Testing is a method to check whether the actual software product matches expected
requirements and to ensure that software product is Defect free. It involves execution of
software/system components using manual or automated tools to evaluate one or more
properties of interest. The purpose of software testing is to identify errors, gaps or missing
requirements in contrast to actual requirements.
Requirement Analysis
The activities that take place during the Requirement Analysis stage include:
Test Planning is most efficient phase of software testing life cycle where all testing plans are
defined. In this phase manager of the testing team calculates estimated effort and cost for the
testing work. This phase gets started once the requirement gathering phase is completed.
Test Planning
The activities that take place during the Test Planning stage include:
At the end of this stage, the testing team should have a detailed plan for the testing activities
that will be performed, and a clear understanding of the testing objectives, scope, and
deliverables. This will help to ensure that the testing process is well-organized and that the
testing team is able to deliver high-quality results.
Test Case Development
The test case development phase gets started once the test planning phase is completed. In
this phase testing team note down the detailed test cases. Testing team also prepare the
required test data for the testing. When the test cases are prepared then they are reviewed by
quality assurance team.
Test Case Development
The activities that take place during the Test Case Development stage include:
At the end of this stage, the testing team should have a set of comprehensive and accurate test
cases that provide adequate coverage of the software or application. This will help to ensure
that the testing process is thorough and that any potential issues are identified and addressed
before the software is released.
Test Environment Setup
Test environment setup is the vital part of the STLC. Basically test environment decides the
conditions on which software is tested. This is independent activity and can be started along
with test case development. In this process the testing team is not involved. either the
developer or the customer creates the testing environment.
Test Environment Setup
The activities that take place during the test execution stage of the Software Testing Life Cycle
(STLC) include:
● Test execution: The test cases and scripts created in the test design stage are run
against the software application to identify any defects or issues.
● Defect logging: Any defects or issues that are found during test execution are logged in a
defect tracking system, along with details such as the severity, priority, and a description
of the issue.
● Test data preparation: Test data is prepared and loaded into the system for test execution
Test Environment Setup
● Test environment setup: The necessary hardware, software, and network configurations
are set up for test execution
● Test execution: The test cases and scripts are run, and the results are collected and
analyzed.
● Test result analysis: The results of the test execution are analyzed to determine the
software’s performance and identify any defects or issues.
● Defect retesting: Any defects that are identified during test execution are retested to
ensure that they have been fixed correctly.
● Test Reporting: Test results are documented and reported to the relevant stakeholders.
Test Execution
After the test case development and test environment setup test execution phase gets started.
In this phase testing team start executing test cases based on prepared test cases in the earlier
step
The activities that take place during the test execution stage of the Software Testing Life
Cycle (STLC) include:
● Test execution: The test cases and scripts created in the test design stage are run
against the software application to identify any defects or issues.
Test Execution
● Defect logging: Any defects or issues that are found during test execution are logged in
a defect tracking system, along with details such as the severity, priority, and a
description of the issue.
● Test data preparation: Test data is prepared and loaded into the system for test
execution
● Test environment setup: The necessary hardware, software, and network configurations
are set up for test execution
Test Execution
● Test execution: The test cases and scripts are run, and the results are collected and
analyzed.
● Test result analysis: The results of the test execution are analyzed to determine the
software’s performance and identify any defects or issues.
● Defect retesting: Any defects that are identified during test execution are retested to
ensure that they have been fixed correctly.
● Test Reporting: Test results are documented and reported to the relevant stakeholders.
Test Closure
Test closure is the final stage of the Software Testing Life Cycle (STLC) where all testing-
related activities are completed and documented. The main objective of the test closure stage
is to ensure that all testing-related activities have been completed, and that the software is
ready for release.
At the end of the test closure stage, the testing team should have a clear understanding of the
software’s quality and reliability, and any defects or issues that were identified during testing
should have been resolved. The test closure stage also includes documenting the testing
process and any lessons learned, so that they can be used to improve future testing processes
Test Closure
Test closure is the final stage of the Software Testing Life Cycle (STLC) where all testing-
related activities are completed and documented. The main activities that take place during
the test closure stage include:
● Test summary report: A report is created that summarizes the overall testing process,
including the number of test cases executed, the number of defects found, and the
overall pass/fail rate.
● Defect tracking: All defects that were identified during testing are tracked and managed
until they are resolved.
Test Closure
● Test environment clean-up: The test environment is cleaned up, and all test data and
test artifacts are archived.
● Test closure report: A report is created that documents all the testing-related activities
that took place, including the testing objectives, scope, schedule, and resources used.
Test Closure
● Knowledge transfer: Knowledge about the software and testing process is shared with
the rest of the team and any stakeholders who may need to maintain or support the
software in the future.
● Feedback and improvements : Feedback from the testing process is collected and used
to improve future testing processes
Bug Life Cycle
In Software Development process, Defect Life Cycle is life cycle of defect or bug from which it
goes through covering the specific set of states in its entire life. Mainly bug life cycle refers to
its entire states starting from a new defect is detected to closing of that defect by tester.
Alternatively, it is also called a Bug Life Cycle.
The journey of Defect Cycle varies from organization to organization and also from project to
project because development procedures and platforms as well as testing methods and testing
tools differ depending upon organizations and projects. The number of states that defect goes
through also varies depending upon the different tools used and process followed during
testing of software.
Workflow of Defect/Bug Life Cycle
Workflow of Defect/Bug Life Cycle
1.NEW
When any new defect is identified by tester, it falls in ‘New’ state. It is first state of Bug Life
Cycle. The tester provides a proper Defect document to Development team so that
development team can refer to Defect Document and can fix bug accordingly.
2. ASSIGNED
Defects which are in status of ‘New’ will be approved and that newly identified defect is
assigned to the development team for working on defect and to resolve that. When the defect is
assigned to developer team then status of bug changes to ‘Assigned’ state.
Workflow of Defect/Bug Life Cycle
3. OPEN –
In this ‘Open’ state the defect is being addressed by developer team and developer team works
on the defect for fixing the bug. Based on some specific reason if developer team feels that
defect is not appropriate then it is transferred to either ‘Rejected’ or ‘Deferred’ state.
4. FIXED –
After necessary changes of codes or after fixing identified bug developer team marks state as
‘Fixed’.
Workflow of Defect/Bug Life Cycle
5. PENDING RETEST –
During the fixing of defect is completed, developer team passes new code to testing team for
retest. And the code/application is pending for retesting at Tester side so status is assigned as
‘Pending Retest’.
6. RETEST –
At this stage, tester starts work of retesting defect to check whether defect is fixed by
developer or not, and the status is marked as ‘Retesting’.
Workflow of Defect/Bug Life Cycle
7. REOPEN –
After ‘Retesting’ if tester team found that bug continues like previously even after developer
team has fixed the bug, then status of bug is again changed to ‘Reopened’. Once again bug
goes to ‘Open’ state and goes through life cycle again. This means it goes for Re-fixing by the
developer team.
8. VERIFIED –
The tester re-tests bug after it got fixed by developer team and if tester does not find any kind of
defect/bug then bug is fixed and status assigned is ‘Verified’.
Workflow of Defect/Bug Life Cycle
9. CLOSED –
It is the final state of Defect Cycle, after fixing defect by developer team when testing found that
the bug has been resolved and it does not persist then they mark defect as a ‘Closed’ state.
Few More States that also comes under this Defect Life Cycle –
1. REJECTED –
If the developer team rejects defect if they feel that defect is not considered as a genuine
defect, and then they mark status as ‘Rejected’. The cause of rejection may be any of these
three i.e Duplicate Defect, NOT a Defect, Non-Reproducible.
Workflow of Defect/Bug Life Cycle
2. DEFERRED –
All defects have their bad impact on developed software and also they have a level based on his
impact on software. If the developer team feels that defect that is identified is not a prime priority
and it can get fixed in further updates or releases then developer team can mark status as ‘Deferred’.
Means from current defect life cycle it will be terminated.
3. DUPLICATE –
Some times it may happen that defect is repeated twice or defect is same as any other defect then it
is marked as ‘Duplicate’ state and then defect is ‘Rejected’.
4. NOT A DEFECT –
If the defect has no impact or effect on other functions of the software then it is marked as ‘NOT A
DEFECT’ state and ‘Rejected’.
Thank You