Hello All,

  I have been working on Agile projects for past 1.5 years and wondering with new approaches that is popping in each time when it comes to test plan.

  At times i was educated that there is nothing called test plan document for Agile project as  we plan the development(Which includes testing) in sprint planning and the progress will be tracked using the burn down charts, daily stand up and closed working model. Having that in place there is no test plan that needs to be devised for the sake of document.

  But at times in Audits i was asked where is your test plan? 

  This leads to questions like

  •   Is there something called test plan in Agile? If so how does it look?
  •   What data needs to captured?
  •   Is it dynamic and open for change in the middle of sprint?  
  •   How is it useful ?

  Kindly share your experience here.

Views: 269

Reply to This

Replies to This Discussion

We have a document we call a test plan. I couldn't tell you if our test plan matches anyone else's test plan because we created this document to match our needs and not someone else's template/expectations.

Quite shortly, our test plan is a model (currently in the form of a mind map) with some text explaining what certain elements in the model mean.

The point of this plan is a document which we can show (and explain) to anyone who requests to see it.

Since it is a mind map, we can alter it as-needed in a couple of minutes at any time without sacrificing the "agile" part of Agile.

Since it is a simple document, we can also use it as a checklist of what we have tested, what we still need to test, and which tests have questions attached (i.e. issues, general questions, strange behaviors which aren't part of requirements, etc...)

As for the data, we include the following:

* List of requirements (useful for the project leader)

* List of things we will definitely test (Useful for the developers)

* List of things we will probably not test and why (Useful for everyone) - This is usually outside of the mindmap portion of the document in a text paragraph or two

For us, more detail than that is unneeded work since it is covered by burn down charts, daily stand up, email interactions, personal interactions, etc...

Sometimes, we add information if we think it is significant to the project, such as if there is a perceived risk which nobody else has brought up before the ideas got to us.

Hi Brian,

    Thank you for the reply. 

    Mind mapping looks interesting. Let me go through on it. 


     What you meant by "List of things we will probably not test and why" when there is a clear Acceptance criteria getting agreed by Product Owner,Developer and QA Engineer? Acceptance criteria explains on what to test which implies that we know what not to test? So does it need to really captured in a separate document called test plan? If so what you see as a value add for that?


Context, risk and communication:

Context: If you already know what is not being tested through other documents, processes or interactions then it is not worth it to you to add it to the plan. In our case it is because...

Risk: In a recent new product, the initial documentation didn't include a key point to our product's life cycle. Since it was a new product, and the tests are annoying as heck to run, we documented that we would not test this point in the initial testing. We had determined that this key point was of low risk, and our time could be better spent in higher risk activities. Since we had documented our plan to not test it, proper feedback could be provided.

Communication: Since other people actually read our simplified versions of documentation (Which was clearly not the case pre-modelling), someone important, who was not involved with the original discussion, raised a hand and asked us, "What about this situation?" (He was not a PO, dev or tester) It turns out that the risk involved with that key point was higher than we expected, and we tested the scenario accordingly. (Good thing too, there were serious issues)

So communicating that we didn't plan on testing something was the important bit. The tool we used for that communication just happened to be our "test plan." You may choose to use other methods (or imply it by not talking about it).

The other thing I use "will not test" for is to communicate that I find this functionality important, even though we didn't discuss it or rejected it in planning meetings and I want everyone else to KNOW that I find it important enough to mention that there may be a risk involved. 

The third thing I use "will not test" for is to let the readers know that we have thought about the feature, but found it a low enough risk to bypass testing or test implicitly by other tests.

According to me, in an agile model, test plan is written and updated for each release.  The agile test plan comprises of different kinds of software testing done in that iteration like test data needs, infrastructure, test environments and test results. Usual test plans in agile includes


1) Testing Scope

2) New functionalities which are being tested

3) Level or Types of testing based on the features complexity

4) Load and Performance Testing

5) Infrastructure Consideration

6 )Mitigation or Risks Plan

7) Resourcing

8) Deliverables and Milestones



© 2017   Created by Rosie Sherry.   Powered by

Badges  |  Report an Issue  |  Terms of Service