SOFTWARE TEST LIFE
CYCLE (STLC)
Testing
itself has many phases i.e is called as STLC.
STLC
is part of SDLC
Defect
Life Cycle is a part of STLC
Requirement is the input for testing.
Test Plan – is a document which derives all
future activities of the project. All future testing activities is planned and
put into a document and this document is known as Test Plan. It contains –
number of engineers needed for the project, who should test which feature, how
the defects must be communicated to the development team, when we should start
and finish writing test cases, executing test cases, what are the types of
testing we use to test for the application etc.
Write test case – we write test cases for each
feature. These test cases are reviewed, and after all mistakes are corrected
and once the test cases are approved – then they are stored in the test case
repository.
Traceability Matrix – it is a document which ensures
that every requirement has a test case .
Test
cases are written by looking at the requirements and test cases are executed by
looking at the test cases. If any requirement is missed i.e, test cases are not
written for a particular requirement, then that particular feature is not
tested which may have some bugs. Just to ensure that all the requirements are
converted, traceability matrix is written. This is shown below,
Defect Tracking – any bug found by the testing team
is sent to the development team. This bug has to be checked by the testing team
if it has been fixed by the developers.
Test Execution Report :- Send it to customer – contains a
list of bugs(major, minor and critical), summary of test pass, fail etc and
when this is sent, according to the customer – the project is over.
TER
is prepared after every test cycle and sent to development team, testing team,
management and customer(depends if it is a fixed
bid project or time & material
bid project).
The
last TER of the last test cycle is always sent to the customer. And this means
that the project is over-according to the customer.
Retrospect meeting – (also called Post Mortem Meeting
/ Project Closure Meeting)
The
Test Manager calls everyone in the testing team for a meeting and asks them for
a list of mistakes and achievements in the project.
This
is done by test lead or test manager. Here, the manager documents this retrospect
meeting and stores it in QMS (Quality Management System). It is a folder, where
inside this folder, there is another folder called Retrospect folder and here
this excel sheet document is stored. When we get new project, while we write
the test plan – we will open this retrospect file and will try and implement
the good practices and correct the mistakes.
REQUIREMENTS
COLLECTION / SYSTEM STUDY
The
requirements can be in any of the following forms,
·
CRS
(Customer Requirement Specification)
·
SRS
(System Requirement Specification)
·
FS
(Functional Specification)
·
If
we don’t have requirements and if we are given only the application, then we do
exploratory testing.
·
Use
case
Use
Case
Use case is a pictorial representation of
requirements. It explains how the end user interacts with the application. It
gives all possible ways of how the end user uses the application.
TEST PLAN
Test plan is a document which drives
all future testing activities.
Test
plan is prepared by Test manager(20%),
Test Engineer(20%) and by Test Lead(60%).
There are 15 sections in a test plan. We will look at each one of them below:-
1) Objective
It gives the aim of preparing
test plan i.e, why are we preparing this test plan.
2) SCOPE
3) TESTING METHODOLOGIES
For
example,
Smoke testing Functional testing Integration testing
System testing Adhoc
testing Compatibility
testing
Regression testing Globalization testing Accessibility testing
Usability testing Performance testing
4) APPROACH
The way we go about testing the
product in future,
a) By writing high level scenarios
b) By writing flow graphs
5) ASSUMPTIONS
When writing test plans, certain
assumptions would be made like technology, resources etc.
6) RISKS
If the assumptions fail, risks are
involved.
7) CONTINGENCY PLAN OR MITIGATION
PLAN OR BACK-UP PLAN
To overcome the risks, a contingency
plan has to be made. Atleast to reduce the percentage from 100% to 20%
8) ROLES AND RESPONSIBILITIES
9) SCHEDULES
:-
This section contains – when exactly
each activity should start and end? Exact date should be mentioned and for
every activity, date will be specified.
10) DEFECT TRACKING
In this section, we mention – how to
communicate the defects found during testing to the development team and also
how development team should respond to it. We should also mention the priority
of the defect – high, medium, low.
11) Test Environment
It describes the environment where the test has to be carried out.
It will give details about the software, hardware and the procedure to install the software.
12) Entry and Exit Criteria
Entry Criteria
a) WBT should be over
b) Test cases should be ready
c) Product should be installed with proper test environment
d) Test data should be ready
e) Resources should be availablea) WBT should be over
Exit Criteria
1)Based on %age test execution
2)Based on %age test pass
3) Based on severity
13) TEST AUTOMATION
At this stage it is decided that
1)Which features should be automated
2) Features not to be automated
3)Which
is the automation tool you are planning to use
4) What is the automation framework you are planning to use
14) DELIVERABLES
It is the output from the testing
team. It contains what we will deliver to the customer at the end of the
project. It has the following sections :-
v
Test Plan
v Test Cases
v
Test
Scripts
v Traceability Matrix
v
Defect Report
v
Test Execution Report
v
Graphs and Metrics
v
Release Note
15)TEMPLATES
This section contains all the templates for the
documents which will be used in the project. Only these templates will be used
by all the test engineers in the project so as to provide uniformity to the
entire project.
The
various documents which will be covered in the Template section are,
·
Test
Case
·
Traceability
Matrix
·
Test
Execution Report
·
Defect
Report
·
Test
Case Review Template
TEST DESIGN
At this stage the Test plan is implemented.The Test case are designed for each functionality at this stage
TRACEABILITY
MATRIX
Traceability Matrix is a document which has got
the mapping between requirements and test cases. We write TM to make sure that
every requirement has got atleast 1 test case.
Advantages of
Traceability Matrix
·
Ensures
that every requirement has atleast 1 test case
·
If
suddenly requirement is changed – we will be knowing which is the exact test
case or automation script to be modified
·
We
will come to know which test case should be executed manually and which are to
be done automatically.
TEST
EXECUTION
Here,
we test the product.
We
test repeatedly for 40 – 60 cycles. We do all types of testing on the
application. Test Execution is the phase where we spend 80% of our time on the
project. Only 20% is spent on the remaining stages.
TEST REPORT
At this stage the Defect is raised and assigned to the test manager who will assign it to the responsible person to resolve the defect.
