Test Technique – Writing a test plan document
Friday, March 28th, 2008Warning – 3/4 finished thought.
In the event of an unknown or unexpected system behavior in the software world – the test plan documents mean nothing.
When we develop our testing strategy we do two things – outline what we WILL test AND what we are NOT going to test. The latter is always one of the hardest to figure out, explain and do effectively. A close relationship with development is required. Trust from both sides is crucial. Expert knowledge of the system and how changes affect it is required. 95% of the time this process works but other times it backfires. It is usually the unknowns that screw us.
For project X a lead tester wrote a test plan document to satisfy project stakeholders. The document brought up lots of good questions and discussion. The one section that got a fair amount of discussion was the “Not going to test” section. We explicitly stated that PERFFORMANCE would NOT be TESTED. We would eyeball the performance (web based UI connected to our 4 year old core server technology) and not provide a formal analysis of request/response times. Why take this approach? We had done load testing with a shipping release build 1 month prior. We got benchmarks, provided this info to development and discussed the risks. Everything looked good. There was no reason for any of us to suspect performance problems. Everyone agreed “There should be no reason we would have performance problems”. All project stakeholders “signed off” on the test plan.
What do you think the single biggest problem found while testing?
