Software Testing - Definition Of Done

Agile and Scrum are not alien to us anymore. Industry has embraced Scrum and Agile because of the value they provide. People have used Scrum in many ways and have modified it to suite their unique needs and project requirement. It is not rare to see task boards with many variant of columns, with stretched tasks, defects, burn down charts and so on.  If you are not familiar with how requirements are managed in Agile / Scrum world, you might find this article on User Stories interesting.

To summarize , in Agile world typically requirements are managed in the form of user stories in product backlog. During sprint planning meeting, product owner gives a list of user stories that are important for the current sprint along with their condition of satisfactions. Team then breaks this story into small tasks and gives their estimated time to finish them.

These tasks are posted on the task board along with the user stories and team moves them on the task board. Typically any given task can move in four stages, not started, in progress, done and done done. Tasks are treated as ‘done’ when developers have finished their coding and then it moves to ‘Done Done’ when testers have finished testing it.

Often teams are not clear on what is the meaning of ‘Done’ and when should any task be treated as ‘Done’. Different people interpret ‘Done ’ in different ways according to the roles they play in Scrum. For example, developer might say task is done if it is working on their machine, tester will treat task as done if it is in a state where it is testable, scrum master might say it is done when it is out from the backlog and so on. Since people have different meanings of done, tasks are done but their could be some conditions under which it is really not done, probably there is some scope for design / code improvements, documentation and so on..

As a result of this, management and customer get a false sense of velocity. They think that features are done and are ready for production, but in reality they are done with some caveat. They are done but there is some technical debt associated with them. Features are done, but they are partially tested, hardly documented, rarely optimized and ready for release but without confidence.

One very simple solution for this problem could be to define explicitly and clearly so that every one knows what is the meaning of done. This will also give chance to the product owners to see, if they want to do something more before treating tasks as done. One example of done could be “ Task is done when it is implemented, unit tested, code is reviewed, integrated, tested across browsers and is ready for further testing”

Once definition of done is agreed by the whole team, it can be implemented in the form of either checklist or individual items like unit testing, code review, integration etc can be treated as separate tasks and can be attached to every story.

This should be responsibility of whole team to ensure that every person in the team is adhering to the definition of done  Every time a task is moved from in progress to done, team should ensure that it is not only working on developer’s machine but is done according to the agreed definition of done.

Once we have this definition in place, team will be a bit closer to their final goal of producing top quality re-factored code which can be deployed anytime with confidence.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11379785/viewspace-690482/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/11379785/viewspace-690482/