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