Test Plans in Agile
Talking to a test manager recently he mentioned that he often gets asked, “When do you do test plans in agile, if ever”. Since it is a common question I thought a blog post would be useful.
First let me clear up a common misconception. Agile does not mean NO documentation, the agile manifesto says “while there is value in the items on the right, we value the items on the left more.” So documentation is valuable, but working software is more valuable. But you also have to ask what goal the documentation is serving.
I believe in planning. I do it regularly. Mostly with flipcharts, whiteboards and post-it notes. Often my documentation of the plan is a photo of the flipchart. It is useful, I refer back to it to see what I have to do. Once the work is done though the plan serves no purpose. Creating a 5 page document is unnecessary when a photo of a flipchart works just fine.
I think test plans are exactly that, they are the plan of what you are going to test and how. The process of coming up with the plan is probably the most important part of testing in my view. It’s where you apply your critical thinking. You should be asking: What do we know about the current system? What do we know about the new requirement? What is the most important piece for users? How important is performance? Usability?
In the end you should have answers to the following questions:
- What tests does the Product Owner want to see to confirm it’s working?
- What tests do the team feel are most important to run (based on knowledge of the system)?
- What negative cases are necessary, which are overkill?
- What tests will be automated and with which tools (i.e. what cases as the unit level, what at the UI level etc.)?
- Where do we expect to find the most issues?
- What parts need exploratory testing?
- What environments will we execute the tests in, if more than one which ones will we run on each?
Sound like a lot of work? Maybe. When do you fit this in? Sprint Planning. This is exactly the level you should be looking at things in sprint planning (especially SP2). The whole team should be involved in this. Test plans in agile are not long documents written in isolation by a single tester, they are interactive discussions captured on a whiteboard or in a mind map. The goal is that everyone on the team understand what is going to be tested and by what method.
The benefits of everyone understand it are massive:
- You get 6 heads looking at the problem, therefore you are far less likely to miss an important test case.
- Everyone understands what needs to be done, and can therefore help, even if the tester is off sick.
- Developers know up front what negative cases will be tested, so they can ensure they code for those.
- The whole team agrees what is sufficient to ensure quality, this enables the whole team to be accountable for quality.
