For several years I’ve told our customers that we begin test planning by learning about their business objectives. A VP in product development told me that he had no problem discussing their business goals with me, but surely such a discussion had nothing to do with testing. He said “I’ll give you the requirements; I’ll tell you when I need to know if we have met those requirements: all I want from you is to create test cases validating my requirements, and how long it will take you to run them.”

Maybe he tells me his business objective is to gross $20M next year. That doesn’t help me. I need to know how he plans to get there, and what part his software plays in those plans. Maybe he’s selling day-trading software at $30K per system. Maybe he’s developing software to monitor POS transactions at 36 of his stores in 4 states. In the first instance, which is a sort of product development, he’s spending testing money up front that he hopes to recoup through product sales. In the second instance, a kind of IT tooling, he’s hoping to optimize business processes in order to reduce overhead costs. They differ in what to test and how to test it. In the first, delivering feeds from several markets in real time is going to be a major criterion for quality; in the other, getting it in real time isn’t as important as interfaces to inventory databases, a bookkeeping system, and credit card companies.

A company won’t know if it’s meeting its business objectives unless those objectives are measurable.

So the objectives have to be translated into dimensions. Verifying delivery of live data in real time can be measured in units of time. Tests can be written whose output is expressed in units of time so that output can be compared to target values. A short way to say it is that quality objectives must support business objectives.

If that VP in product development did not write requirements that reflected quality objectives that would support his business objectives, even if we had delivered test cases in a day and executed them in only 15 minutes, in a very real sense he would still be clueless regarding ship-readiness. Being ship-ready cannot just be about passing tests. The tests need to be meaningful – that is, they must verify that specific functions complete actions necessary to the fulfillment of business objectives. It is much easier if requirements have been written for that purpose. All this must be considered for test planning.