Agile software development seeks to embrace adaptability, collaboration, and short-term planning in over more traditional predictive or plan-driven software development methods. Agile developers tend to use small time increments (iterations or time boxes) of mere weeks when planning tasks, often forsaking detailed long-term planning. The traditional quality assurance methods involving long-term planning, budget projections, and overarching deadlines must be altered in several ways to accommodate the emphasis on adaptability and incremental objectives.
The incremental approach emphasizes the delivery of quality software in short iterations. Objectives are smaller in scale. This is in contrast to a more traditional planned approach that generally performs testing only after the completion of most of the coding. In theory, making software testing a priority from the outset takes the general QA philosophy of problem prevention one step further by focusing on preventing defects before they occur, not finding them after creating the entirety of the software.
Traditional QA also relies heavily on documentation, test plans, and bug reports. QA in an agile environment shifts the focus from planning and documentation to interpersonal reaction between team members. While both types desire collaboration, the methodology contrasts greatly. Agile QA uses the iterative approach to constantly involve project sponsors and users in the creation process. Traditional QA generally abhors changing requirements because their budget and deadlines focus on shipping the deliverable after one or more years’ worth of development; any requirement mutation can potentially undo thousands of hours of work. Because Agile QA breaks up their deliverables into approximately month-long projects, the team embraces a philosophy of constant evaluation and adaptation.
Perhaps the key difference between these two forms of QA can be found in how they deal with the unknown. Traditional QA wants to identify and address nearly all goals, obstacles, and methods before committing resources, while agile QA sidesteps this need with the iterative approach. Agile QA tolerates partial or imperfect knowledge, but only under the condition that team members and sponsors regularly and formally meet face-to-face.
The challenge of agile QA roots in its emphasis on face-to-face communication between team members. Generally speaking, agile developers work in small teams of less than ten members within one office to facilitate this strategy. If a project demands a larger team, the QA divides them into smaller groups, each responsible for a specific goal. In any event, the focus on direct communication removes the reliance on documentation as a means to maintain a cohesive effort. The face-to-face method also attempts to address obstacles as they arise rather than deal with them after months of programming and testing.
In the end, one can hardly claim that one approach is inherently “better” than the other. The decision of which method to adopt will give way to the project’s scope, budget, and available personnel. Some sponsors may balk at the idea of an incremental approach; others will accept agile QA’s strategy of sacrificing long-term planning for adaptability.