Too many bugs, not enough developers

“There is nothing final about a mistake, except its being taken as final.”

More software testing words of wisdom from my fortune cookie. Like the last one I blogged about, this quote captures a fundamental truth about the testing profession: Many of the bugs you find will never be fixed.

This blog post helps explain why:

“We live in a world where there just aren’t enough software developers. No matter what stage of development you may be at, your team could always use just a few more developers to build that great feature marketing wants, fix that extra bug that’s been nagging technical support, help build some tools so that software development can work more efficiently, etc. But sadly, we live in a world of constraints and that means that the marginal cost of any investment has to be paired with the marginal benefit it will bring.

To  improve this situation (that is, getting more of your bugs fixed) it would be wise to consider this recent piece of advice from uTester Joseph Ours: Change the way you report bugs.

VN:F [1.8.1_1037]
rated 5.0 by 5 people
Too many bugs, not enough developers5.055

2 Responses to “Too many bugs, not enough developers”

  1. Jack Repenning said:

    Including the basis for your judgement that a behavior is wrong is a great idea, I agree. But it doesn’t seem likely to me to increase the number of bugs that get fixed.

    Someone’s already picking which bugs to fix (and which not), by some logic or other (probably consisting wholly or in part of “we ran out of time and resources”). At best, if the QA team actually knows more about the business than this person, this technique might ensure that the more important bugs get fixed–but it’ll be at the expense of those bugs formerly thought to be more important.

    “Fix better bugs,” maybe, but not “more.”

  2. Martijn Linssen said:

    I highly recommend Joseph’s approach, it helps a great deal in deciding which bugs to fix. As I also agree with you that there will always be more bugs than fixes
    But it would certainly give a better view on the impact and likelyhod of bugs!

    Fact of the matter is, the usual functional designs made by a.o. business analysts just describe the desirded situation, hardly ever the, and never all, undesired ones

    This leaves developers fairly free in deciding which situations to regard as error, and which to handle as exception. And that’s why we are so used to get illegible messages (exceptions) when we make a silly mistake

    At the end, there’s the testers. They basically can’t possibly have a clue about all unwanted situations as those just aren’t (all) described. So they do their best. And sometimes, their best is not “the” best when they go at length to find bugs with hardly any impact that will only occur if you fall asleep on your keyboard while hitting those few keys in exactly the right order <– stretching it to the max here but trying to make a point ;-)

    I thought and hoped offshoring would make a difference, forcing designs to cover all wanted and unwanted situations. Then again, that would take the creativity out of developing and testing, wouldn't it? Nonetheless, it hasn't happened. All kewl stuff developed over the last decade was just aimed at faster development, doing more projects in less time

    Will the perfect application ever exist? It probably will, with a lifespan that lasts until the next release ;-)

Leave a Reply