Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am currently working in a small agile team and I am trying to decide if a test plan is worth creating or if it is then what to include. Currently working on a story that I believe could do with some documentation to use as a guide and keep track of what is tested.

I am unable to just create a script and follow that due to the nature of the story.

share|improve this question
up vote 4 down vote accepted

A test plan is worth creating if there is something that needs documented testing. It may be frustrating to see a test plan with only a few steps, but if you realize the purpose of the necessity of documentation, it doesn't matter how small the test plan is.

You should include whatever it is that needs testing. Whether it's an anticipated UI response to interaction or a back-end component that gets updated, if it needs to be verified that an action occurred or did not occur, it should be included in the test plan.

I work in an agile environment, and sometimes it requires test plans to be updated due to design changes. In an agile environment, that comes with the definition of the strategy. Just be sure to stay on top of changes that need to be made.

share|improve this answer
    
This pretty much nails it. There are tons of possibilities for what may or may not require a plan. If you need to document part (or all) of your tests, a plan great place to keep it. This way it can be easily passed around the team to add scenarios/stories to it. – maznika Oct 4 '12 at 23:34

Welcome to SQA, Teague. Your test plan is part of a feedback loop. You convey something about the project to whoever is testing. They test the project, find some problems, and fail to find others. You incorporate what you observed into how you write your next test plan. It is all about paying attention and being open to changing what you do according to the circumstances.

You probably have a hunch for the right depth for a test plan. Start there, then try what I just described.

share|improve this answer

A good test plan doesn't necessarily enumerate everything that will be in the final release of a product. More importantly, a good test plan defines the scope of the feature and most definitely can account for whatever uncertainty you may have.

Also keep in mind that test plans are like software in that they are much easier to extend when they have a solid framework early on. Making test plans in agile sometimes only results in a single, pared down iteration and sometimes they get many iterations with lots of parts.

The best question for you to answer is what would be useful for your team in the short/medium/long term based on what you know and don't know right now.

share|improve this answer

In an Agile environment think of a test plan less in terms of a formal document and more as

a conversation

that sometimes will result in documentation, sometimes detailed, sometimes none. The key thing is to go over logic, conditions, exceptions and the like with the developer(s) before they start coding to both determine how to test the change and also to think of what other consequences should be considered. This is the best point in an Agile environment to add value as a QA person.

The earlier you can add such input the easier and the less it will cost the company in rework and bad data. It's more effective to build in quality than to have to criticize and retro-fit afterwards.

This can require Quality Engineers to be more engaged and proactive than in traditional waterfall environments.

If the feature or change is anything more than trivial and you or another will be testing the change in the future under various conditions expecting certain results to see how it works you will want to document any key points uncovered in the conversation for testing in a test plan.

Test plans developed in this way fit in well with the core Agile principles:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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