Israel’s National Road Safety Authority held lately very interesting ad campaings, in print, radio and TV that are aimed to increase accident-awareness for Israeli drivers.

In this country, 95% of all accidents are due to reasons which include “human factors”. While 2005 statistics show that the “Deaths in Accident” relation to the population-total was low when compared to other European contries, the same statistics demonstrate that Israel is one of the worse countries on the “Deaths in Accident” compared to number of vehicles.
That means: Our vehicles kill more people than vehicles in other countries do. This is a very scary conclusion, and I learn from it that our drivers are careless (or could not care less!) about road-accidents.

Ad Campaigns can effectively increase consciousness when done right.
Here is how the Road Safety Authority approached the problem, and how you can adapt this in your tests.

See the picture:

[Image removed from original server]

The Caption says: “He is close to your bumper. He is fast, he is furtive… He can be unexpected… And if you don’t look for him, you’ll not see him. Slow down and look for the kid in the road!”

Another strong advert in Radio went like this: “He is approaching, and he is fast. On the road, always look for the man with the helmet!”

See the pattern? It is not “look for some kid that may be around”, or “check if there’s a motorcycle”… Stop and find that motorcyclist driving overthere!
The common to both announcements is that you are left with the impression that there are children and motorcycles everywhere.
They ARE there, somewhere where you can’t see them. You don’t want to hit them, so please be careful.

Once, when talking about SW testing with a person new on the subject, I explained the process of bug fixing, something in the lines of: The developer fixes and reports the fix in the next oficial version. You then have to look for the bug to reappear until you find it, by either changing the environment or parameters. If there is no reproduction of the original bug, you try to find a different bug related to the first or to the fix. If at last you don’t suceed, you give up, acknowledge the fix, and go find new bugs using the normal methods.
The new guy was surprized by the approach: Is this the attitude to have? Do we really want the program to have many bugs?
To anyone with a bit of experience it is clear — the bugs *are* there. All around, all the time. If we don’t find them, it is because they’re either hiding or of very little effect.

As soon as you realize that the program you are testing is bug-filled, your outlook changes. You now are a bug-hunter looking for the prey. And no one can fool you by saying there are no such things, because you know it, you can feel them breathing.

Some statistics on our side of the story.
Steve McDonnel, in his fabulous Code Complete book [Section 25.4], brings some bugs statistics (please lookup for details):

  • – Industry Average is about 15 to 50 errors per 1000 lines of code.
  • – Microsoft, in one department, at one stage, experienced from 10 to 20 defects per 1000 lines of code (I usually don’t use KLOC notation, but this statistics are different)

I’ve heard people telling that there is a potential defect for every two lines of code (!), and that for every bug fixed there is an additional one inserted in the code (which is hopefully of minor impact). As I’ve never seen this written anywhere, and they seem a bit exagerated, I’ll not count it officialy. But it is the right mind-set! 🙂

The truth is, unless you believe/know that the bugs are there, you will not be able to find them.
And, for the programmers reading this, you will not be able to prevent them. As Steve says in the same book [Section 26.1], “It’s hard enough to find an error in your code when you’re looking for it; it is even harder when you’ve assumed your code is error free”. In “The Software Development Process” presentation, Robert Brady explains that the belief in bug-free code doomed IBM to work bad, slowly and lousy at the 80’s. Be sure to read the example.

In conclusion, there is no such thing as bug-free code, but the impact of bugs can be minimized with proper testing.
Remember! He is close to your customer. He is fast, he is furtive… He can be unexpected… And if you don’t look for him, you’ll not see him. Slow down and look for the bug on that program!