Software Testing Life Cycle: a Model-Based Explanation
Probably, life has been much easier at times, when “coding” meant software development. Today, we realize that tech progress is unstoppable. Big data systems require architects, analysts, developers, QA engineers work together to deliver custom code for us, the software users. The approach to website development has become complex and enterprise-driving with a variety of models to efficiently build the process.
We will recover in memory two most popular methodologies and show the way software testing integrates.
The oldest of the models and the best-known. It is the sequence of stages: the output of the first stage serves as input for the next. Meaning the phases don`t overlap, the next step begins only if the previous is ready.
This is how software development cycle looks like:
- Requirement specification
- Coding Implementation
- Software Testing
Although the model is clear, it is not always useful and flexible as compared to Agile, it works well for the projects with more or less precise requirements. But the IT projects of today are rarely that stable to specify the requirements in advance. They change along with the development process and market growth. Every iteration needs a considerable feedback, QA support, usability strategy. That is why “design before code” principle doesn`t always fit the current dynamics of IT projects.
Anyway, Waterfall remains applicable nowadays, so here is how the QA strategy works as per this model:
This is the stage where the team discusses and analyzes the project requirements — the desired way the website/app would be functioning as soon as released. The details of both functional (the software performance) and non-functional (usability, security) requirements are discussed with the project stakeholders and technical managers. In fact, this is a pre-planned stage which serves as a basis for the way the testing process will further develop.
Most of the articles you might read on the same topic name this stage as the most significant in the whole software testing life cycle. And it does make sense. This is the phase where a team defines the QA strategy along with the cost estimate and efforts determined to test the entire project. QA manager would work on test tool selection, resource planning, role & responsibilities division. As soon as the QA lead gets the results of project load estimate, they come up with the two primary docs: Test Plan and Test Effort Estimation.
Test Case Development
This is the stage where the details of test cases are born. In fact, QA engineers not only create but also verify and correct ready test cases and scripts if the new requirements are introduced. Requirement Traceability Matrix, a test case & requirement tracking system, is often a part of the phase.
Setting up test environment
No need to implement the stage as a separate. Test environment defines the conditions (soft- and hardware) for efficient product testing, and it is often completed along with the test case development. Moreover, the QA team doesn`t have to be active here. In such cases, project owner/developers provide ready-made testing environments. The task of QA here is to conduct smoke tests and check if the environment requirements are ready.
An active stage of software testing execution. This is where the plan is carried out. The QA engineers run the tests, document the results, log the defects. They detect bugs, report to the development team for correction, and repeated checks (regression testing).
Closing the tests cycle
Once the testing is done, it`s time to focus on the results. The team evaluates the effective decisions across the STLC and points out the areas to improve. Time, costs, test coverage, business objectives serve as a basis here to prepare the test metrics and a closure report. After all, the idea is to take lessons: define the current STLC drawbacks to avoid them in the future test cycle, find best practices, and apply them for the forthcoming projects.
The model of STLC is flexible. Whether you work with an internal team or a software testing company, the quality assurance process has to be integrated within the popular software development strategies. Let`s consider one more model to exemplify the way software testing works along with the project.
Before we continue talking about testing, a quick reminder: the whole process in the methodology aligns with the Agile development model. In this case, the project development goes on along with customer requirements. Therefore, agile testing is continuous as well. The QA team is supposed to start together with the programmers and integrate with the project specifics. Some of the key features of agile testing:
- Quality-oriented. Agile involves minimum up-front planning and design, unlike the traditional waterfall. It breaks into short timeframes (sprints) and, therefore, agile is valid for constant control over the software quality. Since the QA engineers access the details from the very beginning, they indicate the defects far earlier.
- Test-driven. Agile is an iteration-based model. Every iteration (duration varies: 2-4 weeks) goes along with the testing stage. Moreover, QA engineers perform regression tests as soon as new features are introduced, no need to wait for the implementation phase. Each sprint might finish with the user-acceptance tests.
- Customer-friendly. Agile testing provides constant feedback about the ongoing QA and reports whether the project meets business needs. In such a way, product owners have a clear picture of project growth to make timely decisions and necessary changes.
This is how agile testing life cycle looks like:
This is the stage where Agility Planning takes place. The QA team, developers, project stakeholders meet together to establish a testing schedule, set deliverables to each QA stage, define frequency of the future meetings.
The teams practice everyday meetings to catch up on the QA strategy status and establish the course for further performance.
These are usually weekly meetings with the stakeholders to evaluate the progress. It helps QA engineers verify the project status so far and plan the strategy ahead for the next week.
A final project review. Here the team decides whether the project is ready to go live or QA engineers get back to previous stages in the cycle to check the existing issues.
This is a post-release stage of input gathering from the customers, product owners, stakeholders. It is a sort of feedback for the team to rely on for the next deployment cycle.
We will update the article with some other applicable methodologies development teams implement in the SDLC process. Stay tuned 🙂