I’ve made some comments, both on this blog and in various speechs/webinars/courses, about Agile development processes and how they affect testing.  However, I haven’t addressed the entire set of Agile principles at once.  I haven’t seen others who I would call “Agile agnostics” do so either.  (By ”Agile agnostics” I mean those who do not cast themselves as proponents for or opponents of Agile.)  So, in this post, I make some test-centric observations about the Agile principles from the Agile manifesto.  These observations are based on my experiences working on Agile projects and working with Agile teams.

• “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”  Like any iterative lifecycle, Agile breaks the development work to be done into iterations.  Each iteration should create a collection of features that are potentially valuable to customers.  I say “potentially” because not all iterations do result in the delivery of features to customers, but, when practiced properly, each iteration’s features could be delivered to customers; i.e., each iteration is sufficiently complete and of sufficient quality. This focus on regularly assuring quality (in the most holistic meaning of the term “quality assurance”) is helpful to the test team.
• “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” As a practical matter, this principle is one of the most challenging for testing, because there is a point in each iteration at which changes become highly disruptive in terms of complete testing of the change and the associated possible regressions.  Balancing quality and agility in the face of desired changes is important.
• “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”  Most Agile teams and projects seem to have settled on iterations of between two to four weeks.  At the end of each iteration, as mentioned above, the software should work and be potentially deliverable to customers.  This principle is challenging to testers, because of the short timeframes for test preparation and execution, but it also provides the benefit of limiting the number of features delivered for testing at any one time.  Short iterations also help to contain the number of bugs that could accumulate in the code prior to test execution, a distinct advantage to the test team.
• “Business people and developers must work together daily throughout the project.”  This principle, while laudable in theory, is difficult.  Often, surrogates represent the users or customers, and business people are too busy to participate daily.  In addition, the absence of the word “testers” from the list above can create challenges.  However, accessibility of the business stakeholders to the project team is certainly helpful to the testers, and good Agile practices can make it easier for test teams to resolve questions about expected behavior.
• “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”  This principle simply re-states what is called “theory Y management.”  Simply put, the theory is that people are essential self-motivated and want to get work done.  Tom DeMarco and Tim Lister, in their books on management, are probably the leading current proponents of theory Y management in the software engineering discipline.  From a testing point of view, to the extent that individuals are motiviated not simply to produce large volumes of features, but to produce quality features, this principle supports the testing process when realized.
• “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  Certainly, no one can argue with the idea that excessive documentation can reduce the efficiency of a project.  However, this principle can pose some challenges for the test team if the face-to-face conversations happen when testers are not in a room, thus leaving them disconnected from decisions about how the system should work, what features it should contain, etc.  The use of brief daily meetings to re-synchronize the team can help manage this challenge, but it’s essential that these meetings expand to become so long that they become simply a different form of inefficiency. It’s also important that Agile teams remember that “less documentation” does not mean “no documentation;” essential documentation, including for testing, must still be prepared.
• “Working software is the primary measure of progress.”  While this principle is also laudable from a testing point of view—most testers would accept that working software speaks for itself—this principle is sometimes stretched to the point that smart metrics, including metrics of quality and testing progress, are abandoned.  Good practices in terms of testing and quality metrics, measurement and management apply in Agile projects as with any other project, though the specific forms of the metrics tend to differ from the metrics used on sequential lifecycles.
• “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”  Working a normal workweek, without overtime, weekends, excessive pressure or stress, is certainly a desirable goal.  In some cases, I’ve seen Agile teams avoid the “death march” behaviors that arise at the end of some projects when large feature backlogs and enormous numbers of bugs overwhelm the teams.  However, I’ve seen plenty of situations where overtime is a regular feature at the end of every iteration, and where this burden falls disproportionate on testers.  This principle remains under-fulfilled in practice, to the detriment of testers.
• “Continuous attention to technical excellence and good design enhances agility.”  Music to the testers’ ears, indeed.  Of course, some programmers find it hard to make the transition from big chunks of development work, done on rushed schedules (with the concomitant quality compromises) to the smaller chunks of work, done carefully, that are proposed by this principle.  I hope to see better realization of this principle on actual projects as software engineering professionals internalize the practice of Agile development.
• “Simplicity—the art of maximizing the amount of work not done—is essential.” As testers, this principle is also a joy to hear, and to see.  Simplicity implies a small set of high-quality, working features, the opposite of the untestable, complex, sprawling applications that are so hard to cover in any reasonable sense.  Again, though, this is a major mental shift for many software engineering professionals, and this principle is under-realized in practice.
• “The best architectures, requirements, and designs emerge from self-organizing teams.”  As with the theory Y management topic discussed earlier, this is an assertion about the nature of human psychology and capabilities that is beyond the scope of this book.  However, I have observed that Agile processes don’t always scale smoothly to large, complex, and especially distributed projects and teams.  I have also seen and heard of instances where the reality of “emergent design” and “emergent architecture” was considerably less satisfactory than this principle might lead us to expect; the cliché about “painting oneself into a corner” can apply.  With complex applications, testers should watch carefully for problems with performance, maintainability, and reliability, because these can reflect fundamental design and architecture problems that are difficult to fix after too many iterations have gone by.
• “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Of course, project retrospectives are hardly an Agile innovation, but all testers would agree that such periodic reflection is a great idea. Testers should encourage the actualization of this principle, and ensure that becoming more effective at producing quality is part of the agenda.

These observations are reflections on a work-in-progress.  Software engineering teams are still learning how to apply Agile approaches.  Agile approaches have not (yet?) been successfully applied to all types of projects or products.  Some tester challenges remain to be surmounted with respect to Agile development.  However, Agile methodologies are starting to show promising results in terms of both development efficiency and quality of the delivered code.

So, what do you think about Agile methodologies and testing?  I’d be happy to discuss this topic with interested readers of this blog.