When Developers and Testers Collide

In an earlier post I discussed collisions and conflicts which may occur within an Agile environment. A common collision on Agile teams occurs between testers and developers so let’s dig into this scenario a little deeper.

When we begin introducing agile into organizations, the impact is often strongly felt by the testing community. Testers are an easy target when bugs are released into production and are often the focus of blame. Because of this, testing groups have built heavy processes and sign-offs to protect themselves from what they know will be coming later. Trust will need to be restored before testers will fully engage and freely interact with a team.

In dysfunctional situations, developers and testers will often come into a team thinking of each other in one of four ways:

The Outsider. You don’t know enough about what I do so I’ll keep you in the dark or ignore you for as long as possible until you just go away.

The Obstacle. You’re on the team but I don’t like it. I’ll do just enough to keep you off my back and nothing more.

The Speed Bump. I know you’re there for a reason and I should slow down a little for you but why bother.

The Enemy. “Your code stinks.” “Your testing stinks.” Repeat.

Obviously, none of these attitudes will go very far on an Agile team. We must find a place of mutual respect for each other, value each other, and become amazing agile teammates.

Start small but start with something. If the relationship between developers and testers has a history of being toxic in your organization it will not go away on its own and the effects of the dysfunction will only be amplified on an Agile team. Quality must be a team event.

Empower your Scrum Master or Agile Coaches to use subtle changes to build (or rebuild) a foundation for the testers and developers to form their relationship on. Here are a few activities to consider:

Learn about customers together. Schedule a field trip with the entire team to watch people use your product, app, or web site. Seeing the impact our work has on people (both positively and negatively) brings clarity to what is really important.

Build stories and acceptance testing together. Rallying around the user will further shift the team to a position of focus on who will receive value from what we are building. If they aren’t already, have developers and testers author acceptance criteria together.

Mature your definition of “done.” If you haven’t looked at your definition of done lately perhaps it needs some attention. As the Scrum Guide states, “As Scrum Teams mature, it is expected that their Definition of “Done” will expand to include more stringent criteria for higher quality.”

Create unit tests together. This may be a challenge but worth suggesting. Try having a developer and tester “pair” while writing a suite of unit tests. The quality perspective from the tester and the extra set of eyes could be beneficial and begin breaking the ice.

Emphasize conversations around quality and “done” over tools and process. Don’t track bugs on currently in progress stories as a defect. I have seen teams want to do this but resist the urge…the story just isn’t finished yet. If conversations aren’t enough just write a task for the bug and add it to the information radiator.


Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

6 thoughts on “When Developers and Testers Collide

  1. Love that last part…”the story isn’t finished if we have known bugs.” But of course, the team should be working towards TDD. If not the devs will just say QA is holding “us” back (as QA would be the last “step”).