Fixing problems requires knowing how the problem was created. Knowing how a problem was created requires knowing what you’ve been doing up until that point. And the easiest way to keep track of a series of actions that produces a problem is with test planning.
How I’m using test planning:
What the heck are we doing?
We’re implementing test planning for Telesaur.com. We’ve created scripts that testers follow. Each script contains a series of actions to perform, and testers log errors as they find them. Errors are easily tied to the scripted actions that caused them. Then, when we work on those areas in the future, we can be on the lookout for previous errors. If you’re curious, here’s an extensive test sample plan (with more detail than I ever plan to implement).
How teleworkers can use test planning:
Teleworking, on any scale, creates room for error. And without a way to identify an error’s cause, the errors can rarely be fixed. Telework becomes the scapegoat when we’re not managing our workflow properly. That’s kind of like throwing out a new car because the brakes were bad. Fix the brakes.
Test plans for decentralized teams could potentially refine our workflow and communication. Identify the chain of events that brought you to a failure and pinpoint the critical actions that are broken. Was it Bob’s email? Was it Natasha’s Blackberry? Was it Harvey’s alarm clock?
Note to self: Test planning isn’t real.
That’s right, it isn’t the real thing. We can’t plan for everything. But when we come across errors outside of our test plan, we’ll document that error as a new set of actions in our test plan. We can launch Telesaur.com major development errors resolved, while still responding to unexpected errors as they surface. You can test plan telework on paper forever, but nothing beats real world testing.
Worried about rolling something out to your whole company or all of your clients? Just hand it over, full strength, to a few people. Test, document, analyze, repeat.
How could you benefit from test planning?
