I think of development and test as partners. The developers create product and defects. The testers detect product and defects. They both need to understand what the product is supposed to be and how it’s supposed to work (the requirements). The more the developers explain the architecture and design, the better the testers can test the product and detect defects.
So why do some people think that developers and testers are supposed to be antagonistic? The “necessity” of antagonism shows up in surprising-to-me but altogether too typical ways:
- Retaining the end schedule date even though the developers have slipped their schedules, reducing the time allowed for testing. If the product hasn’t worked up until now, why would you want to reduce the amount of time for testing? Wouldn’t you consider increasing the time for testing, if it was important to deliver a product with fewer defects? If it’s not important to deliver a product with few defects, why assign testers at all?
- Saying “It’s just a one-line change; you don’t need to test that.” Yeah, right. All of us know the fallacy of that statement. But when we say it to testers, what we’re really saying is, “We don’t care if you did find something with this change; we’re going to release anyway.”
- Making the testers responsible for quality. Testers didn’t create the product, they can’t be responsible for quality. They can report on their detection of the state of product quality, but they can’t be responsible for quality.
I suspect the reason to create tension between development and test is to mask incompetent project management. If the project manager can’t figure out how to create a quality product given the constraints, s/he can blame the developers and testers by creating tension between the developers and testers. By the time they’re done yelling at each other, the project manager can look like an island of serenity and competence.
Instead of creating tension between developers and testers, let’s create projects where the entire team is out for the same thing. Where everyone understands the project’s constraints and requirements, and creates ways to work together to achieve a successful project. (In my post tomorrow, I’ll talk about the project’s constraints and requirements.)
In the meantime, if you see a project where the developers and testers are in tension, step back and look at the big picture. Is the project manager helping or hurting the project? Does everyone know how little the project can accomplish before the project is done? Does everyone know what the project’s goals are? Does the schedule make sense? Is anyone measuring anything about the project?
Tension between developers and testers is not creative and does not help the project. Teamwork, where the entire project is focused on one goal helps the project. Look for teamwork, not tension on your projects.