Creating a test plan can be daunting for projects big and small. With the use of a structure approach and careful planning you can create plans in confidence.
This first thing to consideris the functional specification for the software (or website) and/or the systems requirements. You will then take these and then break them down into separate tests (or testing areas). You should also consider further than the written speciationâs and think over what has not been looked over yet. This will then leave you with a set of areas which require testing.
Once you have your testing sections you should think over what is required to make sure that each requirement is met by the system. Each requirement can be broken down further should the system be complex enough or the requirements vague enough.Â
You will then have a set of testing requirements which a test can be written on. You should carefully consider each requirement and how to test that it works. Min/max testing should be applied where necessary both in terms of figures and considering how you can break the system.
Once you have worked out each test you now have the amount of tests required to run for this system and therefore the workings of a test plan. Above this you should also consider regression testing. This will be done after you have confirmed your requirements and is a method of making sure that all or any fixes have not had a larger effect above and beyond the fixes own area of effect.
The test plan should then consider the methodology of the testing and the environments in which it is to be carried out. Also detailed are the assumptions you have made and therefore the risks which are taken in doing so. As a side note assumptions will by no means be bad thing and almost all projects will require some assumptions to prevent colossal workloads. Data is another key point to consider, you do not need to create the data yet but the text plan should detail your approach.
Next your reporting tools and requirements of the testers should be considered. The software and approach should be tailored to the system and budget. As a result of defects being reported you should also consider a priority system and how you what the consequences of defects will have on testing. As an example should a high priority defect which is considered not able to go live with, halt all testing, only some areas or can you carry on with your test scripts.
Finally you should consider the resources available to you for testing and how this will affect your proposed time for the QA testing phase