The pain of platform possibilities: Page 2

(Page 2 of 2)

Having just been the victor in a bloody battle to get development to agree to support this very server so he could book the sale, he was furious. "Why didn't someone tell me this before?" Again, I smiled. "No one asked the test group."

The ultimate benefit of clarifying what the company will test and what it won't is that it gives everyone a chance to mitigate risk.
I am confident this scene plays out every day in many corporate enterprises. Adding support for a new platform is not just a development issue, it's a testing and support issue. In fact, you can compare the development effort to having a child: it may take nine months to develop it, but testing and support have to raise it for the next 18 or more years as it goes through every patch, release, and version of its life.

Supported configurations

Once you have identified the certified configurations, anything else marketing wants to sell becomes "supported." This means that although the company doesn't represent that it has, in fact, tested a precise configuration, it agrees to accept responsibility for resolving any issues that arise.

At first this may sound like a PR problem, but in reality it's a plus. If the customer has a problem with a supported environment, it doesn't automatically raise the question of whether the company tests anything at all. Without this distinction--and we've all heard it before--when a customer uncovers a major problem with an obscure combination, he immediately freaks out and questions the competency of the test organization altogether. For most battle-weary testers, this can be a morale killer.

With supported environments, at least there's notice up front about what the company is committing to test versus what it's willing to take responsibility for. As a result, the customer realizes the risk it's assuming in adopting this configuration.

Mitigating risk

The ultimate benefit of clarifying what the company will test and what it won't is that it gives everyone a chance to mitigate risk. If company officials are concerned a key account is at risk because its configuration is not certified, they can mitigate that risk in one of two ways: One, they can invest in additional time and resources to cover that configuration; or, two, they can include the account in the beta program.

In fact, customers with supported configurations would be ideal candidates for early release. This would allow the test organization to extend its coverage without bloating staff or costs, and it would allow customers whose configurations are at risk to participate in the test process.

The point is, it's wrong to simply assume that test organizations can fully test every platform and every possible configuration the software can potentially run on. Both the company and its customers should be fully informed--and the test group fully equipped--to deal with the risks posed by the many potential platform possibilities. That way, testers have a hope of meeting quality expectations, because they will be both clearly defined and, more importantly, actually achievable in the real world. //

Linda Hayes is CEO of WorkSoft Inc.. She was one of the founders of AutoTester. She can be reached at linda@worksoft.com.

Page 2 of 2

Previous Page
1 2

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.



IT Management Daily
Don't miss an article. Subscribe to our newsletter below.

By submitting your information, you agree that datamation.com may send you Datamation offers via email, phone and text message, as well as email offers about other products and services that Datamation believes may be of interest to you. Datamation will process your information in accordance with the Quinstreet Privacy Policy.