In this article, we’ll discuss some sources of conflicts between developers and quality assurance and the advantages of a true partnership between the two — as well as some ideas on how to get there.

QA: “I was testing your change and the app suddenly closes when I press these keystrokes! We can’t ship this!”

DEV: “Wait why are you pressing those keys? Can you replicate this? Do you have any errors logged?”

QA: “Does it matter why? It shouldn’t crash the application! I’ll try to find some steps so you can fix your problem”

DEV: “That’d be good. I’m kind of busy. I have 5 features to implement before I go home tonight…”

Sound familiar? Maybe not the specifics, but the dynamics of this relationship are certainly familiar.

I’ve worked with some very devoted quality assurance (QA) professionals. I’ve also worked with some extremely talented developers. But when you put the two of them together — look out! When QA and development interact, sparks tend to fly, arguments start suddenly and swiftly, and things devolve into chaos.

While I can’t say I’ve never gotten into conflict with QA (I was the developer in the paraphrased scenario above, many years ago), I’ve found some ways to build healthy relationships between QA and development.

Beyond just a better relationship, I’ve found a few key things that improve QA’s ability to understand changes and development’s ability to detect bugs before handing changes off to QA. All of this together improves application quality and team velocity.

Let’s talk about the problem, the ideal relationship, and how we can get to a better place.

Why we Clash

So why do developers and QA professionals clash so frequently? After all, QA wouldn’t exist if developers weren’t blinded by confirmation bias. On the other hand, developers can look at QA as the last line of defense between them and late nights resolving production outages.

I think, in short, that the answer is that we all care.

QA cares about making sure as few bugs as possible get through.

Developers, in turn, care about getting work done, finding intelligent solutions, solving the right problems, and meeting business needs. With most good developers, there’s also a decent amount of pride in their work. Additionally, once developers hand off work to QA, they move on to other work items, and any disruption is going to be bad news of some form or another.

So you have the pride of developers swearing that their testing worked flawlessly mixed with QA’s pride in finding potential issues and protecting users. Then comes accusations that QA is making incorrect assumptions, rebutted b QA stating they’re just reading the information available to them.

These conflicts are ultimately good — you want your developers to take pride in their work and you want your testers to be motivated to find issues. The question is — how do you reduce the misunderstandings that lead to clashes from QA making incorrect assumptions or developers not testing the right thing?

As it turns out, I have some ideas.

What Partnering with QA Looks Like

Let me break down what my ideal version of a developer / quality assurance looks like over the course of a feature.

During ticket grooming, developers and testers are both present and involved and discuss the details of the change, any risks involved in development, and how the item will be tested at a high level.

At the beginning of development, the developer writes a draft of a test plan. This is a simple and non-formal document outlining how the developer intends to test a change before handing it over and how they recommend QA test it, if that’s different than how they’ll test it.

The point above is likely the most controversial point I’ll make in this article so I should expand on it a bit.

What I’m saying is that the developer should be forced to put together a low effort set of sentences describing how they’re going to make sure they’re not breaking anything before they work on the feature. This has the following benefits:

• Developers start thinking about testing early on
• Developers are more likely to unit test code as they go and follow test driven development.
• Quality assurance is less likely to need additional information from development before starting testing
• Quality assurance is less likely to make incorrect assumptions about a work item
• Quality assurance has a starting point for a formal test plan
• Quality assurance has an opportunity to gently and politely point out important test cases the developers missed.

Ultimately, I feel that this change of having developers draft informal test plans and hand them off to QA as the basis of the real test plans helps everyone — including the business and its customers.

Once development is complete, the developer hands off the feature as normal to QA, along with the draft of the test plan.

If organizational policy and source control or build systems allow, development can share a link to the feature branch that was merged in so that QA can look at the scope of the code that was changed.

This one is also somewhat controversial as most QA professionals won’t be able to fluently read source code, but I believe that even the count of files or lines modified is important information for QA to understand. After all, you test a multi-file change a lot differently than you test an additional check for a null value or a fixed typo.

