The Savannah River flows on by!

The Savannah River flows on by!

The flow of testing is different in an Agile project.  In many cases, organizations have either not recognized the change in flow, or have created Agile/waterfall hybrids with test groups holding onto waterfall patterns.  While some of the hybrids are driven by mandated contractual relationships, the majority are driven by lack of understanding or fear of how testing should flow in Agile projects.

A typical waterfall testing flow, circa 1990s, was for a Quality Assurance (QA) manager to create an initial test plan during the project planning phase.  Next, the business analyst or someone acting in that capacity, would go off to gather the requirements.  In most organizations no one from QA would participate during requirements elicitation, instead work was compartmentalized like an assembly line. When the requirements were complete, QA personnel would begin to build tests scenarios, test cases and detailed test plans, as developers built the software in parallel. In enlightened organizations, developers and QA might have interacted during reviews to approve documents or code reviews. When the developers were done building, the QA personnel would test the projects deliverables and point out the defects.

The flow of testing in a typical Agile project is much more integrated. The idea of a high-level test plan is generally subsumed into the concept of the definition of done.  The definition of done includes the macro steps that will be required for each piece of work to be completed and ready to be implemented.  A general definition of done for a unit of work might include definition, coding, unit testing, system testing, user acceptance testing, documenting (as it provides value) and perhaps other macro categories of work. How each of these macro categories would be accomplished for a specific unit of work is defined contextually as a piece of work is accepted into a sprint during sprint planning.  The first two major test-planning events from the waterfall world, high-level test planning and writing test cases, are spread across the Agile project. As the Agile team breaks down the units of work into tasks and activities, the testing activities are defined and captured by the team.  Many Agile techniques begin building software by detailing the test cases (all types of testing) for each unit of work.  This happens as the team begins to understand the unit of work, but before a single line of code is written.  Conceptually, satisfying the tests cases proves the unit of work is done both at the code level and function level. Another typical difference in the flow of testing in an Agile project is amount of automated testing  which occurs every time the software is built (in its simplest terms, a build reflects putting the software together as a whole, as if it were to be put into production). Testing is a major component of all Agile projects, but the flow of that work is different than in waterfall.

There are a myriad of hybrids of waterfall and Agile. For example, when a separate team is created for testing and that team picks up after the development team writes and unit tests the code.  This hybrid holds on to the idea of an independent test team that runs tests and point out defects and shortcomings.  It also creates or continues a separation between QA personnel and the sprint team, which makes communication difficult.  This scenario also increases the cost of rework, because defects are found out-of-phase which means reopening units of work that were considered complete (and may have used to build other units of work).This scenario almost never makes sense.  A second, and perhaps more palatable hybrid, is the use of a hardening sprint in which the team performs a final set of tests. These tests sometimes include a final integration test or a final user acceptance test. This scenario is problematic as it requires building up a significant amount of work before review, thereby risking significant rework.  Hybrids are useful if testing has to be isolated due to contractual reasons, but they almost always generate rework and should be avoided.

The flow of testing in an Agile organization is different.  The reason Agile embeds testing into the basic flow work is to more effectively generate feedback for the entire team early in the process.  Breaking the testing into parts that can be integrated into the day-to-day flow of work helps facilitate communication in an environment where testing is not someone else’s responsibility. The flow of testing in Agile is an explicit recognition that good code is tested.