Levels of testing

December 25, 2021
Who is responsible for unit, integration, and acceptance testing? Developers.

I recently came upon an infographic on LinkedIn, which I won’t include here, because I don’t want draw negative attention to the author whose name appears in the image. But it’s quite simple, and the text reads:

Levels of Testing

  1. Unit Testing — Done by Developers
  2. Integration Testing — Done by Testers
  3. System Testing — Done by Testers
  4. Acceptance Testing — Done by End Users

This mindset might have been considered acceptable in the 1990s. But in the age of Agile software development and DevOps, we now know this approach is not a good one for a number of reasons. Most important, we now know that quality suffers when developers aren’t writing acceptance tests. We also know that it’s very inefficient to have so many work silos and breaks in workflow.

Furthermore, any developer who can’t write integration or system tests is not a qualified developer, in my opinion. Would you hire a plumber who only makes sure the faucent works, but doesn’t know how to test that the faucet is connected to the water supply?

What about acceptance testing?

If your developers don’t understand the customer requirements sufficiently to do acceptance testing, they also don’t understand customer requirements enough to implement the feature in the first place.

If you find yourself in a situation where developers cannot do acceptance testing on their own, the solution is probably to get the developers talking to the users of the software, not shirking their responsibility by offloading that testing work.

So here’s my fixed version of the “Levels of Testing”:

Levels of Testing

  1. Does it work? — Done by Developers

Related Content

The False Dichotomies of Automated Testing

I just threw away a bunch of tests

I had failed to complete the "refactor" part of "red/green/refactor" several weeks ago, leaving me with some redundant tests that came back to bite me.

When is 95% test coverage worse than 5%

Test coverage for its own sake is dangerous. It leads to foolish technical choices.