How Software Developers Can Get Along With Testers
It’s a bit humorous and somewhat unexpected, but for many software developers, one of the most difficult parts of their jobs is dealing with QA, quality assurance… yes, those dreaded… testers.
In a previous chapter, we talked about testing and laid out the basics of what it is and how it’s done.
But just because you understand testing doesn’t mean you understand testers.
So, that is what this short chapter is about.
It’s about you, as a developer and how you can deal with testers and QA in general.
QA Is Not The Enemy
It’s important to start out this chapter by letting you in on a little secret… QA is not the enemy.
I know it may seem that way.
I know things are set up that way.
I mean, here you are making stuff, building features, kicking ass, getting shit done, and there is QA over there picking their noses, making sneering comments, reading the latest post on sticky minds, and—oh yeah—breaking your code.
But, are they really breaking your code?
Is it really QA’s fault that the code you wrote has bugs in it and they are trying to find those bugs?
It’s your fault, or it’s no one’s fault, if you like to be one of those “let’s not blame anyone” type of people. (But it is really your fault.)
Anyway, the point is you are actually on the same team.
You actually have the same end goal: to produce high quality working software.
Yes, it can seem at times that you are enemies, because it seems that your goals conflict.
And I’m not going to say that there aren’t testers who aren’t hell bent on breaking your code and making sure it doesn’t ship.
There are plenty of QA people who forget that the goal is to actually create working software, not to prevent any software from ever being released. We’ll get to them a little later.
But, in general, you have to recognize that it is not you versus them.
Because if you start that battle and you make it you versus them, you are going to have a really difficult time trying to do your job.
Whatever notions you have of QA being the enemy, get rid of them now.
It’s not going to help you, it’s only going to hurt you in your software development career.
Oh, and I’m talking from personal experience on this one.
Trust me, I’ve had many epic battles with testers over the years.
I’ve even being accused of throwing a chair—utter nonsense.
Know What You Are Being Tested On
Here is where most QA/developer conflicts start:
“Hey, what the heck, this isn’t a bug.”
“Yes it is, your code doesn’t sort non-alpha characters correctly.”
“It’s not supposed to. That’s not a valid test. The feature works.”
“Well, it should. It’s a bug.”
“No, it’s not a bug. I’m going to throw this f—- chair at you mother f—-!”
What we have here is a failure to communicate.
No, really. That’s all it is.
Problems like this one can be resolved extremely easily, simply by talking to QA before you write any code and agreeing, together, on what is going to be tested.
In that situation, a five-minute conversation could have prevented a perfectly good chair from being destroyed.
If I—ahem, I mean the software developer involved in this “incident”—had talked with this ass—I mean tester—ahead of time, and simply discussed what was going to be tested, then this software developer would know that they should make their code handle sorting non-alpha characters.
Or they could have disputed it before writing the code, before any ego was invested, and the conversation could have been much more civil.
You wouldn’t take a test in school without knowing what you are going to be tested on first, right?
I mean, I don’t think very many lawyers walk into the bar exam without knowing exactly what is going to be on the test.
It’s not like they sit down to take the exam and say, “I have no idea what is going to be on this test, but let’s just hope it’s what I studied.”
So, don’t write code that is going to be tested without knowing in which way and on what it is going to be tested. Duh.
Test Your Own Stuff First
I briefly covered this in the other chapter on testing, but I’m going to mention this again since it’s so important.
Test your own stuff first.
QA is not a babysitter who tests your code for you so that you don’t have to.
QA is a last defense before your code goes out and wreaks havoc on your customers.
Don’t expect testers to find your bugs, expect them to validate that your code works.
In fact, good testers often call what they do verification, not testing.
(Oh, don’t get me started on this. I went to a QA conference one time and I was lectured for hours on the difference between verification and manual testing.)
Anyway, it’s your responsibility to test your code before you hand it over to QA.
When I say this, some software developers get annoyed and ask me, “What is a tester’s job if I have to test my own code anyway? What good are they?”
It’s a fair question, and in some organizations testers exist solely to manually run tests, but in general, a tester’s main value is coming up with what should be tested and thinking about all the ways things could break or use cases which haven’t been thought of.
Think of it this way.
Anyone can come up with the basic scenarios of how an obvious feature should work.
You should be testing all of those basic, obvious scenarios before you hand your code over to QA.
But a good tester might try running some of the not-so-obvious scenarios and corner cases which you might not have thought of.
(Of course, I still recommend that you run even those tests if you’ve talked to QA before you actually write your code and decided on what should be tested.)
The point is that the basic use cases, and anything you know is going to be tested, should work.
Which brings us to the next point.
Avoid The Bug/Fix Cycle
The big reason for working with QA in this way has less to do with whose job something is and more to do with increasing the overall efficiency of the team.
As much as possible, we want to avoid the cycle of finding bugs, fixing bugs, verifying the bugs are fixed.
It takes a large amount of time and resources for a bug report to get filed, get assigned to a developer, be reproduced, fixed, sent back to QA, verified to be fixed, and then logged as fixed.
We want to avoid going through all that time and overhead as much as possible.
That is one of them main reasons you should test your own stuff.
If you find the bug before you even send the code to QA to be tested, you cut most of the steps out of that loop.
But… there is another way to shorten this loop.
Try to work directly with QA to fix any bugs as they find them rather than them filing a bug report and going through that whole formal process.
One simple way to do this is ask the tester who is going to test your code to come over to your desk, run through a few scenarios, and look at what you built before you even check it in.
You could also put the code on a development server or give them some other way to access it.
Or, if it has already reached QA officially, you can go over to their desk and watch them executing some of the tests. or ask them to let you know if they find anything, so you can figure out if you can do a quick fix for it instead of filing a bug.
Sometimes, an official bug report needs to be logged, and then it makes sense to track the bugs, prioritize them, and go through that whole process.
But, in general, if you can avoid that bug/fix cycle as much as possible, you are going to save the development project quite a bit of time.
Help With Automation
Most testers are not software developers.
Even the ones who know how to write some code probably aren’t as good at writing code and architecting a system as you are.
Yet, many software development organizations want to have their testers automate their testing efforts.
As a software developer, this can be extremely frustrating when you get bug reports on your code that you know works, but some automated test failed because it wasn’t properly written or designed.
You should step in before this happens and help with creating automated tests, and especially with creating a test automation framework.
This is one area where you can be a huge benefit to QA. It is a great opportunity to bring the testers and developers closer, which can greatly reduce conflict and the me versus them attitude.
What About That One Asshat?
Ok, so you are trying to get along with QA.
You are testing your own stuff first, you are making sure you know what is going to be tested before you even write your code, you even took the entire QA team out to lunch to show them how you aren’t such a bad guy.
But there’s this one QA dude—this asshat—who just seems to be gunning for you.
No matter what you do or how friendly you are, he just seems to be hell bent on proving that your code sucks, derailing the project, and finding as many bugs as possible, whether they are relevant or not.
What do you do?
Warning: what I am about to say is not politically correct and it’s going to piss some people off, but it’s the truth.
Look, here’s the deal.
Let’s be honest.
Sometimes—not all the time—people who are in QA feel inferior to developers.
In the back of their head, they feel like they just couldn’t hack it as a developer, and they settled for a job as a tester.
Now, don’t get me wrong, this doesn’t describe every person in QA, but it does describe some people in QA and, most likely, that asshat you are struggling with.
One way of dealing with this feeling of inadequacy is to try and bring down other people, especially developers who you are envious of, in order to make yourself feel smarter and better.
I’ve seen this pattern enough times to know that it is fairly common.
And, in my experience, I’ve found that one of the best ways to deal with this kind of problem is to swallow a little of your pride and frustration and acknowledge the intelligence of your colleague.
It’s not easy to compliment someone who is purposely dishing out abuse at you, but it is the higher road.
I’ve found that in many cases, this person is just looking for some validation and acknowledgement, and once you give it to them, they are like a puppy following you around and wagging their tail.
A little genuine and sincere praise can go a very long way—remember that.
And if your efforts still fail, at least you’ll know you’ve done what you can.