Testing Product Evaluations

Quality technique · See it on the map

Guide only — Running and judging a test is a judgment call.

Checking a finished product itself against its requirements, not the process that made it.

When to use it

Before handoff or release, whenever there's a deliverable with defined requirements and the cost of a defect reaching the client exceeds the cost of testing it first.

When to avoid it

As a substitute for process control on a high-volume repeat product — testing every unit after the fact is expensive insurance for problems a controlled process would have prevented earlier. Testing finds defects; it doesn't prevent them, so don't rely on it alone when the underlying process is known to be unstable.

Steps

1. Pull the requirement or acceptance criterion for the product under test, from test and inspection planning if that step already happened.
2. Choose the evaluation method that actually verifies the criterion — functional test, dimensional check, load test, visual inspection, or a client walkthrough.
3. Run the test under conditions representative of real use, not just ideal conditions.
4. Record the actual result against the target, not just pass/fail — the margin matters for the next product.
5. On a fail, route it back to the deliverable's owner with the specific criterion missed, not a general 'didn't pass.'
6. On a pass, record the evaluation as part of the deliverable's acceptance record.

What it produces

• A documented pass/fail result per criterion, with actual values recorded.
• An acceptance record for the deliverable.

Common pitfalls

• Confusing this with an audit: a passed product evaluation says nothing about whether the process that built the product was followed, and a clean audit says nothing about whether this particular unit meets spec — they answer different questions and neither substitutes for the other.
• Testing under ideal conditions that don't represent the client's actual use.
• Recording only pass/fail and losing the margin, so a product drifting toward the threshold isn't noticed until it fails outright.

Worked example

Larch & Rowe pours a set of custom concrete countertops. The testing/product evaluation is the 28-day compressive strength test on cured sample cylinders against the specified PSI — a check on this specific pour's product. It's separate from, and doesn't replace, an audit of whether the crew followed the documented curing and mixing procedure; the two would catch different failures if the strength test came back low.

Source

• PMBOK-6 §8.3

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.