You may also want to expose unit test information including code coverage statistics to highlight which files have adequate unit test coverage. Bear in mind, however that code coverage can be a misleading statistic. Source code analysis tools like NDepend for .NET that expose information on cyclomatic complexity are more likely to be useful to QA.

If QA tests and item and finds a defect, they should provide as much information as possible — recording a Gif if necessary for user interface bugs or sample HTTP requests for API results, for example.

The tester should walk through the issue with development and, once a fix is identified and provided, look for how the test plan could have helped the developer find the issue before handing it off. Bear in mind that some bugs only occur in certain environments or with interaction between different data sources or external systems.

The key point is that you’re looking to continuously improve and that QA and development both look at defect prevention as a layered approach where different checks in the process are not guaranteed to detect an issue, but create a system likely to catch defects before they reach end users and minimize their impact if they do.

From Conflict to Cooperation

So, how do we get there? How do we get developers to want to talk with quality assurance — let alone taking additional work in drafting test plans?

I think you do this in baby steps.

If you’re a developer, start by working on establishing friendships with people in quality assurance. You need a relationship of mutual respect and trust to have healthy communication, so start with the people involved.

Next, broach the idea of QA being more involved earlier in the process. You could invite them to a code review potentially (though this is going to be boring for many testers), or you could just jump in and say something like “Hey, I’m starting development on this and I’m thinking about how I’m going to test it. Do you mind looking over this plan for how I plan on testing it and let me know if you have any ideas?”.

Hopefully, if you start like this, QA will see that you care, see the value in what you’re trying to do, and see an opportunity to use their expertise to contribute to the success of the organization.

What you don’t want to do is say “Hey, I wrote a test plan for this feature. Use this as a starting point on your end”. That’s essentially telling QA that you can do their job better than them. You wouldn’t want a tester to send you a drafted technical design document, right?

You’re much more likely to achieve success if you stay humble and say “Here’s how I’m testing what this is. You can use this as a starting point on your end if you want. What I’m really hoping is that you can point out major cases I’m missing”.

If you’re in quality assurance, it’s a bit harder to be proactive. After all, going up to a busy developer and saying “I think you should draft test plans” sounds like “I don’t want to do my job. Do my job as well as yours” which is somewhat unlikely to go over well.

What you’ll more likely have better success with is if you wait for a significant test case to be missed by a developer or miscommunication or bad assumption. After the issue is resolved and any stress from it cools off, you could offer to be involved earlier in the process.

Something like “I feel like I’m not always understanding the true nature of the changes you send my way, and sometimes I feel like you’re not testing things that are obvious to me. Would you be open to talking about test plans with me when starting with development? I think it’ll lead to less tension and better speed and quality over time”.

Admittedly, this is a harder sell coming from QA to development than the other way around, but if you focus on the value you can personally offer the developer by sparing them the stress and aggravation of mistaken assumptions or bounced defects, a reasonable developer should at least consider your idea.

And, like I stressed for developers, establishing a healthy and respect-based personal relationship with developers is going to help them not to jump to any assumptions about your intent.

What about that bug?

As a thank you for reading this far, and to tie up loose ends, let me share with you what happened with that crash I described at the beginning of this article.

QA was eventually able to provide a set of keystrokes from a specific page that would cause the application to terminate.

It wound up that QA’s keystrokes moved the keyboard focus onto the exit button and clicked it. The application handled this by closing. In this case it actually did wind up being a feature and not a bug, but I made a code change to prevent future confusion: The application now logged whenever the exit button was clicked.

While this story is maybe a little unflattering on the QA side of the fence, the tester in question was acting on what she thought was a rare crash from a sequence of key presses during a page transition. It wasn’t until she gave me the details that we knew exactly what we were looking at.

Some things you just can’t make up.

Conclusion

So, I’ve thrown some fairly controversial ideas out there. These may or may not work with your teams, organization, processes, and culture.

My central point here is that we can do better than sliding changes under a door with a note on it reading “please test”. Testers and developers all care about the same thing: shipping quality software on time that meets the needs of the organization.

Development and QA have a lot to offer each other. We may not always agree, but we’re better together than we are separate, so let’s look at our processes and break down walls to improve our quality and velocity.

Originally published at https://killalldefects.com on November 30, 2019.