“Karl – how’s testing going on Project Zeta?”
“Not too good, Michael. I can’t figure out which features have been implemented, it looks like several key requirements have changed but I don’t know what the new details are, and I have a whole slew of untestable requirements.”
“Some of those ‘the system shall be available for 99.9% of the year’ requirements?”
“You got it. The requirements team makes it so hard for my group to do our job – and that’s on top of our testing time always getting reduced!”

I’ve changed the names to protect the innocent, but conversations like this happen all the time. As Product Managers, we produce requirements for all of our stakeholders – and that includes teams like training, development, and testing. I’ll give you three simple pointers to keep in mind that will make your test teams your best friends.

Make Requirements Testable
Easy, right? Then why is this still a problem for so many people? Part of the problem is that we take statements like the one above (about availability) at face value as valid requirements. We need to probe and explore to find out the real reason behind the statements (and therefore the true requirement). Include someone from your test team in the review process and specifically ask them to highlight requirements that are untestable or risky – and work to resolve those.

Setup Traceability
Karl can’t tell which features are implemented probably because traceability hasn’t been setup. Go here for details on how to do traceability (and why it is so important).

Maintain Good Change Control
Requirements change. If you aren’t setup to deal with this fact, your project will suffer for it. Make sure that when things change downstream teams are made aware of the change. I won’t dictate how you do this – your internal organization and development methodology will determine this – just make sure you have some kind of process in place that everyone understands and follows.

Keep these suggestions in mind and your testers (and Karl) will thank you!