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.
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.
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.
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.
In an Agile environment think of a test plan less in terms of a formal document and more as
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:
