Posted by: Shilpa Venkateshwaran
In traditional software development methodologies we are used to writing long test plans. We usually had releases only couple of times a year and we had days to plan and write a test plan. These days the release cycles are getting shorter and shorter and we don’t have the time to write a 10 or 20 or longer page test plan. Even if we did write it, our teams don’t have time to review it and give feedback.
What we really need is planning with agility. We have to be able to plan or strategies for testing and communicate all relevant information to the team. It doesn’t have to be a long document but we have to be able to plan and also communicate our testing strategy efficiently and effectively.
Here are some things to keep in mind
- Don’t skip planning just because there is less or no time for it. Its important to have a strategy in place for testing. Spend the time on this but only write things that are important for the planning and communicate to the team.
- If there is a risk management tool or some place else move some long term risks and assumptions do that. This way the team has access to it and this can be managed independently of test planning document.
- If the team is using tools for managing test artifacts like HP Quality Center or Rational Robot, then document the process for these tools outside of the test plan. Reference this document in the test plan.
- Keep a master test plan for testing processes and definitions (if the organization uses testing handbook move some of the process information to that document). This way testing terminology can be maintained separately and is not dependent on the release.
- Stick to defining test strategy to what needs to be planned for each release or iteration. Do diagrams or pictures where ever possible. This way dependencies can be shown clearly and it will be easier for people to understand how the application is being broken down for testing. For example if you have feature A that can be tested only after Feature B is delivered then show that dependency in a clear way and communicate to the team. This they also see the clean picture and if they don’t agree with they will be able to let the test team know.
- Get inputs from the team they might be able to help with identifying dependence’s or risks that might be easily missed.
So dont skip planning just think about it differently and with agility.