Software testing is a very important part of software development. owing to the huge demand and necessity of testing nowadays, The software testing process is now getting more intricate, and competent. Because of that, Software testing not only limited to finding bugs but plays an important role in delivering a quality product to the end-users and on time. This has resulted in making the whole testing process streamlined and organized. And that led to the development of the software testing life cycle or what is commonly known to us as STLC.
What is STLC?
The software testing life cycle is a sequential flow of various testing processes that are to be executed to ensure maximum results from software testing. STLC ensures that all the testing processes are carried out in an orderly and planned manner.
We have understood that STLC is a process, now look at the different steps involved in this process:
- Requirement Gathering
- Test planning
- Test case Development
- Set up the test environment (Test, Int, Prod)
- Test case Execution
- Test cycle Closure/Maintenance
1. Requirement Gathering
Requirement Gathering is the very first Step in the STLC process. The document containing these requirements is called the Specification Document. This is a very important part of the software because all the development would be revolving around this document.
It is always advised to get a sign off from the client for the requirements document, to reiterate the correctness of the specification that the client is looking for. It is with these requirements that testers would be able to come up with the test cases.
Requirements will be either in the form of a document or User Stories. In Agile a requirement is called User story. Each user story can be further broken down into several tasks and assigned to different members of the team.
The requirements are received from clients/stakeholders who are in need of the product/service. A BA (business analyst) is normally the person who prepares this document after discussions with the client. It is advisable to have the client, the BA, product owner or manager along with team leads (including QA lead) and architects should be attending the requirement gathering meeting.
Entry Criteria
- Availability of requirement Document, acceptance criteria and application architectural document.
Activities
- Recognizing the tests to be executed.
- Identify test priorities and focuses
- Create Requirement Traceability Matrix (RTM).
- Recognize details about the test environment
- Carry out Automation feasibility for the testing.
Deliverables
- RTM
- Automation feasibility report.
Exit Criteria
- RTM
- Automation Feasibility report
2. Test Planning
Once the requirement analysis is over next is the planning phase. Team lead/Test Lead or sometimes Manager will prepare the Test Plan document. This plan will be kept in share drives or test management tools like Rally, ALM, etc. so that they are accessible to everyone.
The test plan document is a single point of reference when it comes to all testing activities. It also works like the document that is shared between the Dev team, Business Analysts, Project Managers, and the other teams for concurrence.
Owing to this transparency of the QA team’s work to the external teams will increase to a great extent. The main input needed for the test plan is the signed of requirement document.
Test plan Document may have the following Sections:
1. Entry Criteria
It specifies the conditions which must be satisfied for the testing process to begin. The most common entry for testing is a stable build that has passed the smoke test within the minimum number of failures or the data setup is ready or the hardware is ready etc.
2. Scope
The scope of the Testing will be listed in this section.
The scope of the testing refers to the list of requirements from the requirement document that are feasible for testing in that particular release or iteration.
There will also be a traceability matrix created which will map the requirements to feasibility, test cases, test case runs, test case status and defects. This matrix will clearly indicate the status of the testing and quality of the product.
3. Out of Scope
Out of Scope feature will be listed in this section.
Any features or requirements which are not covered as part of the current release will be marked as out of scope. There can be several reasons for marking an item as out of scope. Data setup not available, dependency on other modules, application not ready, not feasible for testing are some of these reasons.
4. Assumptions
Assumptions are listed in this section.
As the name suggests this section would contain the list of things we think would be ready when we are starting the testing. Some of the items covered in this section are application is up and running, resources are available, hardware setup is up and running. Each project can have a different set of assumptions.
5. Schedules
Here we can write about how many test cycles are needed. Start date and end date of each cycle, the sequence of testing, etc. This section will contain an estimate of the number of test cases available and how long it will take to script and test each of these.
Then based on the number of resources available a timeline is reached for test case creation, data preparation (if applicable), and test case execution and reporting.
6. Roles and Responsibilities
Team members and their roles and responsibilities are listed in this section. Since this test plan document is shared with the development and other teams, it helps them to know whom to contact in case needed.
7. Defect management
This section talks about the process followed for reporting and closing defects. Most companies use test management or defect tracking tools like ALM, Bugzilla, and Rally, etc. This section also discusses to whom the defects will be assigned and the steps to closure.
8. Deliverables
This section contains the list of documents the testing team promises to deliver after the testing process is completed. Test results summary, defect list, and testing metrics are some of the deliverables that can be mentioned here.
9. Hardware and Environments
This section mentions the hardware requirements and setup that is needed for testing and the environment in which the testing will be done in each phase. In most cases, the testing is done in QA or Stage environment with a dummy copy of production data.
10. Risks
This is a very important section that lists out the risks and contingencies along with the mitigation plan. There can be many types of risks like hardware failures, application downtime, data unavailable, etc. These basically refer to issues that can impact your testing activities and schedule. For all risks mentioned, it is advisable for a mitigation plan. This is like a plan B when plan A fails.
11. Exit Criteria
Here we need to mention when the testing will be stopped. There are 2 situations when testing is stopped. One, when the testing is completed.
In this, the exit criteria would be testing completed for all test cases and x% of the defects closed. (X is the % of defects closed and would be decided by the management). Second, when testing needs to be stopped due to various reasons. Build instability, too many Sev 1 and Sev 2 defects or reduced timelines can be some of these reasons.
3. Test Case development
What is a test case?
A TEST CASE can be defined as a set of variables with which is used by a tester to determine whether the system under test satisfies requirements and works correctly. The process of developing test cases can also help find problems in the requirements or design of an application.
Who will write the test case?
Usually, the Test case document will be developed by the testers. The test cases are written in such a way that it validates each requirement.
The test case is based on what document?
Test cases will be based on the requirement document (SRS- Software Requirement Specification) or in agile where we do not have proper requirement document the test case will be based on the User stories
How do you identify Test cases?
Ideally, for each requirement, there should be at least one test case. In Agile User, Stories will be broken into tasks. Usually, there will be multiple test cases for each requirement/task. The mapping of the Test case to Requirement is called the Traceability Matrix.
While writing the test cases one should be careful to make sure that a maximum number of options, navigations, and validations are covered. Ideally, the test cases should be written such that every branch of the code is exercised.
Different Types of Test cases
Regression Test cases:
Regression test cases are those which cover stable and previously rolled out functionalities. Regression test cases are usually automated and are called Regression Suite. Also known as Sanity testing
Functional Test cases:
Functional test cases are test cases that validate the functional aspect of the AUT. Most of the UI and interface-related test cases would be functional. Login, logout, navigational flow and error scenarios are examples of functional test cases.
Non Functional Test Cases:
The test cases which are not related to the functionality of the application are known as non-functional test cases. For example the layout of the page, font, color, text size, image size, etc.
Integration Test cases:
When data flows from one system to another, then the test cases need to be elaborately written to cover this. These are called integration tests as they validate the integration between one or more systems.
Performance Test cases:
Test cases related to Performance of the site or application like the loading time, load it can take, etc.
White Box Test cases:
Some amount of technical knowledge is needed to write white box test cases. These test cases validate the developer code and the functional modules developed.
Let us now try to write a typical test case. It should have the following fields
- Test case number
- Test case Name
- Input steps
- Test case Type(functional, performance, Regression)-optional
- Expected Result
- Actual Result
- Status
- Requirement No
- Bugs associated (Bug ids)
If Expected Result and Actual result matches Status will be pass else fail.
4. Setting up Test Environment
Most of the companies will have a different environment to test against examples of environment would be TEST, INT, and PROD (testing, integration, and production).
There could be multiple test environments. The setup would also include any data and device setup that is needed to kick start the execution process.
Once the test cases are ready next test environment needs to be set. For example, if we are going to execute the test cases against “Test Environment “the build which developer sends for testing need to be deployed in Test Environment.
Sanity check or Regression needs to be run and there should be no new failure which means the new feature is not affecting the existing application. Only then QA can execute test cases against it.
5. Test case Execution
Here is where the actual execution takes place. Each tester is assigned a separate set of test cases. Based on the step to reproduce as mentioned in the test case document, the tester would validate whether the mention functionality is pass or fail. In case it is a fail, he needs to open a defect for the defect. He may also be required to attend triage meetings to help the developers to better understand the problems and hence fix it too.
Read also : Test Management Process: A Complete Guide
While the testing is in progress the team would be having a daily status reporting to the test lead or manager to track the progress. The team may also need to be constantly in touch with the developers to help them understand the issues and defects.
In case any bug fixes are received, the team needs to make sure the issues are actually fixed and also validate that the fix has not adversely affected any other functionality
6. Testing closure/Maintenance
Once all the test cases are completed and most of the defects are tracked to closure, the test process is also closed. All the deliverables’s as mentioned in the test plan is shared with the development team along with the certification of whether or not the build is a go or no-go to the next stage.
Hope this section was useful to you in understanding the STLC process. Though we have talked about the 6 steps there are always customizations that we need to do to make things smoother for the project.
With Scrum and agile being the buzz words, the STLC has been reduced to a minimum with no proper test plan and in most cases no detailed test cases as well. But always remember the process is important and the more you do away with the greater is the risk.
Why do we need STLC?
Software testing ensures the high quality of the software product and is essentially a very important part of software development. The software testing life cycle ensures that the testing process is carried out in a well-planned and sequential order thus promising better testing results.
The Software Testing Life Cycle can embrace 4 different testing models namely the agile model, the waterfall model, the V model, and the spiral model.
- Agile model: Agile Testing model is being largely adopted by testing teams. It is based on continuous integration between testers and developers. Agile Testing does not follow a sequential flow of testing processes.
- Waterfall testing model: Waterfall Model or Linear Sequential Life Cycle follows a sequential order of testing. We only move to the next phase of testing when the previous phase is completed. It is good for small projects where the requirements are very clear.
- V model: V Model is an advanced version of the classic waterfall model. In the V model, each phase of the software development life-cycle is validated before going to the next level. In the V model, software testing starts as soon as the requirements are written. V model helps in detecting defects in the early stages of life-cycle and it also minimizes probable future defects.
- Spiral Model: Spiral Model is based on incremental and prototype techniques. It is usually applied in large and complicated projects with high-risk probability.
Conclusion
A systematic and sequential approach is always beneficial for any process. The software testing life cycle is such a systematic and sequential way of conducting software testing that promises a more effective and efficient testing results.
Get an eBook: Download PDF