A reader recently asked if IÂ’d write on how agile handles quality assurance. Because the agile framework that my team uses is Scrum, IÂ’ll describe the process in relation to Scrum, but keep in mind that most agile methods treat QA similarly.

First of all, the Scrum process does not demand that developers use any particular engineering practices. But most agile engineering techniques will integrate well, including test-driven development, continuous integration, and pair programming. If Scrum does not dictate which engineering processes a team should employ, it implicitly asks developers to address quality every sprint. Because Scrum asks teams to deliver a potentially shippable increment every sprint, some of that time must be dedicated to ensuring the product functions. In theory, the team should be able to demonstrate the progress it has made to the customer at the end of each sprint. So it follows that the team would want to eliminate as many bugs as possible before presenting its work to the customer.

So how does quality assurance take place over the course of the sprint? One way to accomplish this is by writing robust definitions of the acceptance criteria for each story at the Sprint Planning Meeting. This is an important first step toward ensuring the work lives up to the customerÂ’s standard of quality by fully defining what his or her expectations are. Of course, defects will be detected over the course of the sprint. When that happens, the team can either write more stories to address these problems in a future sprint or resolve them within the sprint that theyÂ’re discovered. I recommend that teams attempt to fix the bugs as soon as they find them. ItÂ’ll mean more work during the sprint and may lead the team to take on less work (lower effort estimates) for ensuing sprints. However, the extra work is worth it because the development team always knows where it stands: Even if the progress it makes is less than the team has averaged historically, the code is clean, bug-free, and ready to be presented to the customer.

To help a team compensate for the extra work of addressing bugs (which will only grow along with the size of the codebase), I recommend automating as much of the testing as possible, including end-to-end (system) testing, load testing, Â“negative testing,Â” and security testing. When the team is capable of automatically testing the system to quickly assess if itÂ’s broken or not, it will be able to make more sweeping design changes than manual testing would allow. The importance of breaking the habit of working in phases is further described in this introduction to Scrum.

Yes, this is a demanding process that appears to add a lot of work to a teamÂ’s regular sprint goals. But thatÂ’s not really the case. Instead, this agile approach to QA simply revises when QA takes place. Rather than building in a linear fashion and resolving bugs at the end, Scrum and agile prod teams to address defects as soon as theyÂ’re discovered. Such conscientious coding might add work in the short-term, but it ensures that the team is always working with clean, functional code and vigilantly eliminating bugs, which significantly cuts development time overall.