Most people don’t volunteer to write a test plan but writing a good test plan isn’t rocket science either. The most important part of good test planning is having testable requirements. Vague statements like ‘the system must be fast’ or ‘the user interface must be intuitive’ aren’t testable and will ground your test plans before you even take off. Getting your requirements documented correctly is a necessary prerequisite to any test planning. Part of your requirements need to call out system requirements. Pop-up blockers, required plug-ins, and varying browser configurations can all impact your test results. Once you’re confident in your requirements, keep these 6 items in mind, and you’ll be well on your way to mission complete.
1. Keep it simple
Don’t repeat information that is included in other documents. Refer to your requirements document and traceability matrix as you build out your test plan. On the other hand, do not copy the information into your test plan or try to list all of the test scripts you’ll be executing before you’ve even written the test scripts.
2. Plan for failure
Nobody is perfect, and neither is software. Your plan should include everything from pass/fail criteria to how you will manage defects, including a severity ranking system. A defect could be a show stopper if it causes a system crash – even if it’s related to a low priority requirement.
3. Who ya gonna call?
Identify who will execute your testing. A dedicated QA group may need some additional system training prior to starting the testing process to understand how the business will be using the software or how to interpret the expected results. Business users will need some training on how to document test results – especially failures. If an automated testing tool will be used, your test scripts will need to be in a specific format.
Tip: A shared error log with an owner is a test documentation best practice.
4. Don’t forget the negatives
Most requirements only call out what a system SHOULD do. When you’re working on a timeline for testing, don’t forget you may need to conduct negative and boundary testing. You may be able to eliminate some testing if the software vendor has already documented some basic system functionality.
5. All the world’s a stage
Staging data for test execution can be a time-consuming task, so don’t forget to budget time for this critical step in your timeline. It’s generally better to stage specific data for each test script rather than try to link test scripts. Murphy’s law states if you expect to use data from test script 1 for a later test script, tester error will inevitably make the data unusable.
6. Test real world situations
There is typically more than one way to do something in an application. It’s important to test the actual way the system will be used by the business users. If data migration will be part of your project, plan to use migrated data for some of your testing. It’s better to find out during testing (versus the first week of go live) that migrated data behaves differently than data entered through the system.
