The division of labor couldn’t be clearer:

  • Quality assurance professionals are supposed to test and report bugs.
  • Software developers are supposed to build and fix code.

Getting a product ready for launch might require hundreds (or thousands) of back-and-forth exchanges to fix all defects. However, that’s how the industry is set up.

But what about those really minor bugs that you (as a tester) could easily fix in a few seconds:

  • Should you resolve the issue and bring it to the developers’ attention (for future reference)?
  • Or

  • Should you send the bug back and have the developers fix it on their end?

Unfortunately, there is no universally accepted answer.

Some teams are so tightly integrated that the division of labor isn’t clearly defined. And they manage to pull off testing and development very smoothly.

But in our experience, this setup is a recipe for disaster.

When things are going well, everyone is okay with nebulous lines of responsibility. But when problems arise, clearly defined roles emerge retroactively – with lots of finger-pointing and shouting.

But what about when there are distinct testing and development teams – each with clear-cut responsibilities? Is it ever okay for the QA guys to do a little bit of code-fixing?

There are compelling reasons for and against this approach.

Let’s take a look.

Why Software Testers Should Become Temporary Developers

The most obvious benefit is efficiency. When you have testers make easy changes, it reduces the number of back-and-forth exchanges required.

This approach also potentially reduces some of the passive-aggressive resentment that sometimes crops up. We’ve witnessed the following conversation take place on more than one occasion – and perhaps you have as well:

Developer: In the time that it took you to tell me about this bug, you could’ve just fixed it.

Tester: Look, it’s not my job to fix your mistakes. I’m here to find them.

Developer: But that’s a waste of time. It would be much faster if you corrected these simple mistakes.

Tester: If speed is your concern, don’t make simple mistakes in the first place.

By letting software testers do some of the fixing, you can avoid this type of toxic breakdown. But we would argue that having testers develop (and developers test) can lead to even bigger problems.

Let’s take a look.

Why Testers Shouldn’t Act As Developers

Software testers are expert at finding bugs. But it can become pretty dangerous to have QA professionals digging around in the code. They might be able to fix the problem, but they could just as easily end up pulling the wrong thread.

Note that this isn’t simply a matter of experience or skill. Code is highly customized and interdependent. Even veteran developers avoid stepping on each other’s toes until they understand all of the dependencies involved.

Moreover, not every bug is a bug. Sometimes there is extra code on purpose to support some future feature or to act as a temporary placeholder.

Lastly, quick fixes don’t always get documented correctly. And you end up disrupting the version history, making it less likely that everyone is working on the most up-to-date iteration of the product.

This is why we strongly feel that the best approach is to keep testing and development duties separate. Otherwise you put the entire project at risk.

Making Well Defined Roles That Work for Everyone

What about the toxicity and inefficiency discussed earlier? Given that:

  • Developers will always make easily correctable mistakes…
  • And

  • Testers should avoid fixing those mistakes…

How do you mitigate passive-aggressive flares and unnecessary back-and-forth?

Good questions.

Solving the efficiency issue is easy. Simply stop focusing so much on speed. Given the choice between launching a product that works versus a product that reaches market quickly, we should always choose the former (for the reasons listed here).

Tackling the group dynamics issue is a bit trickier since you’re dealing with personalities and egos – from both sides of the aisle.

We recommend the following strategies:

  • Make sure everyone is on the same page and understands the bigger picture. This involves having regular meetings throughout the project cycle that include all relevant parties – including developers, including testers.
  • Equip every team member with the tools, resources, and support he or she needs. There should be no weak links anywhere in the system. And everyone should be regarded as a valuable contributor.
  • Most important of all, encourage open and honest communication. Problems will inevitably arise – in fact we’re paid to find them. And developers are paid to fix them. But this symbiosis only works if team members communicate effectively with one another.

Agree? Disagree? Please share your thoughts down below in the comments.