How to Empower Quality Assurance and Developers to Work Together

The rise of new software engineering trends such as DevOps and continuous integration means that Quality Assurance (QA) and development are more closely linked than ever — or, at least, they should be. Unfortunately, it isn’t uncommon for testers and developers within an organization to be at odds.

If you’re practicing agile software development, or thinking about doing so, it’s absolutely critical for QA and developers to interact and work together as often as possible. Here are a few of the most common causes of friction between QA and development — and a list of ways you can work through them.

Common QA Complaints

Although they’re crucial for the successful release of any software product, QA teams (and testers) often face hostility in the workplace. QA has been described as a “necessary evil” of the engineering process, which understandably hurts job satisfaction! No one wants to come to work feeling like their team members dread the feedback they’re there to provide. A hallmark of the waterfall method is that developers and QA are divorced from each other’s workflow. This can be incredibly frustrating for both parties, as simple fixes have to go back and forth many times. It’s especially difficult for QA, however, when their work feels tacked on at the end of the process. Many of their recommendations would be easier to implement sooner, but they aren’t given that option. Instead they feel like an afterthought, which drives dissatisfaction.

Common Developer Complaints

In traditional software development lifecycles, development is broken into a sequential series of steps. Creating a software requirements specification always comes before building the software, which always comes before testing and deployment. When the engineering team is rushed for time, developers can feel under pressure to deliver results faster so that QA can get started.

It’s unfortunate how often a waterfall methodology can create resentfulness between developers and QA. The role of developers (and the team as a whole) is to create a fantastic product. QA’s role is to provide a perspective an engineer may not have had, ultimately helping create a much stronger product. But when they aren’t working in step together, it can feel like QA is coming in after the fact and finding fault with the product. As a result, those developers want to interact with QA as little as possible, “throwing code over the wall” and waiting to hear back about any bug fixes.

Getting QA and Developers on the Same Page

QA and testing can be so much more for your business than their stereotypical role of “bug finders.” Not only should they identify defects after developers have finished their work, they should also take a proactive role in preventing problems in the first place, like a good doctor. To do so, your testers should take an advisory role, recommending tools and processes in order to help streamline development. In addition, QA and development should meet at the beginning of every sprint to ensure everyone understands what will be built, how it will be broken up, and how it will be tested. This way they’ll feel like different parts of the same team, working together to create an amazing product.

If your developers are working on one iteration while QA and testing are working on the previous iteration, you aren’t practising agile software development. Instead, you’re using a “mini-waterfall” methodology that has all the drawbacks of the waterfall model with few of the benefits of agile. Testing and development need to happen simultaneously during a sprint. Break issues into smaller, bite-size pieces that can be resolved more quickly.

Incorporating QA and testing into the development process as soon as possible is an approach known as “shifting left“—because testing is moved left on the software project management timeline. Shifting left requires a great deal of collaboration and cooperation between QA and development. For example, in order to free up testers for other duties, developers should help build an automated testing framework as part of their commitment to agile software development.

Make sure the project requirements are very clear to both QA and development at the very start of the project. QA should play a critical role in determining a project’s definitions of ready (DoRs) and definitions of done (DoDs)—in other words, the entry and exit conditions for adding an item to or removing an item from a sprint.

Final Thoughts

The key to cooperation between QA and development is the realization that quality assurance is everyone’s job. If you want your products to be known for their quality, then that commitment needs to be baked into the software development process from the very beginning. Instead of making “quality” the job of a select few, insist on quality performance from every member of the engineering team.

If you’re unsure how to get developers and QA closer together, try simple physical proximity. Just putting some desks together can do wonders for improving communication and breaking down barriers. In addition, you should put less emphasis on performance metrics around bug finding, and more emphasis on resolving issues and deploying a quality product that delivers value to your end-users.

Do you have questions about ZenHub? We’d be more than happy to help on Twitter @ZenHubHQ or email us directly.