Agility pervades everyday life in development departments. Where it is not yet practiced, it is currently being introduced. But what does the change from conventional to agile development approaches look like? What are the pitfalls and how does this change quality assurance, especially testing? What are the consequences for the familiar roles in testing? It is obvious that the switch to an agile approach will bring about far-reaching changes. Testing is not spared either. So let’s embrace the change and discover the opportunities for testing.
Agile is often advertised as a project management method. This is understandable, as the consulting industry thrives on packaging ideas into sellable and tangible products. As a result, there are different variants of Agile with different names that contain a wealth of tool sets, methods and procedures. And those who implement these well should be allowed to experience the benefits: Reducing bureaucracy, accelerating the development of effectively useful results and maximizing customer benefit.
In our view, however, agility is much more than that. It is a culture and an attitude that allows a team to pursue its goals in a self-organizing, courageous and transparent manner. And this results in far-reaching changes: more self-efficacy among employees, more commitment, greater satisfaction and more flow in the implementation of tasks.
However, changes do not fall from the sky and are rarely purely as described in the textbook. You simply have to start the actual work somewhere. All the agile principles, methods, best practices, procedures and defined approaches are a very good start.
Starting with Scrum or Kanban à la textbook is a promising entry into the agile world. And training courses on agile testing, such as the Agile Extension to the ISTQB Certified Tester Foundation Level or the iSQI Certified Agile Tester, will also get you on your way. And once these processes are up and running, the first successes can be achieved. However, in our experience, the boost for benefits and success only ignites once the agile values have been internalized in the team or organization and the associated processes have been established.
One indicator of this is the results of the retrospectives, namely when the team begins to constructively question the current process and redesign it to suit the specific situation. It develops its own agile approach that suits the team and the context and offers individuals the opportunity to contribute according to their skills and interests and achieve the common goals.
We want to pick out a few aspects and questions from agile testing here to give you an idea of what to expect on your journey.
Tight and efficient test automation is essential in agile projects. The test pyramid model is often used for this: This describes the types of tests to be carried out, the ways in which they are used, the associated costs and the dependencies between the individual test types and stages.
For example, it is often the case that automated unit tests form the basis, which are carried out during development and before all other tests. Depending on the structure of the system, various intermediate stages are possible, right up to the final manual tests as part of the acceptance process by the customer.
The four test quadrants are often mentioned in the same breath as the test pyramid. These often help us in projects to categorize all the different types of tests, whether dynamic or static, functional or non-functional, in one picture.
Janet Gregory and Lisa Crispin have taken a fundamental look at what tests are needed in agile projects and who should ideally carry them out. Test experts generally like to use the V-model to determine which reviews or tests need to be carried out by whom and when, even if their project does not work according to the V-model. This may still work to some extent for some Kanban teams, as Kanban is fundamentally open here. But in most agile teams, the integration levels are very close together and hardly separated from each other in terms of personnel.
As Gregory and Crispin both come from an XP environment, they looked for a consistently different approach and found the most effective model to date, which has already proven itself many times in practice. They have called it the “four test quadrants”, as they have divided the test into four significant groups based on considerations by Brian Marick using two dimensions.
The ideas of classic test methods are of course still valid in an agile context and should be applied: the grouping of similar behavior as in equivalence classes, the consideration of limit cases as in limit value analysis or the focus on logical and technical states as in state-based testing. At their core, all of these methods continue to offer the possibility of creating test cases according to the motto: As little as possible, as much as necessary.
However, there is usually not enough time to explicitly work through these methods in agile projects. It is therefore essential to internalize the ideas of these methods and not just work through them procedurally. Of course, this point must be scrutinized once again, taking into account their use in safety-critical environments.
Exploratory testing is a valuable addition to structured tests. In an agile context, these tests become even more important. Experienced testing experts such as Cem Kaner and James Bach advocate a creative approach to testing, according to which the tester is guided by intuition and not by a method or tool 4. A good, creative tester will have an inkling of where the errors lie.
This approach amounts to an exploration of the software. The tester pokes into the system and follows paths that may lead to errors. If he does not find any, he returns and follows a different path. Due to his many years of experience, the experienced tester will know where to look. Similar to the term “code smell” commonly used in the development environment, which developers smell when they see suboptimal code, you could say that testers perceive the “bug smell”.
We have made another interesting observation in our projects. Good, experienced and explorative testers use the structured test procedures implicitly - they have already internalized their basic ideas.
And that’s just the start of the test procedures. Session-based testing, Acceptance-Test-Driven Development and Behavior-Driven Development play with the shared responsibility for quality in the team and help to live quality throughout the entire process.
Last but not least, there is the question of the roles in the test process: Do you still need a test manager in an agile project? The answer is quite clear: it depends. It is obvious that in a professional project environment - whether traditional or agile - many quality assurance tasks need to be organized and carried out. While a test manager is the focus of test planning and control in the traditional approach, the agile team should organize quality itself. However, especially in agile projects, it can be enriching for the team to have access to someone who has test and quality assurance expertise, who knows test procedures and who can coach the team during test activities.