Ah, quality--always the last phase in traditional plan-driven projects! So I've left defect detection and prevention as the last topics covered in this article series. Used to being the caboose on the train, QA staff have come to expect shortened time frames for testing, specs that don't match the product delivered, and little interest in their input until the last few weeks of the project. As one of my colleagues used to say, "Well, we must be done testing because today is the release date!"
In a change that pleasantly surprises most quality personnel, agile software development brings QA back into the analysis and design of the product, keeping QA heavily involved in decision making throughout the entire lifecycle. Because incremental code is being developed each iteration, QA is now testing at the very beginning of the project lifecycle instead of waiting for something to be "thrown over the wall" at the end. And because throughput is increased as a result of agile's iterative and incremental development, QA finds itself with a need to become more technical as it must automate testing at all levels, not simply via macros run on the GUI.
Typically, quality planning includes defining how to perform quality assurance and quality control activities as they relate to standard QA practices, organization policies, and procedures. Agile QA team members should still address this need and work with the project team to determine what tools and technology they will use in writing, running, and reporting tests and results, as well as what metrics will be tracked in each iteration. It is important to engage developers in this definition, as they will be contributing to testing by writing unit tests and helping with the framework for automating regression and acceptance testing. Product owners also must be involved, helping to define and run the acceptance tests. In agile methodologies, everyone contributes to defining, maintaining, reviewing, and enhancing the quality of the product and the process.
Quality assurance, with its focus on preventing defects, is translated into the agile practice of having committed QA resources on the development team that participate in daily decision making throughout the lifecycle of the project. Their input during elaboration and design helps developers write better code. As a result, more "what if" scenarios are considered and planned for, as the collaboration between coders and testers gives the coders more insight than if they were to plan the work on their own. Likewise, the testers gain added insight into the expected functionality from the coders and the product owner, and they are able to write more effective test cases for the product.
Another aspect of quality assurance is the idea of continuous improvement, which the agile principles of constant feedback and responding to change support. Stopping points meant for inspection and adaptation are built into all agile methodologies. Continuous improvement is practiced in planning meetings, daily activities, and iteration reviews and retrospectives. A recognized exercise in the iteration retrospective is determining what went well in the iteration, what did not go well, and what changes the team wishes to make in the next iteration.
Quality control places its emphasis on finding defects that have already slipped into the system and working with developers to eliminate those defects. This bug checking is done within the iteration, using techniques such as daily builds and smoke tests, automated regression testing, unit testing, functional and exploratory testing, and acceptance testing. Everyone participates; no one is exempt from the task of ensuring that the coded feature meets the customer's expectations. The goal is to find and fix all the bugs in order to have the feature accepted by the product owner by the end of the iteration.
In some agile methodologies, quality drives the entire software development process in something called "test-driven development" (TDD). In this approach, tests are written and automated first, before the functional code is written. As stated in one of the FAQ responses at Testdriven.com's Web site, "Write a small test, write enough code to make the test succeed, clean up the code. Repeat."
Whether you choose to embrace typical agile activities or something more extreme, quality is guaranteed to improve when implemented in the spirit of the Agile Manifesto and its guiding principles. And as this last article in the series draws to a close, I hope that you've seen how agile practices are in sync with most, if not all, of the tenets outlined in the Project Management Body of Knowledge. I invite you now to learn more about agile by visiting the following sites and to look for more of my articles next year on how to make the transition to agile.
Click Here to Read Relating PMBOK Practices to Agile Practices Part 1 of 4
Click Here to Read Relating PMBOK Practices to Agile Practices Part 2 of 4
Click Here to Read Relating PMBOK Practices to Agile Practices Part 3 of 4