Agile Testing - Problems and Success Factors 

 29 March 2021

Like it?
Share!

The agile transformation brings challenges with it. After many software testing projects that we have accompanied, there are nevertheless a few typical problems that occur again and again, despite all the individuality. And there are also a few factors that positively influence and accelerate the transformation.

Problem #1: Limitation to the test

Agile procedures create transparency. And thus, deficiencies in quality quickly become visible. The first reaction in practice is often to focus the concentrated energy on "agile testing" or "agile testers" - precisely with the motivation to focus on quality. However, this approach only partially solves the problems.

Quality in the agile team means above all responsibility of each individual. And even though it makes a lot of sense to have a tester's perspective in the team, this does not exempt from the joint responsibility for quality. It is not the agile tester who brings quality, nor the testing methods. Quality must be lived throughout the 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. Thus, all of the following methods and tips provide an impulse and starting point, which, however, must be thought through further in the projects individually and depending on the context.

Problem #2: no patience in 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 existing - this also applies to test methods and test approaches. Here it is important to be vigilant and not to judge too quickly whether a change has made a difference or not. The effects of a change may only be visible after some time or iterations. If the change is hastily reversed here, a valuable opportunity for further development may be lost.

Problem #3: THIS is the solution

Tools, methods or gurus are often seen as a solution for all the challenges presented by the transition to agile. Typical example "to accelerate" the tests: test automation. But if the foundation is not stable, even the tool does not solve the problem. Quite the opposite: "If you automate crap you still have crap - only faster". So it's easy to fall into the method trap: "We have to test this way! Why? Because it says so in the book! Likewise, the saying "A fool with a tool is still a fool" reveals that the use of tools (e.g. for test automation) needs to be well considered and chosen to fit the project essay.

Success factor #1: Freedom for personal responsibility

Agility thrives on values such as self-responsibility, transparency and courageous decisions. For this, the necessary freedom must be left for the development of the test strategy, for example. Testers must have the possibility to try out methods and tools, to discard them and to take other paths. This also requires an appropriate error culture in which errors are seen as an opportunity for learning in the team and not as a failure of an individual. This is especially important when moderating retrospectives.

A change in thinking by superiors, e.g. the line test manager, is also necessary here. If the testers' decisions are repeatedly questioned or overruled from above, this quickly affects the motivation in the team and leads to the exact opposite of what one wants to achieve with the agile approach: Instead of a team bubbling over with creativity and performance, things like safeguarding, logging and decision templates are then relied on.

Success factor #2: Soften classical thinking

Sometimes the biggest challenge in the transformation is to get the "old" thinking out of the heads. This applies to the team as a whole, but especially to testers who come from traditional projects into agile. For the tester, it is no longer about working through "his" area - test concept - test design - test execution - defect management, but about making his know-how available to the team. Likewise, it is often unusual for developers from a traditional project environment to contribute so much to quality themselves and not just throw the finished modules "over the wall" to the test team.

This breaking down of silo thinking requires a sure instinct when it comes to 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 until these behavioural patterns are changed.

Success factor #3: Retrospectives

In our experience, one of the biggest levers for the success of agile testing is the proper execution of retrospectives. By the way, this is not only true for the agile context - but also for the traditional one. The emphasis here is on "proper", because a meeting where the majority is not active and the rest is complaining about the last 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, to correct processes and to address the elephant in the room - which no one else is talking about.

For quality and test topics, it is worthwhile to conduct separate retrospectives that only address these topics. This can be particularly helpful in the start-up phase of agile testing, when the basic test strategy is being developed or the characteristics of test automation are being worked out. Nothing is more frustrating than realizing after weeks or months that the chosen path - e.g. the choice of test tools or a framework - was the wrong one. Retrospectives can help to uncover these points early on and prevent conflicts from arising in the first place.

Bonus success factor #4: Your personal path

The concrete 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 in the iterations, to the type and extent of customer feedback, to the degree of test automation, to the level of detail and scope of the results and their documentation. Every project and every organization is highly individual and the shift to agile methods thrives on experience, best practices and sharing. And so we would like to encourage you here: talk to others about your project. There is so much knowledge and experience in your company and networks - use it and shape your own agile path.

Do you like this post? Share it: