Software Testing Life Cycle

Step Phase Name Entry Criteria Activities Performed Deliverables

Number
1 Requirements Requirements Do brainstorming of the requirements. Create a list of RUD (Requirements
Phase specification requirements and get your doubts clarified. understanding
document document)
Understand the feasibility of the requirements whether it is
Application design testable or not. Testing feasibility
document report
If your project requires automation, do the automation feasibility
User acceptance study. Automation feasibility
criteria document report.
2 Planning Phase Updated requirements Define the scope of the project Test plan/strategy
document. document.
Do the risk analysis and prepare the risk mitigation plan.
Test feasibility reports Effort estimation
Perform test estimation. document.
Automation feasibility
report. Determine the overall testing strategy and process.

Identify the tools and resources and check for any training needs.

Identify the environment.

3 Analysis Phase Updated requirements Identify the detailed test conditions Test conditions
document document.

Test Plan document

Risk Document

Test estimation
document

1
4 Design Phase Updated requirements Detail the test condition. Break down the test conditions into Detailed test condition
document multiple sub-conditions to increase coverage. document
Identify and get the test data
Test conditions Identify and set up the test environment. Requirement
document Create the requirement traceability metrics traceability metrics
Create test coverage metrics.
Test coverage metrics
5 Implementation Detailed test condition Create detailed test case Test cases
Phase document Prioritize the test case
Identify the test case Test scripts
Identify the candidate test cases for automation
Test data
6 Execution Phase Baselined RTM, Test Execute tests as per plan Completed RTM with
Plan, Test case/scripts execution status
are available Document test results, and log defects for failed cases
Test cases updated with
Test environment is Update test plans/test cases, if necessary results
ready
Map defects to test cases in RTM Defect reports
Test data set up is
done Retest the defect fixes

Unit/Integration test Regression Testing of application

report for the build to
be tested is available Track the defects to closure
7 Conclusion Updated test cases Provide the accurate figures and result of testing Updated traceability
Phase with results metrics
Identify the risks which are mitigated
Test closure conditions Test summary report

Updated risk
management report

2
8 Closure Phase Testing has been Evaluate cycle completion criteria based on - Time, Test coverage, Test Closure report
completed Cost, Software Quality, Critical Business Objectives
Test metrics
Test results are Prepare test metrics based on the above parameters.
available
Document the learning out of the project
Defect logs are
available Prepare Test closure report

Qualitative and quantitative reporting of quality of the work

product to the customer.

Test result analysis to find out the defect distribution by type and
severity

3
Test Case

4
Test Case Field Description

Test case ID:  Each test case should be represented by a unique ID. To indicate test types follow some convention like
"TC_UI_1" indicating "User Interface Test Case#1."

Test Priority:  It is useful while executing the test.

o Low
o Medium
o High

Name of the Module:  Determine the name of the main module or sub-module being tested

Test Designed by:  Tester's Name

Date of test designed:  Date when test was designed

Test Executed by:  Who executed the test- tester

Date of the Test  Date when test needs to be executed

Execution:

Name or Test Title:  Title of the test case

Description/Summary  Determine the summary or test purpose in brief

of Test:

Pre-condition:  Any requirement that needs to be done before execution of this test case. To execute this test case list all
pre-conditions

5
Dependencies:  Determine any dependencies on test requirements or other test cases

Test Steps:  Mention all the test steps in detail and write in the order in which it requires to be executed. While writing

test steps ensure that you provide as much detail as you can

Test Data:  Use of test data as an input for the test case. Deliver different data sets with precise values to be used as an input

Expected Results:  Mention the expected result including error or message that should appear on screen

Post-Condition:  What would be the state of the system after running the test case?

Actual Result:  After test execution, actual test result should be filled

Status (Fail/Pass):  Mark this field as failed, if actual result is not as per the estimated result

Notes:  If there are some special condition which is left in above field

6
Bug Report

 Defect_ID - Unique identification number for the defect.

 Defect Description - Detailed description of the Defect
including information about the module in which Defect was
found.
 Version - Version of the application in which defect was
found.
 Steps - Detailed steps along with screenshots with which
the developer can reproduce the defects.
 Date Raised - Date when the defect is raised
 Reference- where in you Provide reference to the
documents like . requirements, design, architecture or maybe
even screenshots of the error to help understand the defect
 Detected By - Name/ID of the tester who raised the defect
 Status - Status of the defect , more on this later
 Fixed by - Name/ID of the developer who fixed it
 Date Closed - Date when the defect is closed
 Severity which describes the impact of the defect on the
application
 Priority which is related to defect fixing urgency. Severity
Priority could be High/Medium/Low based on the impact urgency
at which the defect should be fixed respectively

7
Categorization

Defect categorization help the software developers to prioritize their tasks. That means that this kind of priority helps the developers in fixing those defects
first that are highly crucial.

8
No. Description Priority Explanation

1 The website High The performance bug can cause huge inconvenience to user.
performance is too slow

2 The login function of Critical Login is one of the main function of the banking website if this feature does
the website does not
work properly not work, it is serious bugs

3 The GUI of the website Medium The defect affects the user who use Smartphone to view the website.
does not display
correctly on mobile
devices

4 The website could not High This is a serious issue since the user will be able to login but not be able to
remember the user
login session perform any further transactions

5 Some links doesn’t Low This is an easy fix for development guys and the user can still access the site
work
without these links