Agile testing today stands for the common sense of good testing practice, no longer for the opposite of classic methods. Testers are equal members of agile teams and share responsibility for quality from the very start. Proven test techniques such as equivalence partitioning and boundary value analysis remain just as valid as test automation and close involvement of business departments and operations.
Key Takeaways
- Agile testers who have not mastered classic test techniques such as equivalence partitioning or boundary value analysis are making a fundamental mistake, because these techniques apply fully in an agile setting as well.
- Many companies get DevOps wrong: instead of building a culture that spans teams, they turn it into yet another department that works just as much in isolation as the classic test department once did.
- When several agile teams develop independently of each other, a gap opens up at system level, because nobody checks whether the partial results actually fit together.
- Self-confidence as a tester does not mean pointing out defects with a wagging finger. It means using concrete techniques such as decision tables to make others aware of their own blind spots.
Why Agile Projects Still Need Testers
A team working in an agile way does not make testers disappear. Yet that exact misconception was there at the start: in some projects, people suddenly said, “We don’t need testers anymore, because we’re agile now.” Behind it was a misunderstanding, most likely a translation problem.
Agile books talk about the development team. In German-speaking countries, “developer” is usually understood as the classic programmer. Read an agile team as a team of programmers only, and the tester drops out of the picture.
The assumption that developers would simply take care of testing along the way has not held up. There are individual lead developers with high standards for quality, but that is a personal trait rather than a methodical approach. It cannot replace testing expertise.
Agile Is Common Sense Now, Not the Exception
Agility has gone from special case to standard. At international level, for example in the work of the ISTQB, it is getting harder and harder to classify an approach clearly as “agile” or “not agile”. Agile has become an umbrella term for many proven practices.
That is why the ISTQB Foundation Level no longer distinguishes between agile and non-agile testing. The yardstick is now good testing versus bad testing. It is about good and bad practices, no longer about thinking in camps.
Using “waterfall” as the opposite pole was always a bit off. In practice, projects ran iteratively for decades, not in one single pass that could never be reversed. What has changed is mainly the speed and scope of each iteration, not the iterative principle itself.
The Tester Is a Full Team Member, Not a Bystander
In agile projects, a tester is part of the team from day one, or not at all. A middle ground where you get to join in a little but have no say does not work.
Ten years ago, testers often reported being left out of sprint planning and planning poker. The others planned; the testers were allowed to watch. That role has changed.
Today, testers help shape the project from the start and are equal members of the development team. They are no longer the ones expected to save the day at the very end. This emancipation of the testing role is one of the biggest shifts of the past ten years.
Why Test Techniques Still Apply in Agile Testing
Agile testing does not make the classic testing craft obsolete. Anyone who calls themselves an agile tester without having mastered equivalence partitioning, boundary value analysis or decision tables is doing worse work, not more modern work.
Exploratory testing is not just playing around either. Session-based testing is set up deliberately, with a clear goal and using techniques you have learned. An engineering approach remains the standard, even inside an agile framework.
What has changed is how much gets documented. A single test case is rarely described in as much detail as it used to be. If automation engineers are working on the same case in parallel, a more detailed description still pays off. The principle behind it is lean: do only what is needed to reach the goal as well as possible.
What Ten Years of Agile Testing Have Changed
Three shifts shape agile testing today: higher speed, DevOps as a question of culture, and much higher technical demands on testers.
The pressure to respond quickly to requirements and stay close to the market has grown considerably. That calls for test automation that fits cleanly into continuous integration. The tools now work at a high level, but they need to become more dynamic.
DevOps has had a strong influence on testing, but at its core it is about culture. Many companies hand DevOps off to a separate department, much like quality assurance used to sit somewhere up on the 17th floor. That misses the whole idea of bringing people together. For testers, DevOps mainly means much more contact with operations and with non-functional aspects.
Non-functional quality has become more important, security above all. Testers today need a broad skill set, complemented by a few specialists who go deep on particular topics.
The Tester Is Becoming More Technical
The profile companies are looking for is shifting toward technical testers: someone who can test APIs, talk to developers and architects on an equal footing, find their way around DevOps scenarios and automate at least in places.
That demand comes from the way teams work. Nobody waits six months anymore for a finished application that can then be tested end to end through the user interface. Instead, half-finished products have to be tested in every sprint, often through interfaces and with whatever the developer is providing at the moment.
Who Makes Sure Complex Systems Fit Together?
Moving from individual applications to integrated system landscapes opens up a gap. A small application rarely stands on its own. There are surrounding systems and complex integrations, and someone has to make sure the overall system works.
The V-model illustrates this well. On the left, descending side, the agile teams work on individual components. On the way up the right side, the integration side, many companies today lack exactly the body that a test center used to cover, at least virtually.
Scaling frameworks with value streams address this at epic level, but they do not automatically settle who tests the integration. In practice, dedicated agile integration test teams form for this purpose. Their work is essentially a development task, namely connecting many systems, and that is exactly where the defects show up that individual teams never saw.
When Everyone Owns Quality, Often No One Does
The agile principle that everyone is responsible for quality turns into its opposite without clear roles. If everyone is responsible, in the end nobody feels accountable.
That is why you still need someone who keeps the overview. Management does not care about the clean work of a single team; it cares about the entire business process. With ten or twelve teams involved, often nobody knows for sure whether their work is converging. Overall quality assurance is becoming a big topic again, and test managers are in demand.
In practice, development and testing work are growing more and more intertwined. Developers contribute a lot on the quality side: unit tests, code reviews, static analysis, groundwork for automation. Testing expertise has to be added so that the two professions come together. The goal: a tester who can develop and a developer who can test.
Curiosity Beats Fear of AI
Testers who stay curious don’t need to worry much about their future. The industry has changed constantly over the years, and interest in new things has stayed high.
Still, there is a latent fear, especially around AI and tools such as ChatGPT. The worry about becoming redundant is nothing new: testers have always been seen as dispensable, and yet they never were. The content of the roles is changing, but the basic mission stays the same.
Curiosity also includes personal development. Testing often happens under pressure and stress, with the constant question of how much to test and where to automate. Getting people mentally ready for this change, solution-oriented and optimistic about the future, is a task in its own right. Otherwise a lot gets left undone along the way.
How to Make an Impact as a Tester in an Agile Team
Self-confidence and coaching work better than a wagging finger. If you help others from a deep confidence in your own techniques, you take the team along instead of lecturing it.
“The wagging finger always comes out when I look down on people from above, because I’m not so sure myself whether I’m right.”
(Martin Klonk)
A concrete example: one team had tested its validation rules only positively, checking just whether each rule fired. But the code was full of branches. Take the team aside and build a decision table together, and you show in very practical terms how much more this test can deliver. For some, a light goes on.
This attitude comes down to three points:
- As a team, commit deliberately to quality and work like engineers instead of just testing away.
- Be confident and explain yourself; bring developers and business departments along instead of making demands from above.
- For every test, ask whether it really adds value. You can’t test everything, and not every test pays off.
Frequently Asked Questions
Can developers simply take on testing roles in agile teams?
No, this assumption has not held up. There are individual lead developers with high standards for quality, but that is a personal trait and not a methodological approach. It cannot replace testing expertise. The misconception arose in part from the term “development team,” which in German-speaking countries was often interpreted as referring solely to a team of programmers. Testers were then effectively left out of the picture.
Is a distinction still made between agile and non-agile testing in test training?
As of 2023, the ISTQB Foundation Level no longer makes this distinction. The focus is on good versus bad testing and good practices versus bad practices, rather than on factional thinking. Even in the international community, it is becoming increasingly difficult to clearly classify an approach as agile or non-agile, because “agile” has become an umbrella term for many proven practices.
Is exploratory testing just free experimentation without guidelines?
No. Session-based testing is deliberately structured, with a clear goal and using learned techniques such as equivalence partitioning, boundary value analysis, or decision tables. An engineering-oriented approach remains the standard, even within an agile framework. What changes is the level of documentation: A single test case is rarely described in as much detail as before, unless automation engineers are working on the same case in parallel.
What technical skills are expected of testers in agile projects?
What’s needed is a profile capable of performing API testing, communicating with developers and architects on an equal footing, navigating DevOps scenarios, and performing at least some automation. The reason lies in the approach itself: No one waits half a year for a finished application that can be thoroughly tested via the user interface. Semi-finished products are tested in every sprint.
Why do many companies miss the point of DevOps?
Because DevOps is delegated to a separate department instead of emerging as a cross-team culture, much like how quality assurance used to be isolated on the 17th floor. This approach does nothing to bring people together. For testers, DevOps in 2023 meant, above all, significantly more interaction with operations and with non-functional aspects, especially security.
Who tests the entire system when many teams are working on a business process in parallel?
Often, no one does, and that’s exactly where the gap arises. In the V-model, agile teams on the left side work on individual components; as they move up to the right, integrating side, there’s no entity to fill the role that a test center used to cover virtually. Scaling frameworks with value streams address this at the epic level, but they do not clarify who tests the integration.
Is the agile principle that “everyone is responsible for quality” sufficient?
No, without clear roles, it backfires: if everyone is responsible, in the end no one feels accountable. Management is interested in the entire business process, not in the meticulous work of a single team. If ten or twelve teams are involved, often no one knows whether the results are converging. That’s why we still need someone with an overview.
Will AI make the tester’s job obsolete?
This concern is not new: Testers have always been considered dispensable, yet they’ve never actually been. While the roles are shifting in terms of content, the fundamental mission remains the same. Curiosity is more important than fear of tools, because the industry has been constantly changing for years. This also involves preparing people mentally for this process of change.
