10. Getting Testing Done in the Sprint – the Definition of Done

Are we done? When this is unclear the team will do too less or too much. Both are bad. The Definition of Done helps to define when you are done, the same as a master test plan helps to define the test levels. A good definition of done specific for your team and project will definitely help knowing when you're ready and to get testing done in a sprint. Mainly because you know when you're done.

Making a good definition of done is a trivial task and books are written about it. A good starting point are these posts:

One thing I really like to keep in mind when defining a Done List are:

Risk Analysis, and together with this the Master Test plan. I should be clear what the risks are and what the impact is on when you are done. You can think of Done ListItems, which help understand the level of testing to be done, like:

All High Risk BPI’s have a test coverage of ..% and no open bugs

All high prio test cases are automated

Low Risk, Low Business PBI’s may have 10% open low impact bugs.

Test Levels, balance the unit, functional and acceptance testing and define where what is tested. Definition of Done items like; all unit tests are green, all functional testing is done or all written acceptance tests are executed, are unclear. How many tests should we write to be done? Code Coverage is one for unit testing, but how do you know when your done specifying functional tests and acceptance tests. So, writing down in the Done list that testing is done isn’t enough it also should have a statement about when test writing is Done.

So, when testing is important and you don’t want to create a random amount of test cases for each PBI, should mention it in the Done List, and for sure make the validation automated with a build system.