Skip to content

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.

 

Advertisements
5 Comments Post a comment
  1. glaucoaq #

    Great post! I was looking for information to show my team the importance to properly plan tests, but everything I had found was just filler, yada yada yada and waste of time, until I found yours 🙂

    March 18, 2014
  2. Archana #

    All the above questions is answered by scrum. It all depends what the team is comfortable with. If team feels writing test plan is good then its good.
    But if i talk about my team. We have EPICS which has PBI’s linked. Example: If team took couple of PBI’s for current sprint may be 3.
    Each PBI should have different tasks associated with that.
    1> Analysis
    2> Scripts if needs(schema changes)
    3> Implementation
    4> Code review
    5> Testing( Automation and Manual)
    6> In sprint demo

    In testing task we can have automation or manual testing task
    Before that what all testcases which we are going to test should be written and linked with the testing task , so that who ever sees the testing task of the PBI understand what all scenarios have been covered to test that one. (Testcases can be sent for review even to the team all well as PO)

    Team can decide which all testcases need to be automated and which will add value in regression or the testcases which will be reused in future.

    Automated testcases should be checked in same source control so that its available to team.

    In short i just wanted to say if the PBI meets the acceptance criteria and we have testcases associated with the same the test plan is not needed in scrum.

    July 23, 2015
    • shaik #

      Thanks

      December 14, 2016
  3. Muhammad Faris #

    Thank you for making it a post!
    *thumbs up

    February 3, 2016
  4. Archana #

    This reminds me of the scrum which my team use to do, almost exactly the same way.

    Agreed with your points, Testplan format or representation is change, but it’s not lost. Now it depends how much and what to be documented. Documentation helps and is needed but not exostiv.

    Benefits are listed well, it leaves us with the thoughts. (Group is better then single and that’s team)

    June 20, 2017

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: