With the Agile process so popular and being followed in most of the organisations, I feel Test Plan creation is being lost. Every project is divided in small user stories and these stories being distributed in each sprint( usually 2 weeks or 3 weeks). Testing features as part of user stories by the end of the sprint is the goal and most of the time testers end up writing the use cases/test cases and sign off.
Test Plan is something which is release oriented and used to be created to plan and ensure end to end testing of the feature. But seems difficult in Agile world.
You ask a very good question; in a way, yes Test Plans are indeed disappearing in Agile. They have gone through evolution with the birth of Agile processes. Initially, based on traditional SDLC models, you used to write an extremely lengthy and cumbersome document that covered the entire release. Now, however, Agile breaks down work into smaller user stories delivered incrementally, thus maybe leaning more towards lightweight planning.
Instead of a formal Test Plan that is heavy and detailed, many teams either place their testing strategy into a test approach document or a Confluence page, or even use the Definition of Done as one. The underlying idea is to ensure coverage and alignment but at a pace that suits Agile. At the release level, some organizations will still create a higher-level Test Plan (mainly when it is a regulatory or enterprise project), although the document is more lightweight and flexible.
From that perspective, it really is still there and present, just leaner; a living document as opposed to a static set of papers. The exact thing gets handled differently by different organizations, depending on their maturity, domain, and compliance needs.
Yes and no in my organization. It depend on the size of the task at hand. Smaller tasks gets done by attending, as a tester, sprint plannings (we also have larger plannings for the whole organisation like 3-4 times per year where I as a tester do take part).
Larger tasks, that indeed do reach the “project” level, we do write test plans, and handle the project as an “oldtime project” even if it is performed in sprints. The role of the test plan is (as it also was before) largest in the early stages of the projekt, even if things like testing stages is well defined in the test plan.
Actually would agree with Anders, yes and no, I believe they are largely depend upon the feature I would say even in fact rather size of the company.
In my current role, we create Test Plans best on the features and its sensitiveness. We make sure most important aspects are covered. I guess its now just depend upon whats works best for the team and the product. But yeah as Agile’s manifesto suggests: People not process, work over comprehensive documentation. Which is good and its seems to be working so teams opting whats working for them which is great!
I see the same problem. When it’s just agile development, features tend to get split up in many smaller units, testing single features. But what about the overall workflows, the big picture? This tends to be forgotten in my experience. So make a test plan with a system/acceptance test, whatever is needed and make it a task for the team.
I definitely create a Test Plan to capture all the Test ideas briefly listing out all the feature/subfeature under test can do , which in turn helps in test coverage
I like to get meetings to discuss a test strategy then plan but rather than some big documents for each feature/epic, I see it as capturing the conversation, identifying testing that wouldn’t get discussed via our usual process and then immediately ensuring it is covered by tickets. Then per story we’re getting into the meat of things, often with a story level test plan.
I guess my point is that the discussions, planning and understanding what we’ll need shouldn’t go away with agile. However the test plan artifact has little value if we’ve captured testing needs in actual tickets.
In my organization we don’t have official test plan document. We maintain it in sheets. One of the reason is shortage of time, being a start-up and fin-tech we have lots of tasks for every person in the team and we already have lots of other documents to maintain for regulatory and compliance specially test cases and evidences for their execution, so test plan is not in out list.
But in my last organization we had test plan and it was being shared with the client.
I recently read MoT article on single page test plan and i really loved it and i’m working on creating something similar for reference.
Interestingly, for us the Test Plan has made a comeback.
So when I had a large team we had about 4 tech QE’s and 8 UX QE’s. We had a lot of work but had the people capability that when products came for release we didn’t need to be that tactical. But I hated the phrase “Full Regression Test” as it implied “nothing to think about, run everything. So I was always encouraging the team gradually to be more tactical.
Now, the team is a lot smaller, obviously the workload has reduced to a degree to compensate for that but if all of our products had releases at the same time, we’d be in trouble. So now, as part of the release planning we will write a test approach document to describe our risk based approach, whats in scope and out of scope, and any other information around the tactics to minimise the time taken. The document is minimal, just enough information to describe the approach so if anything is out of scope people have a chance to voice concerns.
I think everyones release process is down to their customers. I envy those that can release daily and have customers open to minor bugs working alongside the engineering processes as a stakeholder. Our customers are local authorities and governments around the world, their bar is high, so we have to put extra effort into ensuring quality in our releases. To be honest, writing the test approach is another skill that the QE’s are enjoying and is extending their craft of considering a releases contents and establish a balance of effort, quality and timescale.
