Programmers can be inclined to complete functionality and then let Testers review their work for bugs - particularly when under pressure from Project and Product Managers! This is time consuming for everybody and can have a negative impact on productivity.

To explain…. When a bug is found by a Tester:

1. The Programmers complete the code, submit it and update the work ticket
2. The code is reviewed by peers (code review), who commit it and update the work ticket
3. The Testers test the new functionality
4. The Testers find an issue
5. The Testers record the issue (how to reproduce it) as a bug ticket and assign it to the Programmers
6. The Programmers read the ticket and try to reproduce it
7. If the Programmers can reproduce the issue, they open the code and look for the issue
8. The Programmers fix the code, test the functionality and resubmit it
9. The Programmers update the ticket
10. The new code is reviewed by peers (peer review), who commit it and update the ticket
11. The Testers open the ticket again
12. The Testers try to reproduce the issue and if fixed, close the ticket

Italicized = work saved when bugs caught by the developer.

If the Programmers tested the new functionality in the first place and eliminated the bug, everything after point 3 is skipped! It, of course, takes the Programmers longer to test the new functionality themselves, but it is still more efficient than engaging the process above.

Thus, if you reduce the bug count, you increase productivity! How do you reduce bug count? Easy! You measure it.

In Jira (and other bug tracking tools), you can create reporting "dashboards" that will let you report bugs by time, severity, platform, and any other number of attributes.

Personnaly, I set up dashboards that report each of the following, for each project and also across projects:

• Bug tickets opened : bar chart (by month)
• Root cause : pie chart (last 30 days)
• Bug tickets re-opened (by month): bar chart (by month)
• Bug leakage (bugs opened by the Product Manager) : bar chart (by month)

It's strange, I have found that as soon as I start measuring things, the numbers invariably improve (up or down - whichever is the improvement). And then, if things aren't as you expect them, you can have meaningful discussions as to why they are so.

Acceptable bug levels

What is acceptable from your Programmers and Testers is really a judgement call and a bit hard to quantify.

Consider your appetite for bugs. As my blog on this topic explores, it can be non-productive to try to get software bug free before releasing to production.

You must recognise that quality costs time and money. If you have a low tolerance for defects, you will need to spend more time and/or more resources to ensure a higher level of quality.

Consider carefully the impact of defects vs. time/cost on the business value you are delivering.

Are bugs in production really more expensive?

There are many articles describing the incremental cost of bugs based on where in the development cycle they are found. It is common to hear suggestions that a bug found in Production will cost 100 times what it would have cost if found in the early development phases.

Given the increasingly prevalent use of Agile and Continuous Delivery methodologies, I suggest that this is increasingly less true.

With teams being retained and remaining active on specific product developments, and with more frequent delivery cycles, there is less incremental cost associated with finding the right resources, upskilling and scheduling of a special release to deal with bugs found in Production.

Where additional cost will still be incurred is when the bug has an impact on Production Data - which may need rectifying. And of course there is always the concern of frustrating and/or losing users.