The Software Quality Chain
July 30, 2013
Posted by on
In any project there are three places software quality issues can be identified.
- at development
- formalised testing
- with the end-users
Ultimately you hope your end-users never encounter bugs – and if they do encounter bugs you hope they are minor and that you can do something about it.
Every stage of the process reduces risk of release of software bugs (if done well); however risk is never eliminated.
Developers have the opportunity to protect against a wide range of software bugs by coding defensively.
More importantly developers have the choice of whether to get to the bottom of problems reported further down the chain (by formalised testers or end-users) and making lasting changes to prevent re-occurrences.
Creating a basic set of automated unit tests allow developers a degree of confidence that any problems encountered in the past will be likely flushed out before being passed on to formalised testing.
Formalised testing has one and only one task: find bugs before the end-users do.
If testers are having to work with poorly disciplined developers then their tasks suddenly becomes exponentially more difficult – because they are not only going to be searching for small defects, but they are likely going to be inundated with large and mundane defects as well.
Worse, those testers may end up shell-shocked as the same bugs are re-introduced over and over again by a lazy development team uninterested in properly solving problems once and for all.
End users, when encountering bugs, can be offered the opportunity to report them before other end-users encounter those bugs – giving a project the opportunity to fix them and keep the majority of the customer base happy.