Home » Scrum » How to Establish Peace to the QA vs Dev Battle

How to Establish Peace to the QA vs Dev Battle

Have you ever noticed how, when QA reports a “defect” developers tend to bristle?  I first noticed this in myself a few years ago.  Now that I’m functioning as a Scrum coach, I’m noticing it in others. Is there a way to have some kind of quality checking in our code that doesn’t make the whole process feel so adversarial?  I think so.

I believe there are some adjustments that need to be made organizationally and personally that will bring these two groups together.

But first, why does this problem exist in the first place?

How to Establish Peace to the QA vs Dev Battle
Photo credit: m01229 via Visual hunt / CC BY

How The Battle Started

How to Insult a Programmer

When I was growing up, my sister was very direct.  If she thought you were ugly, she’d tell you so.  OK.  Maybe it wasn’t quite that bad.  But one day, I remember she said something to the effect of, “I didn’t say anything that wasn’t true.”  And both my mom and I said, “Yes, but it isn’t what you said so much as how you said it.”  In fact, you can say the same words in two entirely different ways.  Two sets of inflections.  And what they mean can change drastically.  Sometimes just changing the words you use can change the meaning.

But, to a programmer, no matter how you say, “Your code has a bug,” they will probably end up hearing. “Your code sucks!”

You see.  Programmers really do care about their code.  At least the really good ones do.  And while it may seem very silly, most programmers get offended when you suggest they’ve written buggy code.

This, you see, is the core of the problem.  Once you understand this, the fix becomes rather obvious.

Don’t Call It a Bug

I think nothing has done more damage in the field of programming that the fact that we call software problems “Bugs.”  It is such an ugly word.  When is the last time, other than a Pixar movie, when we’ve thought of bugs as something we would want to welcome?  We might as well say, “Hey, I found some shit in this program!”

When I got my Scrum certification, our instructor asked a simple revealing question.  “How many of you think people are doing their best to do the right thing?”  That’s not exactly what he asked, but that’s what he meant.  If you believe that all evil in the world is intentional, you’ll come away believing that all programmer intentionally put bugs in their code.  And while I do know of a few cases where this has happened.  Most of us try our best to write perfect code.  When we don’t it is because we didn’t think of the situation and code for it.

If on the other hand, you think everyone is trying to do their best, why treat defects in software as something evil?

To paraphrase Scott Hanselman, “Most people are not nearly smart enough to be as evil as you act like they are.”

Most Bugs are a Specification Problem

Weather you have a formal specification or an informal specification, my observation is that most “Bugs” that show up in code are a result of either 1) the specification being misunderstood or 2) the specification being incomplete.

Yes, there are a few places where neither of those are true and the programmer clearly missed the mark.  But, even then, assuming they missed the mark rather than assuming the specification was unclear will go a long way in making the programmer more receptive to the fact that the code needs to be changed.  Just the fact that we call a defect in our programs a “Bug” reveals and colors what we think about who’s fault

What Programmers Can Do

It’s Not Personal

Listen gang.  Bugs are not a reflection of your personal character.  And even if someone thought it was, that doesn’t make it true.  At worse, it means you might have some stuff you still need to learn about how to program well.  OK.  We’ll never be perfect.  Think about this, while you are writing the code, your compiler, or runtime, tells you you’ve done something wrong quite frequently.  But as soon as a human tells you something similar, you take it personally?  That’s pretty wacked.

Here are a few tips I’ve learned.

  • Emotions are learned responses.  This means your negative response to bugs can be retrained.
  • Just because someone says something about you, or disapproves of you personally, doesn’t mean they are right.
  • Most criticism is only an opinion based on an expectation.

If you can internalize these, you will be much more receptive to hearing that your code has a flaw.

Break the Spec into Tasks

One thing I’ve started doing recently that I’ve found to be a great help is that I’ve started breaking the specification I’ve been given down into the composite task that I’ll need to implement the specification.  How granular.  I aim for task that should take less than four hours.  By getting this granular, I’m able to accurately estimate how long it should take me to complete the specification, and I’m sure I’ve caught all of the tasks involved in completing the specification.

