The Modern Software Testing Lifecycle: From Requirements to Continuous Quality | Amber Insights #009
Updated: Sep 13
By Amber Idumwonyi
When people first learn software testing, the Software Testing Life Cycle, often abbreviated to STLC, is usually presented as a sequence of stages.
Requirements analysis.
Test planning.
Test design.
Environment setup.
Test execution.
Defect reporting.
Test closure.
It is a useful foundation.
But modern software delivery rarely happens in such a neat, linear sequence.
Requirements evolve.
Development and testing overlap.
Automation runs continuously.
Multiple versions of software may exist across different environments.
Defects are discovered while other functionality is still being developed.
Production generates new information that changes future testing.
And Quality Engineers increasingly contribute long before anything is ready for formal test execution.
So while the principles behind the traditional STLC remain valuable, the way we apply them needs to reflect how modern software is actually delivered.
The modern Software Testing Lifecycle is not simply a testing phase inside a development project.
It is a continuous process of understanding risk, designing quality, generating evidence, providing feedback, and learning throughout the life of a product.
What Is the Software Testing Lifecycle?
The Software Testing Lifecycle describes the activities involved in planning, designing, performing, evaluating and completing testing.
Traditionally, these activities are organised into stages.
That structure helps teams answer important questions:
What are we testing?
Why are we testing it?
How will we test it?
What do we need to perform the testing?
What did we discover?
What level of confidence do we have?
What remains unresolved?
Those questions remain relevant regardless of whether a team uses Waterfall, Agile, DevOps or another delivery model.
What changes is when and how frequently we answer them.
In a modern delivery environment, we may revisit these questions repeatedly throughout development.
That is why I prefer to think about the STLC not as a one-way journey through fixed stages, but as an interconnected set of quality activities.
1. Requirements Analysis: Testing Begins Before the Software Exists
One of the most valuable testing activities can happen before a single line of production code has been written.
Requirements analysis allows Quality Engineers to understand what the system is expected to do and begin identifying potential quality concerns.
Suppose a requirement states:
"The system should allow customers to make payments."
That statement immediately raises questions.
What payment methods are supported?
Are there minimum or maximum amounts?
Which currencies are permitted?
What happens if payment is declined?
What happens if the payment provider times out?
Can a customer accidentally submit the same payment twice?
What information should be recorded?
What confirmation should the customer receive?
These questions are not merely preparation for testing later.
They are part of testing itself.
By challenging ambiguity early, teams can prevent misunderstandings from becoming implemented defects.
Requirements analysis may therefore involve reviewing:
Business requirements
User stories
Acceptance criteria
Business rules
Technical designs
Interfaces and dependencies
Non-functional requirements
Regulatory or accessibility considerations
Assumptions and constraints
The objective is not simply to understand what has been written.
It is to identify what needs clarification, what could go wrong, and what evidence will eventually demonstrate that the solution works as intended.
2. Test Planning: Deciding How Quality Will Be Evaluated
Once we understand the problem, we need to determine how testing will approach it.
This is where test planning becomes important.
A Test Plan or Test Strategy should not exist merely because governance requires a document.
It should help the team make decisions.
What is in scope?
What is outside scope?
What types of testing are required?
What are the significant risks?
What environments are needed?
What data will be required?
What dependencies exist?
What should be automated?
What requires manual or exploratory investigation?
Who is responsible for different activities?
What could prevent testing from progressing?
How will we determine whether sufficient confidence exists to release?
These decisions create direction.
On a small Agile product, some of this information may be lightweight and distributed across team artefacts.
On a large, regulated or complex programme, the Test Strategy may require significantly greater detail.
The format can change.
The purpose does not.
Good test planning turns uncertainty into an intentional approach.
3. Test Design: Turning Requirements and Risks into Testable Scenarios
Knowing what needs testing is different from knowing how to test it effectively.
Test design converts requirements, risks, business rules and technical behaviour into meaningful scenarios.
This can include:
Positive scenarios
Negative scenarios
Boundary conditions
Error handling
Integration behaviour
Data combinations
Permissions and access
Accessibility considerations
Recovery scenarios
End-to-end journeys
Consider an age field that accepts users between 18 and 100.
Testing only:
Age = 25
tells us very little.
A stronger design might consider:
Blank values.
Characters instead of numbers.
Unexpected formats.
The value of test design comes from deliberately selecting conditions that reveal useful information.
This is why effective testing is not measured by the number of test cases written.
One hundred repetitive test cases may provide less confidence than twenty carefully designed scenarios.
4. Test Data: The Often-Underestimated Part of Testing
A well-designed test is useless if the required data does not exist.
Test data can become one of the most significant constraints in complex systems.
A scenario might require:
A customer with a particular account status
A user with specific permissions
Historical transactions
Particular combinations of records
Data existing across several integrated systems
An account in an unusual business state
Creating that condition may be considerably harder than writing the test itself.
Modern test planning should therefore consider test data early.
Can we create the data ourselves?
Does it need to be generated?
Can data be reset?
Are there privacy restrictions?
Do integrated systems require corresponding records?
Will automated tests require repeatable datasets?
Treating test data as an afterthought can delay entire testing cycles.
If a scenario matters enough to test, the ability to create the conditions required to test it matters too.
5. Environment Readiness: Can We Actually Test What We Designed?
Another common assumption is that a test environment will simply be available when testing begins.
In practice, environments can become one of the largest sources of delivery risk.
Services may not be deployed.
Configurations may differ.
Databases may be unavailable.
External dependencies may not be connected.
Certificates may expire.
Access may be missing.
Versions may not align.
A failed test therefore does not always mean the software contains a defect.
Sometimes the environment itself is the problem.
This is why environment readiness should be considered throughout planning.
Quality Engineers need to understand:
Where will each type of testing happen?
Which systems need to communicate?
Which services can be simulated or stubbed?
What access is required?
How closely does the environment represent the behaviour we need to validate?
An environment is not simply somewhere to execute tests.
It is part of the testing capability.
6. Test Execution: Generating Evidence, Not Ticking Boxes
Test execution is perhaps the activity most commonly associated with software testing.
Run the test.
Compare actual and expected results.
Pass or fail.
But execution should not become a mechanical exercise.
The purpose of execution is to generate evidence about the quality of the product.
While executing a planned scenario, a Quality Engineer may notice unexpected behaviour that is technically outside the individual test case.
A rigid approach might say:
"That isn't part of this test."
A quality-focused approach asks:
"Why did that happen?"
That curiosity matters.
Execution therefore includes planned testing, but it can also involve exploration, investigation, and learning.
Sometimes the most valuable discovery occurs because a tester follows something unexpected rather than simply continuing down the script.
7. Defect Management: More Than Logging Bugs
When testing identifies behaviour that differs from expectations, the issue needs to be investigated and communicated.
A useful defect report should help others understand:
What happened
What was expected
How the problem can be reproduced
Where it occurred
What evidence exists
What impact it may have
How significant or urgent it appears to be
But defect management extends beyond creating tickets.
Defects can reveal patterns.
If several defects originate from the same misunderstood requirement, perhaps the problem is requirements clarity.
If failures repeatedly occur around one integration, perhaps that interface needs deeper testing.
If the same category of defect repeatedly reaches production, perhaps existing controls are insufficient.
A mature team therefore asks not only:
"How do we fix this defect?"
but also:
"What is this defect teaching us?"
8. Retesting and Regression: Fixing One Thing Without Breaking Another
When a defect is fixed, two questions arise.
First:
Has the original problem actually been resolved?
That is the purpose of retesting.
Second:
Has the change affected anything else?
That is where regression testing becomes important.
These are related but distinct activities.
A developer may correct a calculation error in one component.
Retesting confirms that the calculation now works correctly.
Regression testing considers whether the change has unintentionally affected related functionality elsewhere.
As systems become larger, regression coverage becomes increasingly important and increasingly difficult to execute manually every time.
This is one area where automation can provide substantial value.
Stable, repeatable and business-critical regression scenarios are often strong candidates for automation.
But automation does not eliminate the need for judgement.
Teams still need to decide what deserves regression coverage and at what level.
9. Test Reporting: Turning Testing into Decision-Making Information
A testing team may have executed thousands of checks and identified hundreds of defects.
But stakeholders still need to know:
What does all of this mean?
This is the purpose of test reporting.
Good reporting does not simply list numbers.
For example:
1,240 tests executed.
1,210 passed.
30 failed.
Those numbers provide information, but not necessarily understanding.
What functionality failed?
How significant are those failures?
Are critical journeys working?
What remains untested?
Were there environmental limitations?
Are there outstanding high-risk defects?
What level of confidence does the testing evidence support?
Quality reporting should translate testing activity into decision-making information.
The objective is not to make the results look positive.
It is to make the quality position clear.
10. Test Closure: What Did We Actually Learn?
Traditional STLC models often finish with test closure.
In modern delivery, closure may not mean testing has permanently ended.
It may represent the completion of a release, sprint, milestone, test phase or significant delivery increment.
This is an opportunity to capture:
What was tested
What was not tested
Outstanding defects
Known risks
Test results
Coverage achieved
Limitations encountered
Lessons learned
Recommendations for future delivery
This information becomes particularly valuable when the next release begins.
Without learning, teams can repeat the same problems indefinitely.
A good closure activity therefore does not simply archive documents.
It improves what happens next.
Where Does Automation Fit in the Lifecycle?
Automation is sometimes described as a separate testing activity.
I see it differently.
Automation can support multiple parts of the lifecycle.
It can validate code changes during development.
It can exercise APIs.
It can support integration testing.
It can execute regression checks.
It can create or manage test data.
It can provide rapid feedback within delivery pipelines.
The important question is not:
"When do we automate?"
It is:
"Where can automation provide reliable, repeatable and valuable feedback?"
That makes automation part of the quality strategy rather than a separate objective.
The Lifecycle is no Longer Linear
This is perhaps the biggest difference between the traditional and modern STLC.
Imagine discovering during test execution that an acceptance criterion was misunderstood.
Do we continue because requirements analysis was already "completed"?
Of course not.
We return to the requirement.
Clarify it.
Update the implementation.
Modify the relevant tests.
Execute again.
Similarly, production incidents may reveal scenarios that should become regression tests.
Exploratory testing may expose previously unidentified risks.
Automation results may reveal integration problems.
New requirements may change the test strategy.
The lifecycle therefore contains feedback loops.
Requirements influence testing.
Testing influences development.
Development changes testing.
Production generates new risks.
Those risks influence future requirements and test coverage.
The lifecycle continuously evolves.
Connecting Shift Left and Shift Right
The previous two Amber Insights issues explored Shift Left and Shift Right.
The modern STLC helps connect those ideas.
Shift Left encourages quality activities earlier.
Shift Right extends quality learning into production.
The modern testing lifecycle sits across both.
It begins when teams start understanding what should be built.
And the learning continues after the software reaches users.
This means quality no longer belongs to one isolated box labelled:
TESTING
between development and deployment.
Instead, quality activities exist throughout the delivery lifecycle.
A Modern View of the STLC
Rather than seeing:
Requirements → Planning → Design → Execution → Closure
I prefer to think about the modern lifecycle as:
Understand → Assess Risk → Plan → Design → Prepare → Test → Learn → Improve → Repeat
Sometimes those activities happen sequentially.
Sometimes several happen simultaneously.
Sometimes we move backwards.
Sometimes production sends us back to the beginning.
What matters is not whether every organisation follows identical stage names.
What matters is whether the team continuously generates enough reliable evidence to understand the quality and risks of what it is building.
What Changes in Agile and DevOps?
Agile and DevOps did not make the principles of the STLC irrelevant.
They changed the cadence.
Instead of performing one large requirements-analysis exercise, teams may analyse smaller pieces of functionality continuously.
Instead of producing one large set of test cases before execution begins, tests may be designed alongside development.
Instead of waiting weeks for regression feedback, automated checks may execute with every significant code change.
Instead of waiting until the end of a project to discuss lessons learned, teams can inspect and adapt repeatedly.
The activities remain.
The feedback loops become shorter.
And that is an important characteristic of modern Quality Engineering:
The faster we can obtain reliable feedback, the sooner we can make informed decisions.
Where Does the Quality Engineer Fit?
Everywhere that quality information can improve a decision.
That does not mean the Quality Engineer performs every activity personally.
It means Quality Engineering contributes throughout the lifecycle.
During requirements, we challenge assumptions.
During planning, we identify risks and define the test approach.
During design, we consider testability and coverage.
During development, we collaborate and provide feedback.
During execution, we investigate behaviour.
During defect management, we help communicate impact.
During release decisions, we provide evidence.
After release, we learn from production.
The Quality Engineer therefore becomes much more than the person who receives completed functionality and tests it.
We become part of the system that helps the team continuously understand quality.
Final Thoughts
The Software Testing Lifecycle remains an important concept.
But we should be careful not to teach or implement it as though modern testing consists of completing one isolated testing stage after another.
Software delivery has evolved.
Quality Engineering has evolved with it.
Requirements analysis, planning, test design, data preparation, environment readiness, execution, defect management, regression, reporting and closure all remain valuable.
What has changed is how they connect.
Modern testing is iterative.
It is collaborative.
It is risk-driven.
It uses automation where automation creates value.
It begins earlier.
It learns from production.
And it continuously feeds information back into delivery.
The STLC should therefore not be understood simply as the life cycle of a testing phase.
It is better understood as the lifecycle through which quality evidence is continuously created, evaluated and used to improve software.
Because modern Quality Engineering is not about waiting for software to arrive so that testing can begin.
It is about making quality visible from the first conversation to the final release and continuing to learn long after the software reaches its users.
About the Author
Amber Idumwonyi is a Senior Quality Engineering Leader with extensive experience delivering quality engineering solutions across UK Government, defence, healthcare, and enterprise technology programmes. She has led Quality Engineering initiatives, developed Test Strategies, contributed to modern testing and automation practices, spoken at industry conferences, and founded LEMP, an organisation focused on practical technology education, mentoring, industry experience, and career development.
Amber is passionate about Quality Engineering, AI-assisted testing, technical leadership, and developing the next generation of technology professionals.
Amber Insights | Issue 005 – Risk-Based Testing: Focusing on What Matters Most
Amber Insights | Issue 006 – Building a Quality Culture Across Delivery Teams
Amber Insights | Issue 007 – Shift Left Testing Explained: What It Really Means in Practice
Amber Insights | Issue 008 – Shift Right Testing Explained: Learning from Software in the Real World
Explore LEMP's Software Testing programme and learn how you can get started.
Comments