New edition Agile Testing

Agile testing today describes the common sense of good testing practice, no longer the antithesis of classic methods. Testers are equal members of agile teams, responsible for quality right from the start. Proven test techniques such as equivalence partition or limit value testing remain just as valid as test automation and the integration of specialist departments and operations.

Key Takeaways

• Agile testers who have not mastered classic testing techniques such as equivalence class testing or boundary value analysis are making a fundamental mistake, because these methods are also fully applicable in an agile environment.
• DevOps is implemented incorrectly in many companies: instead of creating a cross-team culture, it simply becomes a new department that works in the same isolated way as the classic test department used to.
• When several agile teams develop independently of each other, there is a gap at system level because no one checks whether the partial results actually fit together.
• Self-confidence as a tester does not mean pointing out errors with a raised index finger, but rather using concrete techniques such as decision tables to make others aware of their own blind spots.

Why testers are also needed in agile projects

Testers don’t disappear just because a team works in an agile way. This was precisely the misconception at the beginning: in some projects it was suddenly said “We no longer need testers because we are now working agile” This was due to a misunderstanding, probably a translation error from English.

Agile books refer to the development team. In German-speaking countries, “developer” is often understood to mean the classic programmer. If an agile team is only read as a programming team, the tester is no longer considered.

The assumption that testers simply do the testing has not proven to be true. There are individual lead developers with a strong commitment to quality, but this is more of a personal characteristic than a methodical approach. It is no substitute for testing expertise.

Agile is common sense today, no longer the exception

Agility has gone from being the exception to the norm. At an international level, for example in the work of the ISTQB, it is becoming increasingly difficult to clearly classify an approach as “agile” or “non-agile”. Agile has become a generic term for many proven practices.

The ISTQB Foundation Level therefore no longer distinguishes between agile and non-agile testing. Instead, the benchmark is: good testing versus bad testing. It is about good and bad practices, no longer about thinking in terms of camps.

The term “waterfall” as an antithesis has always been skewed. In practice, projects ran iteratively for decades, not in a single, irreversible run. What has changed is the speed and scope of the individual iterations, not the basic iterative principle itself.

The tester is a full member of the team, not an onlooker

A tester is part of agile projects right from the start, or not at all. A middle way, where you participate a little but are not allowed to have a say, does not work.

Ten years ago, testers often reported that they were left out of sprint planning and planning poker. The others planned, the testers were allowed to watch. This role has changed.

Today, testers help shape the project right from the start and are an equal member of the development team. He is no longer the one who has to pull the coals out of the fire at the end. It is precisely this emancipation of the testing role that is one of the biggest shifts of the last ten years.

Why testing techniques also apply in an agile environment

Agile testing does not make classic testing techniques superfluous. Anyone who calls themselves an agile tester and has not mastered equivalence class testing, boundary value testing or decision tables is working worse, not more modern.

Exploratory testing is also not just playing around. Session-based testing is set up deliberately, with a clear goal and using learned techniques. An engineering approach remains the standard, even if the framework is agile.

What has changed is the depth of the documentation. Today, 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 is still worthwhile. The principle behind this is lean: only do what is necessary to achieve the goal in the best possible way.

What has changed in ten years of agile testing

Three shifts characterize agile testing today: higher speed, DevOps as a cultural issue and greatly increased technical requirements for testers.

The pressure to react quickly to requirements and stay close to the market has grown significantly. This calls for test automation that fits neatly into continuous integration. The tools are now operating at a high level, but need to become more dynamic.

DevOps has had a strong influence on testing, but is essentially a cultural issue. In many companies, DevOps is delegated to a separate department, similar to how quality assurance used to sit somewhere on the 17th floor. This misses the idea of bringing people together. For testers, DevOps means above all: significantly more contact with operations and non-functional aspects.

Non-functional quality has become more important, especially security. Today’s testers must be broadly positioned, supplemented by a few specialists who go into depth on individual topics.

The tester becomes more technical

The profile in demand is shifting towards technical testers. This means someone who can test API interfaces, talk to developers and architects on an equal footing, find their way around DevOps scenarios and automate at least some aspects.

This requirement arises from the process itself. Nobody waits six months for a finished application that can then be tested via the interface. Instead, semi-finished products have to be tested in every sprint, often via interfaces and using what the developer is currently providing.

Who ensures the integration of complex systems?

The leap from individual applications to integrated system landscapes creates a gap. A small application rarely exists on its own. There are peripheral systems, complex integrations, and someone has to ensure the functioning of the overall system.

This can be illustrated using the V-model. On the left, descending side, the agile teams work on individual components. When moving up to the right-hand side, integration, many companies today lack precisely the instance that a test center used to cover virtually.

Scaling frameworks with value streams address this at epic level, but do not automatically solve the question of who tests the integration. In practice, separate agile integration test teams are created for this purpose. Their work is essentially a development task, namely connecting many systems together, and this is where the errors that individual teams have never seen become apparent.

Quality is everyone’s responsibility often means no one is responsible

The basic agile principle that everyone is responsible for quality is reversed without clear roles. If everyone is responsible, no one feels responsible in the end.

That’s why you still need someone to keep an overview. Management is not interested in the clean work of a single team, but in the entire business process. If ten or twelve teams are involved, often nobody knows exactly whether they are working together. Overall quality assurance is therefore becoming a big issue again, and test managers are needed.

In practice, the work of development and testing is becoming increasingly intertwined. The developer delivers a lot on the quality side: unit testing, code reviews, static analysis, preparation for automation. Testing expertise must be added so that both professions come together. The goal: a tester who can develop, a developer who can test.

Curiosity beats fear of AI

If you stay curious as a tester, you don’t have to worry much about your own future. The industry has changed constantly over the years, and interest in new things has remained high.

Nevertheless, there is still latent fear, especially around AI and tools such as ChatGPT. The concern of becoming superfluous is nothing new: testers have always been considered dispensable and yet they never were. In terms of content, the roles are changing, but the basic task remains the same.

Curiosity also includes personal development. Testing is often under pressure and stress, with the constant question of how much to test and where to automate. Making people mentally fit for this change process, solution-oriented and optimistic about the future, is a task in itself. Otherwise a lot will fall by the wayside.

How you work as a tester in an agile team

Self-confidence and coaching work better than a raised index finger. Those who help others out of deep self-confidence in their own techniques take the team with them instead of lecturing them.

The raised index finger always comes when I look down from above because I’m not so sure myself whether I’m right.

• Martin Klonk

A concrete example: One team had only tested test rules positively, i.e. only checked whether the rule was correct. However, there were numerous branches in the code. If you then take the team aside and set up a decision table together, you can see in practical terms how much more can be gained from this test. Some people will see the light.

This attitude can be summarized in three points:

• Make a conscious commitment to quality as a team and work in an engineering manner instead of just testing away.
• Be self-confident and explain yourself, involve developers and specialist departments instead of demanding from above.
• Ask with every test whether it really adds value. You can’t test everything, and not every test pays off.