Agile IT development processes require flexible and well-reflected testing methods
Agile, light-weight development approaches such as Scrum promise increased efficiency, shorter release cycles, and higher quality software. They also represent a paradigm shift in software testing.
Agile test management – Testing as a continuous process in IT development projects
Agile development methods such as Scrum put the focus on future users. The client no longer receives a product at the end of the software project that more or less meets his wishes and requirements. Rather, he is consistently included in the development process, and changing requirements or priorities are integrated continually within very short release cycles. For this reason, software developed using the Scrum approach is in general much more frequently subject to change than that developed in classically organised projects. This fact also poses new challenges for testing. With traditional approaches such as the waterfall model, the software testing is usually scheduled for the end of the project. In contrast, agile testing represents a continuous process that takes place in parallel with other disciplines such as development or integration. In this way, errors can be found and eliminated at an early stage. This is also important from a business perspective, because the sooner an issue can be solved, the lower the consequential costs will be.
AGILE TEST MANAGEMENT – FASTER TESTING WITH FLEXIBILITY AND COST-EFFECTIVENESS
However, testing must also be able to keep pace with the significantly greater speed and flexibility of the agile development process. Test cases, for example, have to be created more quickly and carried out more efficiently as well. This is usually only achieved through a high degree of test automation. On the other hand, the tester himself is expected to continually reflect on the methods chosen and adapt them in line with the agile approach. He is not completely on his own, however. This is because in agile projects, the tester acts no longer as an isolated unit, but is a part of an interdisciplinary team in which all members also perform work outside of their key tasks: The developer also carries out testing tasks, and the tester development tasks. This is ultimately beneficial to the quality of the end result, as all of the participants assume more responsibility for the overall project. This approach also moderates the tendency towards a destructive interaction between developers and testers that can frequently be observed in traditional projects.
AGILE TEST MANAGEMENT – SPRINTS AND ITERATIONS IN REAL-TIME
In large projects, however, extending the agility approach across the entire test process is still more the exception than the rule. In practice, testing usually takes place only at the end of a sprint or an iteration. This is first and foremost due to the fact that at the beginning of the very first iteration there is often no software yet that can be examined for its quality. In practice, this delay frequently results in a kind of mini-waterfall model, with mini-waterfalls within the individual iterations (see Fig. 1). To make sure that this does not lead to a testing bottleneck, which in the worst case can hamper or even put an end to further development, such deferrals must be responded to in a timely manner. To this end, it is advisable to raise awareness of the issue with the project leader, who must plan ahead to ensure that there is adequate time for all required testing activities. If they lag too far behind, the scope of testing and/or of the functionality of the software to be delivered should be adapted correspondingly (see Fig. 2).
Figure 1: 1 mini-waterfall per iteration
Figure 2: Delays from other activities accumulate in the testing activities
AGILE TEST MANAGEMENT – RISK-BASED PRIORITISING INCREASES BUSINESS-RELEVANCE
One method of dealing with these time constraints is risk-based testing. Here, the testing intensity is oriented towards the risk of incorrect behaviour. This is based on a prioritisation of the individual test cases, with the priority of a test case reflecting the importance of the requirement. If, at the end of an iteration, there is not enough time left to process all the test cases, those with the lowest priority are disregarded. They can be processed at a later stage. This approach increases testing efficiency whilst ensuring maximum system stability. What is critical for risk-based testing is that the prioritisation is approved by the client. This is the only way to ensure business relevance. An additional level of testing – for example in the form of an embedded tester – can also provide a measure of relief from time pressure. The embedded tester acts as an objective authority and as an interface between the different teams. Depending on where the project is facing problems, he can carry out a variety of test methods such as explorative testing, or the first acceptance of the user stories. This enables errors to be eliminated within the iteration in which they have occurred, and prevents them from being carried over to the following cycle.