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 post, 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 post 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 post 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 stuff done, and there is QA over there 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 not. 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 that you are enemies at times 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 chair at you!”
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 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 tested 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 my other post 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 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 even run 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 that 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 to 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.
This post is a chapter from my book, The Complete Software Developer's Career Guide. I'm writing the book live on this site week-by-week. If you enter your favorite email address here, I'll send you the prior chapters and get you caught up - then send every new chapter as it comes out!