🐞 QA Stands For Quality p.9 - Test Process And Where Does It Live In SDLC
Software Testing Process And Its Place In Different SDLCs
Hey friends 👋
Welcome to the next issue of this QA series, where I share the information that helped me become a QA and that I picked up over the years to climb from a Trainee QA to managing an entire department, and that I used to teach as a course on how to become a QA from scratch.
Now that we’ve talked plenty about Software Development Life Cycles, let’s talk about STLC or Software Testing Life Cycle (don’t confuse the two). They are very similar in definition, but they talk about different things. Also, while we are doing that, we’ll talk about the overall process and what it looks like in practice.
Alright, let’s get into it.
🗒️ Software Testing Life Cycle
The test process is quite similar to the Waterfall model, but unlike the Waterfall, it’s almost universal to all companies and projects. At least that was the case for me so far 😅
It all starts with, of course, Requirement Analysis and understanding what exactly we are testing and what the expected behaviour of the system. Usually quite a boring process where you read a bunch of documentation (if there’s any) or talk with Developers, Designers, BAs (Business Analysts) and other people responsible for defining how a specific feature should work.
Followed by Planning, where you or your team talks about how this feature or project will be tested. This is the part where QAs define the documentation that will be developed, what types of tests they are going to perform, who’s doing what and similar planning topics.
And then the work begins with writing Test Cases or any other form of Test Documentation, your basis for all the tests to come.
There is a small caveat to this stage, as sometimes you simply don’t have time to document your tests, a quite common situation, especially if the development team is on a tight deadline or there is an unexpected change of priorities. But most of the time, you should have enough time to write down all the important tests at least in the form of a checklist.
Test Environment setup is usually done by Devs without direct QA involvement, but you should know it’s there.
Then it’s time to Execute the tests and Report all the findings. After all is said and done comes the most interesting part: we are assessing whether the project we are working on or a feature has a high enough degree of quality to release it to real users. If it’s good enough, then we are moving directly to Closing activities, which is a fancy name for a bunch of paperwork and reports for higher-level management.
However, if the quality is not high enough, it means that we will need to wait until the Development Team resolves all the issues QA has found so far, and then it’s a repeat of the Execution and Assessment stages.
