QA and the Maintenance Contract

Testy Redhead said on Twitter:

Never stop testing in production. You have to test the cloud, not just your code. Ken Johnston #bsadt

You know, that’s my motto, too. At my last full-time posting, I set my browser home pages to client sites so that I had to look at the sites by default every time I opened my browser. I ran through the sites every promotion with a basic set of regression tests. And I hounded the developers to make minor bug fixes, the stuff marked low or typo in the defect tracker, so that a low priority did not automatically mean it was resolved (wink, wink) as won’t fix without, you know, marking it so and leading to the firestorm of righteous QA indignation.

However.

We could do that because we had a maintenance budget for these clients/sites/applications. Granted, we blew through the maintenance retainer because those retainers were set based on the assumption that the maintenance contract was pure profit after having a network admin make sure the machines were patched once every couple of months.

The point is, when your organization writes up its maintenance contracts, you should push to include as much QA and bug fixing time as you can to make the testing in production and the bug fixing palatable to the organization.

Otherwise, if the client writes a check and you’re done at product launch, you can test all you want and find a bunch of problems, but the rest of your organization will toussle your hair, chuck you on the chin, and ignore the whole business.

Comments are closed.


wordpress visitors