This checklist summarizes the steps for securing an investment in testing. The process is neither sequential, nor automatic. That's part of the point. This is essentially a mechanism for securing investment (resources and commitment) to produce some value for the organization.

Step - Identify the sponsor(s) who have an interest in the value testing can deliver.

This means identify who has an interest in the value delivered by the system(s) you are proposing to test. Testing (or development) may have been talking to the wrong people.

This can cause organizational friction if development isn't delivering value or sees itself as the sole communicator or arbiter of how systems deliver value.

Step - Identify the compelling values that motivated building the system in the first place.

This means understanding the value people will get from the system in use if everything works out as planned. You have to understand what the intended users do.

This means access to the formal and informal system justifications. If there is resistance (which there may be), say, "I need to focus my test plans on what is important."

Step - Identify what places this intended value at risk and what information about a system might reduce that risk (actual and perceived).

This connects the justification simultaneously to sponsor's concerns, and to the core capability of testing reliable information about a system.

Testing exists because intentions and predictions of system behavior are not perfectly reliable. Developers or sponsors may not want to admit that some of their speculations are less than perfectly reliable.

Step - Develop a candidate testing implementation to provide the valuable information that has been identified.

You are proposing a way to deliver the valuable information you have identified.

You have every right to propose providing any information that is valuable, and within your capabilities. "Testing doesn't do that" is a smoke screen. "Well, somebody ought to, and we can." End of issue.

Any process change impacts all the associated processes. Include them.

Step - Develop your presentation in terms of the seven process investment questions.

Use directional / trend assertions. Back then up with loosely related but accurate data (the helpdesk error rates, for example). Use a narrative to reinforce your points.

Some colleagues from development or testing may object to directional measures. In fact, viewed from the outside, development itself is directional and probabilistic. Stick to the data: real systems have bugs. Unless the bugs were intentional, development produces probabilistic, not absolute results.

Step - Track and report implementation progress to all interfacing organizations and to sponsors.

Once the investment is approved, getting it implemented becomes your project. When you suggest a testing process change, you are not prescribing something for senior management to do, you are offering to go do something yourself if they approve.

Interfacing organizations may try a "pocket veto." That's their problem. Reporting on what is getting done (and not) is yours.

Step - Track and report outputs to supporting organizations and sponsors.

An investment in a business process is like a loan - you're committed to make it pay off.

You're accountable for the outputs you committed to produce. The supporting/influencing processes and people are likewise accountable for using it, or not.