SOFTWARE TEST LIFE CYCLE (STLC)

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.