Inside the Mind of a QA Tester
Testers have an analytical and technical way of viewing things, we discuss how this affects us in our day to day lives. Are we negative by nature? or by perception?
Note: This is a new idea I had for writing a special kind of editorial, where I take a trait of being a software tester and explore where it goes philosophically, including the bad places of taking a concept to an extreme. It is me analyzing myself, QA-ing myself, and if you can relate to the thoughts, that’s great, viewed in a hardware/software kind of way. Perhaps it is best to think of this as exploratory testing of my thoughts about QA. Hopefully this will be received as being transparent and honest, instead of as weird and dangerous in my candor. This is a thought piece, not to be confused with technical information or fluff. Maybe it is partly a sermon. Maybe it is self-psychoanalysis. I’m not sure yet. But here I go …
Am I too critical of things? In a sense, as a QA professional, I have dedicated my life to fault-finding, then highlighting those faults. Is this a good thing, or does all of this negativity damage me as a person? Has anyone ever built a monument to a critic? To be a judge is to wield power, and I’ve heard that absolute power corrupts absolutely. For QA, the power is ultimately the ability to stop a release, to say, “STOP — THIS CANNOT SHIP THIS WAY!” The power to write something up just because you don’t like it, and justifying it as a user experience complaint, even if the reqs make no mention of what you reported. Have we become the peanut gallery, ready to take pot shots wherever we see fit? And as people, what does this make us? Are we too focused on the ugliness to miss out on seeing and appreciating beauty? The word PASS on a test result list just means you keep looking until you see a FAIL, where you now have more work ahead of you.
Well, it is our job. Without QA inspection in the world, there would dangerous food, medicine, vehicles and computers (you probably already know about the computers …). While your efforts might not mean the difference between life and death (although they might), they at least impact accuracy, vulnerability and user experience. There is no need to be snarky or mean in the bug reporting; in fact you can easily state the bug’s limitations and note, even compliment, the behavior outside of the bug’s scope (“The textbox works fine if you do not use Unicode”, “All other combinations were tested, and this is the only one that fails”, “Of the required devices/OS’s, this is the only one that had display concerns”, etc.). The goal is to get the bug reported through proper focus, not to antagonize or bully the developer, so our details should help streamline the debugging. We want to let the developers know that we’ve done our homework so as to help them do their job better! Also the developer realizes that you did not invent the bug, you merely discovered an existing problem and are bringing it to their attention because that’s your job, to help make a better product.
In a janitorial sense, the mess must be removed for the sake of cleanliness. By hiding the ugliness from the end users, they can better appreciate the beauty which is a better functioning, better performing app. When things work properly, it is a beautiful thing. After all, you can’t spell “happy” without “app” (although the same could be said about “crappy”). So back to my original question: Are we too critical? No, we’re just trying to make the world a better place through exposing problems, not to be mean and cause undue problems. Our comments are directed at having a positive impact of improvement, which are backed up with facts and will likely be realized for the purpose of betterment. Outside the domain of finding bugs, there is no pressure to voice observations with a critical eye.
Note: The views in this editorial are not necessarily the views of QualiTest. It is just stuff that I wanted to say when I think about life in QA. Feel free to comment with stuff that you want to say in response, including ideas for future topics.
P.S. One time when I raised the alarm to stop a release was on an expensive piece of hardware I had configured and was unit testing. On a whim, I decided to add a step not on the test plan: shutting down then booting up the box several times. Sometimes it did not boot up. The problem was tracked to a chip that needed better quality control in its settings. I think about how the customer would have felt when they tried to use their new pricey box and it did not boot up. Raising the alarm was the right decision, not being alarmist. Finding faults is a power for good.