The Software Testing Life Cycle (STLC)
If you ask someone what software testing is, you will most probably hear a lecture on the importance of software testing. Yes, that’s exactly right, but often the importance of software testing remains in theory.
What about in practice?
When you go to an IT company or start working on an IT project, one of the most popular words that people always say is testing. Testing is mentioned in almost every meeting and most of the time developers complain about the test phase. However, after a while, you will see that the word “test” means nothing to anyone and is only used to reference some challenges. Software testing is usually the least budgeted part of the SDLC. Nobody agrees, but often companies see the testing phase as a great candidate for all the savings. And software testing is almost never taken into account during the design and planning phase of a software project.
Generally, what people expect from a tester is:
“Hurry up! Find the bugs, if any.”
Therefore, the importance of testing in practice is a variable depending on the size of the bug found by the tester. Perhaps the biggest reason for this is that testing is an abstract task. You don’t produce a product that everybody can see. Testing is a matter only when the defective product is released and the company loses millions of dollars.
So, what happens in such a situation?
Of course, the QA team takes the stage and all eyes are on them. The question is simple:
“Why didn’t you do your job properly? You just had to test the product, right?”
It’s an absolutely correct question, and in such a case, most of the responsibility rests with the QA team. Yes, the QA team had to test the product but what does it actually mean testing? The general answer to this question would be test execution.
Contrary to what is known, software testing is not just a test execution but a long and detailed process is called the software testing life cycle (STLC). If the STLC is not implemented correctly, if sufficient time and budget are not allocated for STLC, it is inevitable that the test phase will fail. Therefore, in an IT project, everyone should understand software testing as STLC, and the project should be planned accordingly. Otherwise, the reliability of the test phase can never be mentioned.
So, what is STLC?
STLC includes the whole process of software testing from a to z and consists of some important steps:
Requirement Analysis
Again, we are at a point that is not given enough importance in practice. In every unsuccessful software project, one of the biggest causes of failure is not paying enough attention to the requirement gathering phase and not start to test in this step. It requires detailed and professional teamwork. It can be a very boring step for some technical people, but at this stage, I wouldn’t be exaggerating if I say the fate of the software project is written. Most of the bugs that will emerge in the future based on this step and at this phase, it can be easily understood that finding a bug costs much less. That’s why it is very important that the QA team starts working from here. Also, it is very important to get the opinion of the QA team while creating the Software Requirements Specification (SRS)[1]. Because the SRS created without the QA team is generally far from the testing approach and this can make software testing very difficult in the future. Briefly in this step QA team interacts with various stakeholders to understand requirements in detail and tests them by SMART criteria[2]. In addition, creating Requirement Traceability Matrix (RTM) [3] at this stage will provide great convenience during the test case creation phase.
Ron Patton describes the goal of a software tester in his book [4] as follows:
“The goal of a software tester is to find a bug, find them as early as possible, and make sure they get fixed”
According to this wonderful definition, the requirement gathering phase would be the right start to find bugs as early as possible.
Test Planning
The QA team has worked on SRS for a considerable time and now they understand the application, stakeholders, and customer requirements and they have RTM. Now is the time to prepare a test plan according to SRS. But there is a challenge; creating a test plan is not an easy job and requires considerable experience in software testing.
Why not start testing directly? Why do we need a test plan?
A test plan is actually deciding what, when, how, who, and where to test. Test plan gives you the opportunity to create your testing strategy, to predict the effort you need to spend during testing, and the risks you will encounter. Also, thanks to the test plan, everyone understands what is happening in the testing phase. This makes the test steps also testable. In short, without seeing the test plan, no one can say that the current test phase is sufficient or suitable for the AUT[5].
Test Case Development
If you’re following the test life cycle for the test and you’re in this step, that means now you know the AUT, you can see the all risks in the test and you are familiar with the needs of the customer. Also, you know the functions that the customer will use the most and the weaknesses in the requirement if any, and you have predictions on where the developers will miss out. Moreover, the test plan is in your hand as a bedside book to guide you through your long test journey. Now you can start creating test cases and test data.
Consider how you could create the test cases that cover all functions when one or more of the above is missing? It is not possible because you don’t know what and how to test. In this case, the biggest mistake made is to concentrate only on the points pointed out by the developers and to create test cases accordingly. The meaning of this is very simple: many untested cases and probably a fiasco release.
Test Environment Setup
Ideally, the QA team would work with the DEV team on all steps of the SDLC. Especially in the design and architecture step, the QA team should consider the event from the end customer perspective and be involved in the whole process. This provides great convenience to the QA team in preparing a test plan. In addition, it is easy to analyze and set up the test environments for them as they are involved in the design and architecture step. Knowing the test environment well, the QA team will write more reasonable test scenarios and be able to make a consistent bug analysis.
Test Execution and Cycle Closure
I think there is no need to say anything about this step because this is the part everyone knows when it comes to testing:
“Execute the tests and say pass or fail!”
As you can see, a long and intensive testing journey is needed to be able to say this sentence comfortably. I mean if you apply the STLC process correctly, you can be sure that the test results will be reliable.
But remember this job has a curse: As long as you do your job well, no one will notice how important a job you are doing :)
[1] https://en.wikipedia.org/wiki/Software_requirements_specification
[2] https://en.wikipedia.org/wiki/SMART_criteria
[3] https://en.wikipedia.org/wiki/Traceability_matrix
[4] Software Testing, Ron Patton
[5] https://innoroo.com/blog/2018/11/22/application-under-test-glossary/
