I recently wrote
about testing in SCRUM, where suggested that the last day of a sprint should be left for bug-fixing. It appears to be not enough, as testers may find more bugs after bug-fix retesting. I have a new idea: testers color story cards and we aim to have all cards green by the end of the day before the last day of the sprint. Green color means that all obstacles for testing was removed, though not all the of bugs may be fixed yet. Red is a blocking bug, yellow a lot of non-blocking bugs. That’s the simplification, let me describe details below.
When do testers set and reset colors ?
The idea is quite simple. All the stories implemented by yesterday should be tested by today, but when does the bugs get fixed? When do we do follow-up testing and how does it influence the project? I suggest tester should color each story green-yellow-red by the end of today with following meaning: green: it’s ok. There may be a few bugs no matter how severe, but we don’t expect any more testing, but bug-retesting. Yellow: there are quite a lot of bugs. Although none is blocking, we are afraid that once they get fixed we may find better ways to test software and find more bugs (which are there now but we failed to find them). Red means blocking bugs. Bugs that prevented as to test story thoroughly. There is a risk that once the blocking bug is fixed the story may become yellow.
Every day tester has to test new stories and follow-up testing of yellow and red stories if obstacles were removed.
Burn-down Chart with colors
So as we add coloring to burn-down chart we could see the problem with testing. Although feature burn-down goes quite well and all stories are implemented by the end of day 9, there are 5 yellow stories by the end of day 10, which means a risk of more defects left there unnoticed yet. But the evidence of the issue is on day 8 already. A team may have decided to skip some features and focus on quality on day 9.
The only problem here is that this is not really burn-down, as you could see that down-border of green area goes up sometimes. I have reworked the charting, so that it never goes down by counting story development-complete only one day behind (when testers has tried it)
More about bug reporting
Note that even if there is a very serious (for customer) bug, such as system crush for a certain input, but we know a workaround the story may be green. It’s only red if it prevents us to do a lot of testing that we would like to.
One more note – if you have both priority and severity in your bug trucking system, then the above means that high severity bug does not mean red story. High priority bug mean it.
Searching for a support
We are using confluence (wiki) to store test documentation and JIRA to store bugs. In project were we want a high level of test execution control we use JIRA type Test Case. It is not very convenient actually, so I was happy to find confluence plugin
that could potentially solve our problem. However this plug-in has build-in red-yellow-green colors, which are defined in a different way.
Green – passed
Yellow – not yet executed
Red – failed
Well, I see certain logic about the yellow as it may become either green or red, so it’s somewhere in the middle. Right, isn’t it? No, I’m not happy with that. Yellow does not mean somewhere in the middle, it means work not finished yet. There are two separate measures – quality measure and test progress measure and we can’t put them both together into one metric!!!