*** Disclaimer: this is not about my current project. It is about all projects, everywhere. ***
If you are a developer, and you have worked much with professional software testers, you will love & hate them.
You will love them because they can do something that you struggle-with: they find the bugs that you missed. Everybody wants flawless software and as a developer, you probably have your limitations. You are good at developing, but you think like a sane, reasonable person, … and well, that is just not good-enough, when it comes to testing.
A skilled tester will have the extraordinary ability to think of whacky, cuckoo, way-out-of-the-box, “WTH” kinds of stuff. It is unnatural for a developer to think like that. Therefore, when a tester finds some nutso bug, or even something super-obvious, the developers feel grateful that it was caught before it went to production.
…unless the tester acts a jerk about it.
I guess even that is forgivable. Probably.
Unfortunately, the very nature of professional testing, is eventually going to condition testers to be jerks. That sounds a little harsh, I know. Let me explain.
So, when a tester finds a bug, he/she has done their job. “Nice one! Keep it up!”. Every now-and-then, a tester will find a “show-stopper”. This is a kind of bug which would wreak havoc on your system and/or undermine a user’s confidence in your software. Sometimes, it can be something simple, like an error message, or an awkward validation message, and sometimes it can be something subtle, like a security rule which was implemented wrong. Regardless, when a tester finds a “show-stopper”, the response is usually celebration by the test team and frustration by the dev team, and management.
As a tester, your first project will have a few of these discoveries, and they will all seem very exciting and emotional. Over time, a tester will accumulate (trophies) tales about the worst bugs ever found and just how serious they were, “That was a serious flaw! What a catch! …and it was truly a last-minute discovery. …blew our go-live date.” For a tester, these stories are big accomplishments and telling them feels great, because you saved the day.
Not every project will go that way. Developers are clever folks. They also have their own tales about solving these “last minute show-stoppers” and how stressful it was. They will learn the patterns of the bugs, and take measures to ensure that they don’t happen ever again. They will learn from their mistakes and mature in their processes. They will eventually make fewer mistakes and produce better programs. This is great for the developers, but for the testers, not so much.
If you are a tester who has found dangerous/critical/catastrophic/project-killer bugs, those shiny trophies become part of your identity. They make you feel validated. You sacked the opponent’s quarterback, or blocked the field-goal kick. You saved the big game and you feel great about it. On your next project, you expect the same, or better. You want eggs for breakfast and those developers are like chickens in a coop. Grab a basket.
Managers mean-well. It is their jobs to keep you motivated and hungry. They know that winning a trophy feels good. A word or two of encouragement can’t hurt anything. Could it? “Remember when you found that epic bug? When are you going to find another one like that? You can do it!”
Let’s face it, a tester can only find bugs which are there. If there are no serious bugs, then serious bugs won’t be found. As a tester, you understand this. So, when there are no serious bug discoveries, everyone has a reason for celebrating, except for you.
If this continues, you (and possibly your management) will start to doubt or second-guess your skills. Could there be a big bug or two in there, but you didn’t find it? You might even get superstitious and develop a feeling that there must be a show-stopper in there. Some people even resort to invalidly applying statistics. Like “for every [X] lines of code there are [Y] flaws and [Z] serious flaws. Therefore, we must have missed something.” It is totally invalid, but it is an easy mistake to fall-into.
Eventually it will occur to you: You couldn’t have missed [Y] flaws and [Z] serious flaws. So, what if you actully did find them but you just didn’t recognize the significance of them. After all, within the current context, certainly some of the bugs are relatively serious. You could be collecting some new trophies right now. Maybe if you had made an appropriate spectacle, folks would be congratulating you. So why not give it a try?
So you try it. You make a bigger deal about one of the bugs that you find.
It is just what the doctor ordered! People have been waiting for this: a bug to sink their teeth into. Everyone high-fives you and calls you a hero. Yes! And to think, you almost didn’t make a big-deal about it. Golly. What were you thinking?!
When a few weeks go-by, and the testers haven’t found a big-one, they will feel some pressure. They will feel deprived of their joy, and it might motivate them to try something to change that condition. After all, folks need their high-fives, right? You see where I’m going with this. …I’m not saying that the testers will resort to blatant hyperbole. (Not initially, at least). However, I’m thinking of a gentler term like “exaggerate”, or maybe “embellish” or “over-react”. Yes sir! All it takes is a little incentive, and the proper rewards.
Repeat this pattern a few times and guess what? It becomes a habit. In some ways it can even seem like an addiction. If a little exaggeration doesn’t satisfy, maybe try increasing the exaggeration a little.
You can see where this is going. Folks will catch-on that some of this might be a little over-inflated. You can bet that the developers are going to call foul eventually. They have their own incentives to show progress and improvement. If it seems like someone is intentionally trying to embarrass them, then things might get a little un-friendly.
Management is eventually going to recognize that something is amiss. At that point they have a few tough options: On one hand, you don’t want to demoralize the testers, because they are thinkers and they need their heads in the game, but if you allow the charade to continue, it will become unhealthy, and it will become more difficult to tell when a bug is just-another-bug or it if actually is the fourth horseman of the apocalypse.
This is when people-skills are key. Usually, this is a management task, but an experienced dev lead can help de-escalate things too.
We all want what is best for our project. Although the-end-of-the-world would be pretty interesting and exciting, I think we are better-off delivering the best product possible, and leave the TV-MA stuff for Hollywood.