Every software development lifecycle model, from sequential to spiral to incremental to Agile, has testing implications. Some of these implications ease the testing process. We don’t need to worry about these implications here. Some of these testing implications challenge testing. Here we discuss only the challenges created by the Scrum methodology, and distinguish those from other types of testing issues. 1) Dealing with the Volume and Speed of Change
One of the principles of Agile development is that project teams should “welcome changing requirements, even late in development”. Many testing strategies, especially analytical requirements-based testing, become quite inefficient in such situations. However, risk-based testing accommodates change, since we can always add risks, remove risks, change risks, and adjust the level of risk. If test execution is underway, we can adjust our plan for the remaining period based on this new view of quality risk. Smart automated testing also accommodates on-going change. With care, automation at the graphical user interface can be maintainable. Automation at stable command-line interfaces does not tend to suffer severe maintainability problems. Many of these challenges arise from change in the definition of the product and its correct behavior . When the test team is not kept informed of these changes, or when the rate of change is very high, this can impose inefficiencies on the development, execution, and maintenance of tests.
In sequential lifecycles, test teams can have a long period of time in which to develop and maintain their, in parallel with the development of the system, prior to the start of system test execution. Some more formal iterative lifecycle models, such as Rapid Application Development and the Rational Unified Process, often allow substantial periods of time between test execution periods for each iteration. These intervals allow teams develop and maintain their test systems. Agile methodologies like Scrum are less formal and faster moving. Consistent with the evocative name, sprints, these methodologies use short, fast-paced iterations. This will further squeeze the test team’s ability to develop and maintain test systems, compounding the effects of change noted earlier. Testing strategies that include an automation element have proven particularly sensitive to this challenge. The risk-based element of the recommended strategy can help. Risk-based testing focuses on the important areas of test coverage, and de-emphasizes or even cuts less important areas, relieving some of the pressure created by the short iterations. This ability to focus proves especially helpful for test teams also under tight resources constraints. Test teams in an Agile world should develop, maintain, and execute tests in risk priority order.
Agile methodologies stress good, automated unit testing. Open-source test harness such as J-Unit and Cpp-Unit minimize the tool costs of doing so, overcoming one keyobstacle to automation. Such automated unittests allow what Agile proponents call refactoring. Refactoring is the redesign of major chunks of code or even entire objects. The automated unit tests provide for quick regression testing of refactored code. Some Agilists recommend substituting automated unit tests for design, as in Test Driven Development. While this sounds good in theory, there are two problems that we tend to observe with this approach in practice. First, unit testing has limited bug-finding utility So, while unit testing helps, the main filter to prevent excessive field failures remains system testing Second, under the guise of excuses both valid and not-so-valid, many programmers do not create automated unit tests and in some cases don’t do any unit testing at all. This creates a great deal of trouble for the test team, which, as mentioned above, remains a critical bug-removing filter. The short test execution periods on Agile sprints, compared to sequential projects, means that the degree of damage caused by one or two days’ of test progress blockage due to highly buggy code is higher than in a sequential project. Delivery of unstable, buggy code will undermine one of the key benefits of the risk-based testing portion of the strategy, which is the discovery of the most important defects early in the test execution period. It also inevitably leads to a large degree of code churn during testing, since so much must change to fix the bugs. amount of change can ultimately outstrip even the ability of the best automated regression test system to keep up, which would then lead to lower defect detection effectiveness for the test team.
In iterative lifecycles like Scrum, though, code that worked in previous sprints gets churned by new features in each subsequent sprint. This increases the risk of regression. Agile methodology advocates emphasize good automated unit testing in part to manage the regression risk inherent in such churn. However, good unit testing has limited defect removal effectiveness, as cited earlier. So, automated regression testing via unit tests will likely miss most of the regression bugs. Therefore, we need effective regression testing at the system test level (which has a higher level of defect detection effectiveness). By combining risk-based testing with the automated regression testing, test teams can effectively manage the increased regression risk.
Agile advocates promote “faceto-face conversations.” This, of course, is another name for a meeting. From a marketing perspective, it was smart of the Agile advocates not to use the word meeting in the Agile Manifesto, but the reality remains. The flip side of this problem, in some organizations, is that everyone gets invited to ever meeting, the meetings balloon in number and duration, managers and leads are not available to manage and lead their team because they are in meetings much of the day, and effectiveness and efficiency drop. Teams using Agile methodologies must achieve the right balance between documentation and meetings. Teams using Agile methodologies must have crisp, efficient meetings that move the project forward and course-correct, not meetings that grind the team down and go around in circles.
In some cases, in spite of reducing the scope of testing, the test team still can’t execute all the tests in the available time at the end of a sprint. If so, rather than ruining their weekend to run every test, the test team can select the most important tests using the risk priority number. Less important tests can slip into the next sprint. (You’ll notice that Scrum and other Agile methodologies allow user stories to slip from one sprint to the next in the same way.) Of course, if the test team must consistently triage its tests in this fashion, they should again adjust the test extent mapping downward for future sprints.
Most of our clients adopting Agile methodologies have retained the independent test team, or at least the independent tester, to some extent. For those retaining the independent team, most have chosen to partition the team across the sprints in some way, often making each tester answerable on a day-to-day task basis to the Scrummaster or other sprint leader, rather than to the test manager. In the case of having independent testers but not independent test team, there is no test manager. This provides some advantages, especially to the person leading the sprint.
None of these challenges (or advantages, for that matter) arises from Agile methodologies per se; it just happens that Agile methodologies as typically practiced tend to accentuate them. The challenges are not insurmountable, if an independent test team exists. The test team, lead by a good test manager, can introduce centripetal forces that will bind the team together and makes its actions consistent and congruent. These forces then balance the sprint-specific centrifugal forces that tend to push the test team members into sub-optimizing for their sprint as well as isolating the test team members from broader testing considerations
One approach to managing these challenges is to have a separate test period that follows the development sprint. (To keep the terminology clean, some like to call this approach an alternation of development sprints following by test sprints.) Some of our clients have pursued this approach. It does seem to work for them, when the test team remains engaged in the development sprint. In other words, if the test team disengages from the development team during the development sprint, you are just exchanging one form of siloing for another.