The "Working software over comprehensive documentation" agile value is one of the most controversial.

Regarding testing, how do agile test team achieve "Just Barely Good Enough Models and Documents"? What factors affect the documentation of testing and what should I do to work effectively with clients and sponsors to produce the minimum documentation of testing?

  • i have reworded this question, can you please check and re-open. – Keshav Dec 29 '16 at 4:19

Your question is not entirely clear, so that I have to make a few assumptions.

When do we start test planning?

  • Test planning should start as soon as development starts, e.g. when business analysts sit down with developers to discuss how to meet customer's needs, testers should be there.
  • But, in a real world, this does not always work, in practice, testers should be pro-active; even if you are not invited to such a meeting, you should actively put your hands up to join in.

Test planning documents

  • It depends on the size of the system under test, if it is a one shot and really short testing project, there may not be necessary to create a formal test planning documents.

  • Test planning documents basically serve as a road map showing how the tests are to be carried out and when they are carried out, who is responsible to what and etc. If there is a need of having one, it should be produced as soon as possible and frequently reviewed.

Are there any advantages of it in Agile?

  • I do not understand this statement, did you mean "are there any advantages of having test plans?" OR did you mean "are there any advantages of having test plans in Agile style?"

  • In general, test planning is useful and almost always is required by management. Ideally, testing and development are carried out in parallel, so if the development is using Agile practices, testing should be in Agile as well. Again, the outcome largely depends on how well you implement Agile. I have seen companies implementing a Agile "shell", e.g. they thought they implemented Agile, but only on the surface level, and they failed and blames Agile for their failures.

| improve this answer | |
  • for advantages part, i agree with the statement "almost always is required by management". Because right now its not required by my management, But in our process we had written that we need to create one. that's why i had this question. – Keshav Dec 23 '16 at 9:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.