You should track your time against your estimates so you can get a sense of how far off your gut is relative to reality.  This will improve your ability to estimate projects.

By breaking down the project like this, you are more likely to see holes in the requirements before you even start coding.

Create a Test Plan

The other thing I’ve started doing is that I’ve started writing out how I plan to test the specification once I’ve completed it.  I just write this out.  Once again, this helps me find holes in the requirement.  But this also forces me to start thinking of ways someone might use the code that would break it.  And that simple act of trying to break it in my mind prior to coding it, refines the spec, and makes my code more reliable.

Ask for a Review

Once you have your tasks and your test plan, ask the person who gave you the spec to review it.  “Does this look like it reflects what you’ve asked me to do?”  This does two things.  First, and most importantly, it ensures you understand what it is you are building.  But, it also enlists someone else in the responsibility of ensuring what you finally build is what should have been built.

What QA Can Do

Don’t Call Them Bugs

I remember reading a Louis L’amour book one where the basic plot was this wagon train going out west.  At the beginning of the trip they had all agreed that no “bad language” was allowed.  And then one day, someone used the word, “shit” to describe cow poop that was on the ground.  The group was in shock and he was reprimanded.  At that point I remember the line, “If a word makes it any different, why don’t we just call it pudding?”

But you see, as I’ve already explained, a word DOES make a difference.

The word I would prefer to use is “Specification Refinement” because, in the end, that is what they are.

Don’t Write Requirements

One thing I’ve noticed happens quite frequently is that once QA has verified all of the items in the requirement, they start doing exploratory testing, as they should.  But, when they find something, they inadvertently start writing requirements.  It looks like this.

“I did X, Y and Z.  I expected to get result 1 but instead got result 2.”

Some of you are probably thinking, “What’s wrong with this?!”

Well, why did you EXPECT to get result 1?  If the expectation was not listed in the requirement, you have no valid reason to expect anything.  Your expectation is just your opinion about what should happen based on previous experience.

So, how to write up this problem instead?

“I did X, Y and Z and 2 happened.  This doesn’t look right but I don’t see anything in the spec that says what should happen.”

Don’t Assign Bugs

This one is going to fly in the face of QA teams everywhere.  But remember, we are trying to find peace in what has become an antagonistic relationship.

Remember how I said that programmers react emotionally to the fact that you found a bug?  Well, if you assign a bug to them and they get a notification about that bug in the middle of writing code for the current sprint, here is what is going to happen.  First, the email is going to interrupt them.  Second, they will have an emotional response to the bug report that could continue to derail them for the rest of the day.

Instead, you should be assigning the bug to the project.  Assuming you are using Scrum and have a backlog, the issue should be put on the backlog for grooming.  Grooming would include figuring out who is responsible for the bug or who is responsible for finding out what the core issue is so we can assign the bug appropriately.

One of the problems I’ve seen with assigning bugs to specific developers is that the bug is often assigned incorrectly.

By assigning the bugs to the back log as specification refinements, they just become additional features and the sting associated with “Bugs” goes away.

If you are using software that requires you to assign bugs to an individual, make that individual the Scrum Master, Product Owner, or Project Manager (if you aren’t doing Scrum).

Organizational Changes

Finally, I want to address organizational changes that you may need to make.  Hopefully, you are already doing this.  But my experience tells me otherwise.

Silos Kill

Everywhere I go, QA is a separate department.  Why can’t QA be co-located with the developers?  Wouldn’t it make a lot more sense to have QA working with the developers to figure out a test plan so we can code for the plan rather than having the plan developed in isolation?  I get that exploratory testing might reveal additional issues, but certainly some of those issues can be revealed early by defining how the code is going to be explored.  Plus, making everyone part of the same team means they are all working toward the same goal.  No one gets offended that way.

When one QA person found out I was writing unit tests, she asked, “What will be left for me to tests?”  Which I found to be an incredibly naïve way of thinking.  Wouldn’t you hope that you don’t find any problems with the code I am working on?  How is the fact that I’m testing a problem for QA?  Aren’t we all working on the same goal?

