Apps + Coffee Connection: Got friction? Ideas to diffuse tension between developers and testers

This blog is part of a series that delivers insights from the monthly meetups of Bugsnag’s Apps + Coffee Connection (ACC) community.

Ample opportunities exist for tension to spring up between developers and testers, given the nature of each team’s work. While a little friction can be fine (and sometimes even healthy), organizations are more likely to flourish when these teams work well together. The ACC meetup in November explored some of the common sources of issues between the two teams, and participants shared lots of ideas on how to diffuse tension and bring developers and testers into alignment.

Pinpoint the real cause of tension

Let’s be honest: development and QA are set up to butt heads. Developers want to ship code quickly and may feel that testers are always slowing things down or holding back releases.  

On the flip side, the tester perspective was summed up by one participant who stated, “The biggest tension comes from developers getting the code to QA towards the end of the sprint. Then we only have a couple days to find as much as we can and get those issues resolved before it’s released into production.”

Another participant believes that the root of this challenge can be found in the way companies transitioned from traditional engineering to Agile methodologies… but ended up implementing a version that doesn’t always stay true to Agile practices.  

“People will say they are doing Agile, but they are really doing little Waterfalls every two weeks: design, dev, test, deploy,” the participant stated. “The last three days of the sprint, testers are really under pressure because that’s when everything is thrown over the fence. That’s not really Agile because you’re not shifting testing left in the release cycle whatsoever.”

Rethink roles around automation and testing

Hand-in-hand with adopting Agile is the desire by organizations to release faster through automation and practices such as continuous integration and continuous delivery/deployment (CI/CD). Remarkably, these strategies often put the onus on the QA team, which several participants voiced as inappropriate.  

“In my opinion, the job of a tester isn’t to write automation. It’s to do what they are good at, which is to find the quirky things that developers will not necessarily think of and to do more exploratory testing, which is what adds value to the process,” a participant stated. “It’s important to make sure the developers pick up a fair amount of that automation work and focus on writing and supporting the automation so that the team can become more productive.”  

One suggestion was for developers to contribute to automation by creating end-to-end tests that can then go through a review process with QA—same as the underlying software. As one participant stated, “If you have brittle tests and they break all the time, you will spend all your time fixing brittle tests. It’s better to have tests that are well thought out and well intentioned, which takes some effort on the developer’s part to really think through the test cases, to understand the code and what they are testing.”

Aim high with accountability and shared goals

A traditional method used to manage development and QA is to define OKRs that draw a clear line between the two teams and what each group’s responsibilities are. The teams are then credited for their respective successes in finding and fixing bugs. While this strategy is designed to delineate the work and responsibilities, the underlying methodology may also create an “us versus them” mentality.  

One participant offered up an alternative approach: “The issue is accountability. My organization tries to solve it by not having a separate QA team where developers throw requirements over the wall so QA can write all the tests and find all the bugs. Instead, we have QA embedded in each of the feature teams, which eliminates a lot of the friction and puts more accountability on the engineers to write things like unit tests and integration tests.”

Since tensions are often born from being on different teams with different leadership, budgets, and goals, putting engineers and testers on the same team means everyone is working towards common goals. As a result, both teams are more likely to focus on quality.

A QA participant spoke to her positive experiences working within this model: “We are embedded within different feature sets. We work really closely with Product and the developers from the early planning stages to understand the acceptance criteria and the business rules and to provide any input as early on as we can to provide any edge cases we can see so the developers can take it into account when they are coding.”  

A developer participant chimed in about the benefits of working closely with testers from the start, including transparency around what each person will do and knowing upfront how the code will be tested. “When there’s no ambiguity around how the code will be tested, it naturally feeds into the psyche of how the developer will develop code,” the participant explained.  

Move testing to the left, trust up and to the right

One benefit that comes from development and testers working closely together is that it speeds up the entire testing process. As one participant explained, “You’re moving testing more and more to the left in the release cycle. You’re not waiting for those cold handovers. That’s what builds trust between everyone on the team. It becomes a team effort.”

To get code into testers’ hands more quickly, one participant suggested development teams should help spread out testing as much as possible. “One thing I’ve found to be very helpful is to make sure developers break up bigger projects into the smallest, most sensible pieces of code that can be shipped faster,” the participant stated. “If QA is working with the developer in terms of breaking things up, it diffuses a lot of that tension and a lot of that stress towards the end. It makes things a lot safer, and the developers seem to feel more satisfied shipping out these smaller pieces faster.”

In a similar manner, developers should work to schedule a mix of bigger and smaller items within a sprint and not always take on one enormous item per sprint. Smaller projects can then be delivered quickly so QA can work in parallel with development and start testing sooner.  

Documentation can save the day (or at least some valuable time)

Several participants pointed to the need for documentation as a way to cut down on a lot of the back-and-forth, inefficiencies, and potential for hard feelings between the two groups. “I think it’s vitally important that developers do the documentation work when working with QA to explain how you test the feature, if it needs specific testing, and how to verify that it’s working,” a participant stated.  

One testing participant echoed this point and described two things that help diffuse tension between her team and developers: 1) strong ticket documentation that states what QA should be looking for and testing in new code, and 2) developers giving their work a once-over, at a minimum, to make sure it’s working as expected.  

Another strategy is to create awareness and a common knowledge across groups about where you have exposure. As one participant stated, “It’s drawing out that matrix to know what’s complex, what’s trivial, where’s low coverage, where’s high coverage, and then do that for all of your features. Then everyone has a good feeling about where you should pay more attention when making a change.”

On a final note, alerting is another factor that can help QA teams stay on top of a new release. As a testing participant stated, “Almost any time we release something of great importance, we have robust testing and alerting. I feel like alerting often gets missed.”  

In it to win it, together

Ultimately, participants believe that everyone is responsible for software quality. Collectively, teams must understand what is being built and how each person can contribute to the success of the solution by communicating and discussing feature changes. When everyone knows what is in each iteration, then everyone will have the same definition of “done.”

One participant pointed out how important it is to always remember to attack the issue and not the people. Tension can build up when people are working in separate environments (such as working from home), which is why it’s also important to build relationships between teams and individuals by doing things together—whether it’s listening in on meetings, having lunch together, or simply talking to each other.  

Interested in participating in conversations like this? Join the monthly discussions with the Apps + Coffee Connection community by registering here.