If you've ever been in the position of knowing your management would like you to decrease test time, but you don't know what your management wants, then you've been a player in the bring-me-a-rock schedule game.

The general form of this game is:
"Bring me a rock."
"OK, here's a rock."
"No, not that rock. A different rock."
"OK, here's another rock."
"No, not that one either..."

Although, in the software testing world it probably looks a little more like this:

Senior manager: How fast can you test this product?
Test Manager: We'll start our work during requirements, but we'll need eight weeks of final system test time at the end of the project.
SM: Not good enough. Decrease the time.

The test manager walks away, gathers her staff, and determines how to cut corners. She returns to the senior manager with a new estimate:

TM: OK, we can get it down to six weeks.
SM: Still not good enough. Decrease the time.

The test manager is starting to see the bring-me-a-rock trap.

TM: Well, how long do you want the testing to take?
SM: You're the test manager, aren't you? You tell me!

No matter what the test manager does to compress the schedule, it won't be enough—unless she can reduce the final test time to zero. Whatever duration she proposes, it will be too long.

If you find yourself in this situation and you succumb to the game, you'll end up agreeing to something unreasonable, whether that's a reduction in scope or time, or an increase in defects.Instead of playing along, here are four options for combating the bring-me-a-rock schedule game:

Explain Why You Need the Time
Explain how you use the time, the risks you're trying to manage, and some alternatives to managing those risks. Offer your manager a timeline of the testing and problem-fixing cycles to illustrate why your team needs as much time as possible to get the job done right. If you have historical data about what you do during system test time, explain the duration of each cycle of testing and the following defect-fixing activities. If she insists on reducing the test time, let your manager know what her options are and what the consequences might be. For example: Start testing earlier, which will affect work being done on other projects.

Use Release Criteria to Determine What You Won't Do
If you have release criteria along with the date, explain the risks if you choose NOT to test some parts of the product. Determine how risky not testing those parts will be to the overall product.

Understand the Requirement for the Change in Date
Ask some questions before attempting to fetch more rocks: Would you prefer more people or fewer? Sometimes you can bring other people in to accomplish the testing faster. How defect-sensitive are our users? Can they live with more defects? Your user base may be ready to settle for more defects if they can use the product earlier. If so, determine the actions you need to take to be ready for the post-release defect reporting.

Elicit the Strategic Reasons for This Project
Ask several context-free questions: Who wants this project? What does a successful solution look like? What is the project worth to you? Why are these results desirable? What problems do we solve with this project? Does the project create other problems? The answers to these questions will help your management articulate (and you understand) the underlying concerns. Then, once you understand management's concerns, you can specify some tradeoffs your management could accept for a new date.

You always have options when you encounter bring-me-a-rock. You can "yes" your management then do what you want anyway. You can find another role on the project or even another job. But whatever you do, don't play along with bring-me-a-rock. If you do, you'll train management to expect you and your project team to work on unreasonable projects.