Central Source of Truth

Another place that needs to be addressed related to silos – Another area that re-enforces and is a result of silos – is this habit of each group using their own project management software.

In one organization I’ve worked at we used four different systems.  One system for version control (GitHub) another system for QA (HP Quality Center) a third system to manage requirements (which we only used minimally and instead had documents on a shared drive) and a forth system for managing our Kanban board (Jira).

The frustrating thing is that 80% of what everyone needed to do could have been achieved by using GitHub.  But even if we needed to use separate systems for the actual artifacts, it seems to me that we could use one system for tracking the project instead of having it tracked three or four different ways.  That’s just craziness.


Other post in Scrum
Article Name
How to Establish Peace to the QA vs Dev Battle
Have you ever noticed how, when QA reports a “defect” developers tend to bristle? I first noticed this in myself a few years ago. Now that I’m functioning as a Scrum coach, I’m noticing it in others. Is there a way to have some kind of quality checking in our code that doesn’t make the whole process feel so adversarial? I think so.
DMB Consulting, LLC

Related Post

  • Agile/Scrum Task Board for “Real Life”Agile/Scrum Task Board for “Real Life” The agile “Task Board,” also known as a “Scrum Board” has become a staple of the agile programming world. “Getting Things Done” (GTD) is a process for managing task in the business […]
  • How to Estimate Software Projects Like a ProHow to Estimate Software Projects Like a Pro We’ve all been there.  Either at the micro level or at the macro level.  Business wants to know, “How much is this going to cost me?”  And as software developers, we all know the answer […]
  • The Proper Function of QAThe Proper Function of QA With all this talk of test driven development, one has to naturally ask, “Where does the QA department fit in?  Do they even have a role in the organization any more?” Well, the […]
  • 10 Reasons Projects Succeed10 Reasons Projects Succeed We’ll get to Reasons Projects Succeed soon, but I need to do some setup work first. I’ve been thinking about starting an Open Source project for a while.  The only issue was; I didn’t […]
  • Are You Average or Awesome? 9 Ways to Improve.Are You Average or Awesome? 9 Ways to Improve. The story goes that there were two men, Joe and Frank, who were camping out in the woods when a bear showed up in the camp.  Terrified, they decided the best they could do would be to stay […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS. Does your team need additional help in any of the above? Contact Dave today.

One Pingback/Trackback

  • Interesting. My experience of programming over the last 38 years or so suggests that the entire discipline is based on violence (either rmental or in some cases physical): put three programmers and an idea into a room, and there’ll be blood (either metaphorical or in some cases real) on the floor in ten minutes. Why? It’s caveman shit: we’re predators, and the successful completion of a program is our prey.

    QA is a necessity: every programmer knows deep down that the last person to test his code should be him; that bristling, I think, is at least as much a function of the predatory mindset of programmers as anything else; get past that and the programmer knows that QA is correct about the bug: that is, after all, QA’s job… well… unless you find yourself in a situation I once had, in which the QA person failed to test anything properly and revealed later that he thought “QA” meant “Question and Answer”).

    But QA needs to understand that the programmer is (at least in his own mind) a dangerous predatory animal which expects a good fight at a moment’s notice.

    There was an old psych test which involved thinking of three animals: favourite first; then second favourite, then third favourite. I selected a tiger as my favourite because it’s rare, dangerous and magnificent; second was a shark because it’s sleek, efficient and a perfect killer; third was a housecat because it’s cuddly, cute and underneath the surface just as much a vicious predator as the other two. Turns out that the test says that my favourite animal (the tiger) is what I think I am; the second-favourite (shark) is what others think I am (because any self-aware individual is aware of that perception on some level), but the third-favourite (housecat) is what I really am.
    And programmers, I think, are that: an often-introverted (I’m not, but a lot are), academic-seeming, quiet type which is, under the surface, quite capable of disassociating morality from the task in hand (one needs to be able to switch that off to debug properly: value judgments are a killer) and entirely predatory.

  • Pingback: Dew Drop - September 14, 2016 (#2328) - Morning Dew()