Agile Test Plan - Do We Really Need One?
Do we need an Agile Test Plan Document?
Test Planning is an important activity of a testing process and one that requires careful thoughts and decisions from not just the test manager (who is usually responsible for creating the test plan) but all members of the testing team and product development manager.
Some people believe that it is the most important part of the testing process (I personally think test designing and abstract thinking is the most important) and spend many hours and effort coming up with a great test plan.
Text books dedicate a whole section related to test planning, how to write one and what to include in a test plan while some governing bodies and regulatory organizations such as FDA require a comprehensive test plan in order to approve a product.
In the real world, in a waterfall environment, quite often the test plan document is one that is hardly ever looked at during the life-cycle of the product. The activity of “Test Planning and Monitoring” should be an ongoing activity during the project life-cycle, it should be updated as per changes to the project, but in most cases this is not the case; test plan is either not updated or changes are retrospective, making the test plan document the least valuable by-product.
Whilst test planning is almost always considered as a must-have product in a waterfall project, do we really need a test plan for an agile project? i.e. does it really add any value to what the whole team is trying to achieve?
The agile manifesto clearly favours working software over comprehensive documentation and responding to change over following a plan.
In an agile environment, the contents of a release (the items) are discussed before the sprint so the testing team know in advance what is the scope and what should be tested.
In the “planning poker game” the estimates are discussed through so the testing team know how long it will take to test a feature (this is inclusive of environment setup, scenarios, automation, exploratory, performance, etc).
In “story writing session” where details of each feature is thought through, the test team are already beginning to write scenarios to cover the many ways stories can be tested - this is the most valuable activity of the team.
During the sprint, QA are continuously testing new code/feature. Test planning becomes a dynamic activity as the priorities for the day change. Testing is based on what is the activity for the day and the outcome of the day before.
It is clearly evident that test plan doesn’t reveal defects but test scenarios will. The effort needs to be shifted on creating better scenarios than creating a test plan.
What is really needed is a short agile test strategy document outlining the processes applicable across sprints, i.e. sections about Sprint Planning, Specifications Workshops, Manual QA, Automation, Test Coverage, Test Reporting, Test Environments, Staging, etc… These are processes and activities applicable to every sprint but of course derived by the company’s vision.
So, with all this in mind, is the Test Plan document or extensive Test Strategies really a thing of the past? Do we really need an Agile Test Plan?