Agile quality assurance starts with conversation, not with testing. Teams that clarify requirements early, derive acceptance criteria analytically and classify risks up front prevent defects at the source. Testing then builds up in stages: static analysis, unit testing, integration testing and system testing. Skipping a stage is allowed, as long as it is a deliberate decision with a known risk.
Key Takeaways
- Bringing testers into the requirements phase avoids expensive rework, because acceptance criteria get checked for testability while the user story is still being written.
- Anyone who deliberately cuts test scope has to name the risk explicitly and keep checking whether it is still acceptable. Otherwise quality gaps open up unnoticed.
- Static code analysis and peer reviews are the fastest quality measures in the process, because they remove defects before the code ever runs.
- AI will derive test cases from acceptance criteria and run them, but it still needs human oversight at a meta level, because an AI is only as good as its training.
Agile Quality Assurance Starts with Talking
Before anyone writes code or builds a feature, the team needs to agree on what it is building and where it is headed. That conversation is where agile quality assurance begins, long before the first test. Only from that shared understanding can you work out how to test it.
This dialog is the most important phase of the entire development process, and it is fine if it is also the longest. Whatever gets discussed properly at the start shortens everything that follows. That is not unique to agile. In a traditional process testers should be involved early too, but the agile framework pushes everyone to sit down together right at the beginning.
In traditional projects, testers could stay on the sidelines for a long time: let the business analysts do their part, then take a look later. That comfort zone disappears in an agile setting. Testers have to make sure that everyone involved gets on board early, themselves included.
How a Requirement Becomes a Testable User Story
Requirements land in the backlog, usually as user stories. For example: “As Thomas, I want the button to be green so I can tell it apart from the red background.” A story like that is where the work starts, not where it ends.
The acceptance criteria come out of the conversation about the story. Which button do we mean? Which exact color code? Should similar buttons change too? What happens when someone clicks it? Each question sharpens the requirement and makes it verifiable.
If you listen with a tester’s ear, you pick up early on the points that will matter at acceptance. This is where the value shows: when the tester helps write the story, testing ideas make it into the requirement before a single line of code exists.
Everyone on the Team Needs a Tester’s Mindset
Quality is not the job of a lone gatekeeper tester who stamps the result at the end. Ideally, everyone carries a tester’s perspective around, including the person who writes the requirement and the person who builds it.
When the requester and the developer both look at a story through a tester’s eyes, they think about how to secure quality while there is still time. When the business stakeholder joins the table and adds their view, the loop is closed.
For this to work, teams need bridges between the business side and IT. Young, newly formed teams need support to get across what feels like a divide. The IT people don’t bite when you explain a business process to them, and the domain experts aren’t out of touch. Once those bridges are in place, collaboration takes care of itself.
Keep the Dialog Focused, Not Maximal
Forcing everyone into one room rarely helps. What matters more is that nobody ends up working alone in isolation. Stepping back, thinking about what has been written down and sleeping on it makes sense, but afterward the topic has to go back into discussion.
Small groups that check in with each other again and again and keep refining a topic often get further than one large meeting. Once a topic has matured enough, it moves into refinement or backlog grooming, where the key people build a shared understanding.
Getting the balance right is hard. Pushing everything into refinement sessions blows up the format, and not every detail is relevant to everyone. Sometimes the business details need to be untangled separately, or the engineers have to go back to the design. The key is to split the conversations so the right ones happen with the right people.
Four Environments, Four Test Levels That Build on Each Other
A typical setup has four environments that become more stable from the developer’s machine to production. As stability grows, so does the testing that runs on each environment.
| Environment | Characteristics | Test Focus |
|---|---|---|
| Development | Unstable from the outside, stable enough to work in; hardly any realistic test data | The developer checks whether the build matches their understanding of the requirement |
| Integration | The software is added to the existing systems | Interfaces, versions, data exchange between systems |
| Acceptance | Close to production: data, interfaces, performance | The business side checks business processes end to end |
| Production | Live operation | Post-go-live check |
Before anything runs, there is static testing. Static code analysis tells you whether the code is understandable, maintainable and clean, or whether it contains dead code, syntax violations and unsuitable constructs. This first quality loop produces findings without executing the program.
In banking, a malicious code analysis is often added, because security matters: nothing may be hidden in the code that later skims off half a cent unnoticed. Next comes a review by a second developer. Static analysis and reviews are quick wins. They start early and make the system more resilient in ways that would take a lot of effort to recover later.
Skip Test Levels Deliberately, Never by Accident
The full sequence of static analysis, unit testing, integration testing and system testing is the ideal case, not a requirement for every situation. The first five lines of code don’t need static analysis.
What matters is awareness. Anyone who skips a level has to make that call actively and name the risk that comes with it. With five lines the risk is small. With 5,000 lines you lose track, and then you need an extra safeguard.
This is the test manager’s job: creating that awareness. Why do we test, what can we do, what can we leave out on purpose and what risks follow from that? Part of the job is also checking again and again whether a risk that was accepted once is still acceptable, or whether the circumstances have changed.
Who Tests the Interface? Ownership in Integration Testing
In integration testing, clear ownership decides the quality. If each side assumes the other one is testing, a gap opens up in the middle of the interface that nobody checks.
The opposite doesn’t help either. If both sides test deep into each other’s part, the overlap is so large that nobody moves forward. It has to be clear who owns which part of the interface and who tests where.
Every new increment changes that arrangement. Each side understands its own part technically, and both have to keep talking about whether the parts still work together. The domain experts behind each system belong in this testing as well.
Which Tests Belong in a Single Sprint
After static testing, a sprint covers component and unit testing, system integration testing and system testing. Once the business side has looked at the feature for the first time and the acceptance criteria are met, the Definition of Done is reached and the sprint can close.
Note what that means: the development process isn’t over yet. The software isn’t in production, but the sprint is done and the next iteration can start. Acceptance testing comes later and is often required by regulation.
Unit tests are usually automated because a version goes through several iterations. Building and maintaining that automation takes effort, but it creates a solid foundation. If every function has been tested with all the data variations you can think of and possible errors are handled, very little can go wrong on the technical side.
Deliver Several Times per Sprint, Not Five Minutes Before the Review
The most common trap is the last-minute rush at the end of the sprint, when everything gets checked in, merged, pushed and pulled five minutes before the review. You avoid it by delivering finished pieces early.
Once a story has passed static analysis, review, unit testing and integration, deliver it and let the business side take a look before you pick up the next story. That way you get feedback within the same sprint, can fix defects right away and present a tested story at the end, instead of piling three days of testing onto the final stretch.
In the heat of the moment, these early deliveries often get forgotten, without anyone meaning harm. An outside view helps here: a friendly nudge reminding the team of an interim delivery works better than pressure. By the retrospective at the latest, the team can agree to ship every finished story right away from now on.
The Test Manager’s Role in an Agile Team
The dedicated test manager role has almost disappeared in agile teams. Ideally, the test manager sits in the dev team as a T-shaped person who brings test management skills and can also write code. In practice, you often find full-stack developers with a test manager next to them.
In that case, the test manager’s job is to raise quality awareness among the developers and remind them of steps that would otherwise slip through. Rather than managing tests from the outside, they pull people in so that everyone is involved early.
Why Knee-Jerk Testing Doesn’t Raise Quality
When quality is poor, the first reflex is usually: “We need to test more.” Then test cases get written in bulk at the acceptance stage, often not good ones, just lots of them. That doesn’t improve quality.
What typically emerges are two ends with a gap in between. On one side, lots of acceptance tests from the business perspective. On the other, unit tests that almost every developer writes out of their own sense of quality, but mostly by gut feeling, without peer review and without an analytical method. Neither side goes deep, and the two don’t connect.
What is missing is a systematic approach. Many people remember ad hoc testing or requirements-based testing because the terms sound familiar. That there are other test design techniques often gets overlooked. With the right skills you ask different questions and notice, for example, that a text field accepts special characters and their behavior needs testing.
If that test case gets written down early, the developer can handle the situation while building the feature. Quality is then built in from the start.
Test Scope Is Risk Management, Not Full Coverage
Very little software needs exhaustive testing. It wouldn’t pay off. A moon mission, where human lives depend on the code, calls for a lot more effort. With everyday software you can leave test cases out, but you need to know which ones.
The selection follows risk, based on two factors: likelihood and impact. Highly complex, deeply nested or library-dependent code gets special attention. So do areas with high business risk. A login is often technically simple, but it has to work, because without a login no software works.
In agile development across several iterations, regression testing comes on top, and there too you don’t rerun everything that was ever tested:
- New features (progression testing): as many test cases as are economically justifiable, to test them thoroughly.
- General regression: high-risk test cases that check the software’s vital functions.
- Changed areas: additional medium-risk test cases that check to the left and right of the change whether the test object still works.
A risk classification of the test cases makes this selection quick. No doctoral thesis, just rough levels such as high, medium and low for complexity and impact. With that matrix you can pick exactly the right tests for each regression run, and if the test cases are automated, adding one more costs next to nothing.
Documentation Doesn’t Contradict Agile
The Agile Manifesto doesn’t say documentation is unimportant. It says there are more important things, and the more important thing is the conversation. At some point, though, what was discussed has to be written down, so you can still trace what you did in three months or three years.
A risk classification on each test case, a defined test object and test cases stored in a structured way help in agile teams in particular, because test cases get picked up again and again and teams change. The documentation stays short: a few lines on how you arrived at the chosen test scope, no novels.
The team decides on the scope together. The product owner, representing the business side, and the developers work out a sensible scope together, instead of a single test manager writing a big test plan in the background. That way the whole team shares the same understanding.
Quality as an Attitude, AI as a Tool with Blind Spots
“See quality as an attitude, deal with automation and use artificial intelligence, but know the difference between what it can do and what it can’t.”
(Christian Mercier)
AI will automate more and more of testing. Tests can be derived from acceptance criteria and executed without anyone writing every test case by hand. That shifts the work, but it doesn’t replace oversight.
An AI has errors and blind spots too, and it is only as good as its training. If you don’t train the AI yourself, you have to look even more closely at what it does and what it doesn’t. Humans move to a meta level here: they need to know what the automation can do and where its limits are.
Quality doesn’t end with the review. Acceptance testing and a post-go-live check are part of an end-to-end process. Everyone who works on software should bring this attitude, not just the tester.
Frequently Asked Questions
When should testers be involved in an agile project?
As early as the discussion about the requirement, before the first line of code exists. Anyone involved in formulating the user story can identify the points that will later be crucial for acceptance and refine the acceptance criteria with questions such as: What is the exact color code? How does the button behave when clicked? In the traditional approach, testers could wait and review things later; in an agile environment, that luxury is gone.
How much coordination does a requirement need before it’s implemented?
Not everyone needs to be around the same table, but no one should be left alone in a back room. Small groups that repeatedly hash out a topic often achieve more than a large meeting. Only once a certain level of maturity is reached do we move on to refinement or backlog grooming. Packing everything into refinement sessions goes beyond the scope, because not every detail is interesting to everyone. It’s okay to sleep on it overnight; then return to the discussion.
What’s the point of static code analysis before dynamic testing even begins?
It provides findings without running the program: dead code, syntax violations, inappropriate constructs, as well as insights into readability and maintainability. Combined with a review by a second developer, this is the fastest way to improve quality, because errors are eliminated before execution. In the banking sector, malicious code analysis is often added to ensure that nothing later siphons off half a cent unnoticed.
How can two teams ensure that a shared interface isn’t left untested?
By explicitly clarifying responsibility. If each side assumes the other is already testing it, a gap remains in the middle that no one checks. The opposite approach is equally unhelpful: if both teams perform deep testing in the other’s area, it just creates overlap. It must be clear who is responsible for which part. Every new increment changes this coordination, and the subject matter experts behind it must also be involved.
Can a sprint be considered complete even if the software isn’t in production?
Yes. After static testing, the sprint includes component and unit testing, system integration testing, and system testing. If the business unit verifies functionality and the acceptance criteria are met, the “Definition of Done” is achieved, and the next iteration can begin. Acceptance testing follows later and is often required by regulations. The development process does not end with the conclusion of the sprint.
Does software have to be tested comprehensively?
No; for most applications, that would not be cost-effective. Test cases may be omitted, but you must know which ones. The selection is based on risk, determined by probability of occurrence and impact: highly complex, deeply nested, or library-dependent code, and areas with high business risk. A login is often technically simple, but no software works without it. Different standards apply to a moon mission.
Does writing more test cases simply help when the quality is poor?
No. Typically, this results in many arbitrary test cases being created for acceptance testing, along with unit tests written on gut feeling, without peer review and without an analytical method. There remains a gap between these two extremes; neither side is thoroughly covered. What’s missing is a systematic approach: in addition to ad hoc testing and requirements-based testing, there are other test design techniques that allow us to ask different questions.
Can artificial intelligence take over the writing of test cases?
To some extent. Tests can be derived from acceptance criteria and executed without having to write every case yourself. This shifts the work, but it does not replace oversight: AI has blind spots and is only as good as it has been trained. Those who do not train it themselves must look more closely. Humans work at the meta-level and must be aware of the limits of automation.
