Agile Testing - Problems and Success Factors

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.