The stage in the delivery lifecycle where the bugs are found can have a dramatic effect on project delivery timelines and budget. Just like NASA’s latest spending plans most of this is not rocket science but the earlier you can find bugs the cheaper they are to fix.
This post was originally posted on extended-content.com
A typical Content Management project will be structured like this:
- Requirements Gathering
- Analysis and Design
- Development
- System, UAT and Integration testing
- Training
- Deployment
Of course bugs can occur at any time during the process. But they can also be resolved at any time during the process.
During the Requirements Gathering and Analysis/Design stages bugs tend to be a misinterpretation of the customer requirements. Fixing a bug at this stage is relatively easy and often just means updating a document. However, they can be extremely hard to identify at these stages and they often only come to light at much later points in the project. The use of mock-ups, design documents and prototypes can help to reduce the impact of these bugs.
The coding stage is often the area where bugs are introduced and should be one of the easiest stages in which to fix them. The key here is thorough System Testing. One of the ways to ensure that this is completed is to share the test scripts with the developers while they’re coding. To many developers and testers this may sound counter intuitive but at the end of the day the sooner that bugs can be identified after the coding the better. When a function or piece of logic is fresh in a Developer’s mind it’s much easier for them to update and refine.
Once you’re in the testing phase the cost of fixing bugs goes up dramatically. You now not only need to consider the Developers’ time but the Test team’s as well. Identifying the bug, clarifying it, fixing, retesting and reporting all add up to making the bug fix far more expensive than doing it during development.
Hopefully by the time you’ve got to the Training stage the solution is fairly robust and ready for the users. However, even if you’ve been following an agile methodology, for many users this will be the first time they actually use the system. You should therefore expect feedback and to have some bugs or changes unearthed.
It’s no surprise that resolving a bug after the solution has gone into production is the most expensive to fix it. At this stage of the project you need to handle legacy testing, Change Approval Boards and manage release schedules.
There’s a fascinating study here where the you can see that the relative cost of resolving a bug based on 1 during the requirements phase goes up to 10 during coding and 150 once in production. There are other studies worth looking at like this one where the author has tried to quantify the cost of a bug. While the actual numbers may vary the relative values seem to be consistent with our experience.
To summarise, the earlier you can fix bugs the better and if you want achieve high quality solutions in the shortest timelines make sure you do the following:
- Clarify requirements and assumptions at every stage of the project
- Test early and often
- Never sacrifice quality