"QA Hates You. You Suspected it. Now You Know it."
We really don’t, but we’ll get to that in a bit. As a member of Vardot’s Quality Assurance team, I find myself doing a lot of reading on technical issues online in order to save developers from extreme humiliation by catching and preventing the bug infested code they just delivered from seeing the light of day. On one of those days I stumbled on a blog titled “QA Hates You” which compelled me to write this blog post.
To be honest, we don’t really hate developers, we just hate the fact that our entire relationship with them is based on us trying to find their screw-ups, not to mention their habit of doing things like fixing bugs and not reporting back that it’s been fixed, or assuming that we’re clueless as to how different Internet browsers work. So, to help clear the air between web developers and quality assurance teams, I've decided to compile a list of things developers have told me in the past and point out why they’re so frustrating. That way, hopefully the next time you deal with your QA officer you’ll know what not to say.
"Just clear your browser cache"
Just a quick FYI, we probably already tried that before knocking on your office door, so you haven’t really given us a solution when you explain to us the miracle of cache-clearing. Also, don’t blame the browser for your bug, we realize that some of the browsers you’re testing on are outdated, but guess what, users are still using them (we’re talking to you IE).
"On my machine, everything looks fine"
It’s possible that my machine comes from a different generation than yours! But it isn’t really possible that your machine is the only one where it works, so just make sure that you’ve pushed all of your updates before assigning the task to QA.
“Do you really want me to document that?”
Let me tell you something: if it’s worth doing, it’s worth documenting. When QA goes through the code with the development team to clean up all the loose ends before launching a website, there’s nothing in the world we like more than a documented comment. Don't blame me when I reject your changes because you didn't document it. If you want your QA team to love you, all you need to do is just document your work please. That’s it. I'm begging you!
"Don't test on Internet Explorer, it has a lot of bugs and nobody is using it"
Do you really think that I don't know that IE is full of bugs? (Queue me laughing hysterically). If your code works correctly on IE with no bugs detected then you ROCK, but seriously, a QA team at any reputable web development firm is going to test your code on more than just IE. So, if we come to you reporting bugs, there’s a good chance we’ve checked your code on multiple browsers because that happens to be part of our job. Secondly, keep in mind that IE is still used by millions of users around the world.
“Aaaaand, it’s done”
Cutting corners when trying to fix a bug is never the answer. If you don't have time to do it right, then you need to have time to do it over. We will make you do it again. And again. And again until it meets the client’s requirements. Okay? Time isn’t a big issue for us; the only way you can get away with not fixing a bug is if your project manager saves you by telling us to move past the issue for the time being! Other than that, be prepared to do your work over and over again until it’s right. Oh, and don’t you give me the old “it’s a feature, not a bug” line, that’s the oldest trick in the book.
“I didn't find the bug that you reported”
“I didn't see the screenshot.” What else can I do? How much clearer can it be? When we find a bug, we write a scenario that thoroughly identifies the bug, take screenshots that identify the bug, and open and inspect the specified element that relates to the bug to ensure that, yes, it is indeed a bug. What more could you possibly need?! Just tell me, please. Tell me and I’ll make sure that I do it because I’m pretty sure I’m clinically depressed now thanks to lazy developers.
“It’s probably just a content issue”
The aim of my process is to make sure every last line of our code is clean and the final product is aligned with the client’s requests. When there’s an issue with the content that means we haven’t finished our job yet. So if it’s a content issue go fix it and then get back to me—then I will decide whether or not this is a real bug or an actual content issue. It may very well be “just a content issue” but you still have to check, and it doesn’t take much time—it’s easy things like this that solve problems!
Tips for the QA team:
But the programming team isn’t the sole instigator in this rocky relationship (just most of the time). Here’s several pieces of advice that the QA team should heed; it will make our jobs easier and help ease tensions with the developers when we’re sprinting through the final stretches of a big project.
#1. Use the inspect element...USE IT
I don’t understand why some QA testers don't use the inspect element; it’s an amazing feature that makes our job easier. It allows us to see the real work—the code. And the inspect element allows us to determine conclusively whether or not there’s a real bug and exactly where we found it. As a QA tester, you earn respect when you uncover and document bugs and other issues that prevent our development team from releasing code with fatal flaws in it to our clients. Since the QA team is one of the last formal lines of defense in the due diligence process, we need to use the best tools at our disposal to assure our product’s quality. Why would you ignore a tool like the inspect element that makes this process simpler and faster?
#2. Some bugs are worse than others
Just like in the animal kingdom, some bugs are more dangerous than others. The most obvious example is a security bug—they should always remain your top priority. The first thing we want to guarantee is that our product is safe—security is always your first order of business and all bugs that could lead to a breach should be prioritized and dealt with immediately, especially in cases when user data is involved. Releasing code with any issue is something we always want to avoid, but security bugs should always be atop our QA “most-wanted” list.
#3. Learn to say “no” to the developer
Some developers like to claim that you can modify certain issues from the back-end and try and pin the responsibility on you (some developers do this, not all. If you’re not one of them don't get mad, okay). You need to be able tell the programmer “no” that this isn’t your job, or if they try to convince you that it’s a feature, then you need to go back through the requirements and find the evidence you need to prove that yes, indeed, it is a bug. This is important because if you’ve done your job properly and identified an issue within the code, then it needs to get fixed—and by a developer with the expertise to handle that task, not a QA member. So in order to get the job done, as a QA member you need to be able to put your foot down with developers when they try and shirk responsibility.
#4. Use screenshots
Screenshots (along with the inspect element) should be a QA tester’s best friend. When a QA tester documents a bug, they need to bolster their evidence with a screenshot because the developer needs tangible evidence that the issue actually exists—that way they can’t say “this is wrong, I can’t find the bug!” Cover your bases and take the best screenshot possible to correctly prove it’s a bug—and that way if the developer claims they can’t find a bug, you don’t have to go find it all over again, because you’ve already documented the issue.
Unfortunately, this blog post probably won’t completely fix the fractured relationship between the development team and the QA team, but at least I’ve cleared the air. This way, maybe the next time one of you developers wonders why the QA tester across the break room is fixing you with a scowl, you’ll have an idea why.