Quite the contrary! Developer testing lets the team leverage the testers’ expertise and allows testers to engage in valuable testing. Valuable testing is exploring the product in a wider context, siding with the end user, planning and executing exploratory testing, or coming up with the truly tricky test scenarios. It also lets the tester advance to become the team’s quality champion.
Developer testing also has its limits. It can’t, and it’s not meant to, replace certain kinds of testing that requires special skills or resources, most notably security testing, advanced performance testing, or usability testing. To be honest, teams that get really good at developer testing and stop experiencing defects related to functionality may get too confident and stop paying attention to the basic usability of their products, i.e. what they produce has no defects, but is ugly and unintuitive to use.
There is a kind of “testing” that’s totally killed by developer testing though. It’s the kind of testing commonly referred to as checking or scripted manual testing. Some people go as far as calling it “zombie testing” in reference to mindlessly following a set of scripts or scenarios over and over again. Yes, certain systems require a share of such testing under certain conditions, but the majority doesn’t. So, testers who spend 40 hours a week maintaining and executing scripted manual tests will become superfluous once the team gets developer testing.
Read more about these topics in Developer Testing: Building Quality into Software:
- Chapter 1: Developer Testing, pages 5-6
- Chapter 2: Testing Objectives, Styles, and Roles, pages 9-19