What can someone new to testing expect from a modern approach to test planning?
Think about this in an Agile context. How is a Waterfall test planning approach different from Agile where perhaps a team is running Scrum or Kanban?
How do modern testing principles impact the role and value of test planning?
Can you share a couple of real examples of when you moved from one test planning approach to another? What happened and how did you navigate the differences? How did it help or hinder?
Hello @simon_tomes ,
Below is my point of view
When someone new to testing dives into a modern approach to test planning, the first big shift theyโll notice is flexibility.
In traditional Waterfall methodologies, test planning is typically rigid, highly detailed, and done upfront. This approach assumes requirements wonโt change much, so you can create a detailed test plan that spans the entire project.
However, in Agile, where teams use frameworks like Scrum or Kanban, the process is much more adaptive and iterative.
Modern test planning is much more point in time, lightweight and pragmatic than historic test planning in traditional waterfall environments. Where you might expect to be able to come up with a detailed plan for what and how youโll test things, in many Agile teams we usually have to focus less on planning and more on executing / getting things done.
Here are some of the differences that Iโve seen over 17 years moving from very Waterfall style testing into Agile teams:
Waterfall
Agile
Plans focus on what we test
Plans focused on how we test
Dedicated to a specific phase
Generally more holistic / across the lifecycle
Test everything
Test what we can
Estimated
Timeboxed
Planned Entry & Exit to test
More flexibility of Ready & Done
Test specialist focused plan
Whole team focused plan
Plan first then execute
Planning and execution simultaneously
Testing functionality
Testing everything from code to non functionals
The main difference now to when I approach planning as a tester is trying to think how we can make more time for ourselves to get things done.
Rather than lots of test design, we explore and focus on execution.
Rather than manually test, we automate where we can.
Rather than aim for perfection, we pragmatically ask โwhatโs good enoughโ.