Thursday, May 11, 2006

Acceptance Criteria

When your QA team tests your product before release, you want it to satisfy the requirements that your product manager has specified. But as I have mentioned before, while requirements should always be testable in principle, it is not always practical to test them directly before release. When a requirement is not directly testable before release, what should your QA do to ensure the product satisfies it?

Your product manager, designers, and QA team should collaborate to agree on acceptance criteria. In many cases, acceptance criteria for a product are exactly the same as the requirements. But when it's not possible to test a requirement directly, you can define separate acceptance criteria that indirectly give you confidence that the requirement is met.

One example I have given of a requirement that may not be practical to directly test before release is:
Take, for example, the requirements for a new, super-reliable model of car. We might specify that the car should last seven years without repairs as long as the owner maintains the car according to a certain maintenance schedule and doesn't have a collision. But it is not possible to directly test whether the product meets these requirements without producing the car and driving it for seven years.
What corresponding acceptance criterion could you use to test this requirement before release?

The question becomes: "What can I test about the car before release so that I can be confident that the car would last seven years?" Designers and testers will be most qualified to answer this question, but one possibility is to set up a simulation that accelerates the wear and tear on the car. If the car lasts one week in the simulation, then we might be able to extrapolate that it would last seven years under real-life conditions.

No comments :