In my last post, Notes on Software Testing Habits, I ran through a few thoughts about how to look at your software testing habits. Regulated or not, there are many commonalities.
Today, I am giving you five bad software testing habits to avoid:
- Pretend there are no bugs. Your system is so perfect and you are so perfect that there cannot be any bugs. Do not plan for them in the project plan, do not train testers on how to deal with them, do not make any allowances for them. Your system is not like everyone else’s in this crazy world. As such, unlike EVERY OTHER SYSTEM, yours will be perfect.
- Blame the testers. Let’s face it, those testers must be dumb as rocks if they don’t understand that this system is perfect. They must be entirely dim-witted if they don’t understand the intention behind your test script, which is to show how awesome this system is. So, just intimidate them as much as possible every time they ask about a problem because, after all, it’s them not the system. If you keep glaring at them, they’ll probably just give up and do whatever they think you want them to do. If they can’t guess what that is, go ahead and replace them with people who have the sixth sense and can divine what that would be.
- Keep no lists. Since this system is perfect, there’s no point in keeping a list of the issues the testers run into. And, let’s be honest about it, you weren’t going to change anything, anyway, so why bother recording it? After all, let’s just let the users navigate the problems. They aren’t stressed-enough with getting a new system, all the training, their regular work – let’s just dump figuring out how to get around more problems onto their shoulders.
- Pretend the test scripts are perfect. The system is perfect and, as such, you did a bang-up job on the test scripts. There cannot possibly be any errors in them. If the users question some of the steps, be clear that they’re idiots and should figure it out because, just as the system is perfect, so are your test scripts. And, if you suddenly realize there are significant problems with a script, secretly rewrite it and find an excuse to make the testers start it from-scratch as if it never before existed.
- Refuse to learn from your mistakes. Well, of course, you didn’t make any mistakes. The system was perfect. So were the test scripts even if you had to secretly recreate some of them. So, actually, unlike most software testing situations, yours was not a learning experience. Despite the grief and unhappiness, which was caused by everyone else involved, you did your part to make the perfect and you can feel smug about it. You are perfect, too, and do not need to learn anything.
There will be many people out there who recognize some or all of this behavior. There will be others who question whether I exaggerated. First, let me say this: most software testing situations experience a least a little of some of these issues. Sometimes it’s just a matter of getting stuck in a rut rather than an ongoing issue. However, there are also projects out there where this type of behavior is endemic. Some or all of this behavior goes on on a regular basis.
As a consultant, you might think that this is where I come in – that I would provide my expertise to redirect them. However, as much as I can try to influence people, I don’t actually have the power to make anyone do anything.
Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/