QA and Agile

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.

2 thoughts on “QA and Agile

  1. James K

    One thing I’d like to see more of when agile or scrum is discussed is the need to change the requirements based on the resources or the resources based on the requirements. Also I’d like to see more discussion on scope.

    QA can easily get trampled in the agile/scrum process in my experience or QA can cheat and not adequately test something and the developer isn’t paying attention enough to notice and everyone is “suprised” near the end of the sprint by the problems.

    Sprint planning seems to be the most important part of the process, but it often seems the assumption is you just plan and adapt and everything will work out. I’d like to see more organizations dissolve their sprints and restart more often rather than grinding on a bad sprint plan.

  2. admin Post author

    Thanks for your comments James. Scope can be tracked within the Enhanced Burndown Chart and if you feel like you’re getting trampled, I would suggest tracking your velocity and using velocity as one of the guides to help with sprint planning / negotiations with the Product Owner.

    Learning to push back on a product owner during the planning meeting can be hard. I would recommend this article over at Agile Journal as further reading (http://www.agilejournal.com/articles/columns/column-articles/1915-how-scrum-generates-increased-productivity-part-three-the-team)

    Quality should never be used as a lever. I would suggest reading this article on technical debt- ( http://www.danube.com/blog/kanemar/technical_debt_and_the_death_of_design_part_1.html)

    Part two and three are available from the danube page as well.

    Disagree with your last statement. Sprint planning should be done – my feelings are:
    (a) Your PO is estimating your backlog – try having your team estimate your backlog
    (b) Your requirements aren’t written with good user stories with clear acceptance criterias outlined (Definition of Done)

    I’d recommend this blog from Michael James for further reading on that: http://www.danube.com/blog/michaeljames/user_story_examples_and_counterexamples

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>