The agile transformation brings challenges with it. After many software testing projects that we have accompanied, despite all the individuality, there are still a few typical problems that occur again and again. And there are also a few factors that positively influence and accelerate the transformation.
Problem #1: Restriction to the test
An agile approach creates transparency. And this is how quality deficiencies quickly become visible. The first reaction in practice is often to focus all efforts on “agile testing” or “agile testers” - with the motivation to focus on quality. However, this approach only partially solves the problems.
Quality in an agile team means above all the responsibility of each individual. And even if it makes a lot of sense to have a tester’s perspective in the team, this does not release everyone from their shared responsibility for quality. It is not the agile tester who brings quality, nor the test methods. Quality must be lived by the entire team, by the developer, product owner, tester and whatever other roles you want to fill.
Therefore, when dealing with testing in an agile context, it is important to always keep in mind that it is only one part of the quality measures. It is much more important to work on promoting and living quality in the team. All of the following methods and tips provide an impetus and starting point, but these must be considered further in the projects individually and depending on the context.
Problem #2: no patience with agile testing
Agility is change and change takes time. Transferring testing with its various aspects into the agile context takes time. In addition, agile is always about questioning the status quo - this also applies to test methods and test approaches. It is important to be vigilant here and not to make hasty judgments as to whether a change has made a difference or not. The effects of a change may only be visible after some time or iterations. If you are too quick to reverse the change, you may miss a valuable opportunity for further development.
Problem #3: THIS is the solution
Tools, methods or gurus are often seen as the solution to all the challenges presented by the transition to an agile approach. A typical example of “speeding up” tests: test automation. But if the foundation is not stable, the tool will not solve the problem. Quite the opposite: “If you automate crap, you still have crap - only faster”. It’s easy to fall into the method trap: we have to test like this! Why? Because that’s what the book says! The saying “A fool with a tool is still a fool” also reveals that the use of tools (e.g. for test automation) needs to be carefully considered and chosen to suit the rest of the project.
Success factor #1: Freedom for personal responsibility
Agility thrives on values such as personal responsibility, transparency and courageous decisions. To achieve this, the necessary freedom must also be left for the development of the test strategy, for example. Testers must have the opportunity to try out methods and tools, discard them and take different paths. This also requires an appropriate error culture in which errors are seen as an opportunity to learn as a team and not as the failure of an individual. This is particularly important when moderating retrospectives.
A rethink by superiors, e.g. the line test manager, is also necessary here. If testers’ decisions are repeatedly questioned or overridden from above, this quickly affects motivation in the team and leads to the exact opposite of what you want to achieve with the agile approach: instead of a team bubbling over with creativity and performance, the focus is then on things like safeguarding, logging and decision templates.
Success factor #2: Softening traditional thinking
One of the biggest challenges during the transformation is getting the “old” way of thinking out of people’s heads. This applies to the team as a whole, but especially to testers who are transitioning from traditional projects to agile. For the tester, it is no longer about working through “their” area - test concept - test design - test execution - error management, but about making their expertise available to the team. It is also often unfamiliar for developers from a traditional project environment to contribute to quality themselves and not simply throw the finished modules “over the wall” to the test team.
Breaking down the silo mentality requires a sure instinct when providing support. It is a balancing act between empathy and maintaining the necessary pressure to change. It is also a process that can take several months to change these patterns of behavior.
Success factor #3: Retrospectives
In our experience, one of the biggest levers for the success of agile testing is the proper execution of retrospectives. Incidentally, this applies not only to the agile context, but also to the traditional one. The emphasis here is on “properly”. After all, a meeting in which the majority of people are inactive and the rest are “moaning about the last few weeks” has nothing to do with a retrospective. It is precisely in this self-reflection of the team that the power lies to quickly assess the paths taken, correct processes and address the elephant in the room - which no one else is talking about.
For quality and test topics, it is worth holding separate retrospectives that only address these topics if required. This can be particularly helpful in the initial phase of agile testing when the basic test strategy or the characteristics of test automation are being developed. Nothing is more frustrating than realizing weeks or months later that the path taken - e.g. in the choice of test tools or a framework - was the wrong one. Retrospectives can help to uncover these issues at an early stage and prevent conflicts from arising in the first place.
Bonus success factor #4: Your personal path
The actual implementation of agile testing depends on many factors: Company, project, structures, application, team…. This affects everything from release planning and the proportion of hardening iterations to the type and scope of customer feedback and the degree of test automation through to the level of detail and scope of the results and their documentation. Every project and every organization is highly individual and the switch to agile methods thrives on experience, best practices and exchange. And so we would like to encourage you here: talk to others about your projects. There is so much knowledge and experience in your company and networks - use it and shape your own agile path.
Frequently Asked Questions
Who Is Responsible for Quality in an Agile Team?
Quality is the responsibility of the entire team, not a single role. Neither an agile tester nor specific testing methods alone can ensure quality. Developers, product owners, testers, and all other stakeholders share this responsibility. A tester’s perspective within the team remains valuable, but it does not replace shared responsibility. Testing is only one part of quality assurance.
How quickly can you assess whether a change in the testing process has made a difference?
Often only after several iterations. Agility means change, and change takes time—especially when well-established testing methods and test approaches are being questioned. Anyone who prematurely reverses a change because no effect is yet visible may be missing a valuable opportunity for further development. Vigilance, yes; premature judgment, no.
Does test automation reliably speed up testing in an agile project?
Not if the foundation is unstable. A tool doesn’t solve a problem that lies in the process itself: If you automate junk, you still end up with junk—just faster. The use of tools must be carefully considered and chosen to fit the rest of the project’s framework. The same pitfall lurks in methods that are adopted simply because that’s how they’re described in the book.
What happens when managers regularly override the decisions of agile testers?
Motivation within the team drops rapidly, and the results are reversed. Instead of a team that demonstrates creativity and high performance, the focus shifts to verification, documentation, and decision templates. Testers need the freedom to experiment with methods and tools in their test strategy, to discard them, and to explore other approaches. This requires a culture of error that treats mistakes as learning opportunities for the team.
What changes for testers and developers who transition from traditional projects to agile teams?
The division of labor disappears. Testers no longer work solely within their own area—that is, test plan, test design, test execution, and defect management—but instead make their expertise available to the team. Developers can no longer simply “throw” finished modules over the wall to the testing team; instead, they contribute to quality themselves. Breaking down this silo mentality can take several months.
How can you tell if a retrospective isn’t working?
If the majority of participants remain passive and the rest just complain about the past few weeks, it’s not a retrospective. Its power lies in the team’s self-reflection: quickly assessing the paths taken, correcting processes, and addressing the elephant in the room that no one else is talking about. This applies in both agile and traditional contexts.
Is there a universal blueprint for agile testing?
No. Implementation depends on the company, project, structures, application, and team. This applies to release planning, the proportion of hardening iterations, the type and scope of customer feedback, the degree of test automation, as well as the level of detail and documentation of the results. The path to achieving this relies on experience, best practices, and collaboration with others within the company and across one’s own network.
