Project Management

Quality Stages in Definition of Done

Yesterday at work I was in a meeting with my team to redefine our definition of “Done”. During this meeting one of them pointed out that every level in the definition of done should include a quality gate/stage where QA Engineer’s can play some role if not the main role. In traditional development, QA Engineers were only performing functional tests and reporting bugs. But agile software development is a highly integrated process where each stage: requirements, design and development could impact the amount of effort needed for testing. I have noticed a number of releases which had quality issues and these issues were not found until or after the release. Some of these issues were also considered as “showstoppers” and needed an immediate bug fix release. If these quality issues could have been detected and prevented during the stages (requirements, design and development) then the effort required in final system testing would go down. I have  derived the idea of Quality stage from Quality funnel mentioned in Agile QA practices of Code71, Inc. (Rayhan, 2008).

Quality Funnel
Quality Stages in Software Development

Different Stages of Quality

Quality Stage 1: Requirements Review. Every story in the product backlog item should meet INVEST (Vaibhav, 2007) which means a story should be independent, negotiable, valuable, estimable, small and testable. This should be part of the ongoing pre-planning activities like story grooming/estimation. The QA engineer along with the team can collaborate and help the Product Owner identify requirements which are forgotten or gone missing and also identify issues which could result in an incomplete product. In general, issues which go unidentified in this stage are “hot issues” and can stop a live release(If you are not using Feature releases ;)) and result in “failing sprint”. Therefore, “Requirements Review” is the most important quality stage. Normally a story should go through this stage more than once for a story to be ready for sprint.

Quality Stage 2: Design Review. Make sure the design for the story is in-line with architecture guideline/style and related requirements are met. Normally if a bug/issue is identified in this stage it means the product does not work as intended. The issues found in this stage could be a “Hot” or a “Cold” issue.

Quality Stage 3: Development Review. Make sure all appropriate unit tests/behaviours are defined and automated. Coding standards are followed. Code review is performed and all unit tests are successful and part of continuous integration. In general bugs/issues that appear during this stage are regression bugs which appear when a new feature is implemented on the existing functionality. These bugs are normally cold issues and should be fixed in this stage.

Quality Stage 4: Test Review. Make sure all appropriate UI functional tests/behaviours are defined, automated and executed as part of continuous integration. All exploratory test session should be defined and executed. Similar to the previous stage bugs/issues that appear during this stage are regression bugs which are cold issues and should be fixed in this stage.

Proposed Usage of Quality Stages

Analyzing the current situation, a feasible solution would be to include the Quality stages in the definition of “done”. The QA Engineer can play the role of a Quality Consultant and collaborate with the team to perform requirements review, design review and development review. By doing this the QA Engineer would ensure better quality at every stage of agile software development and avoid situation like forgotten requirements or tasks within the sprint and reduce the effort needed in the testing phase.


Happy Easter!!!