At TestBash Autumn, our fantastic Stage Mom @ministryofmischief invited on screen the one and only @utchbe for an Ask Me Anything session about Test Strategies.
And as it happens, time wasn’t enough to go through all the questions. One of the questions we didn’t get to was:
What’s the difference between a testing strategy and a testing plan?
What do you think?
When I think about a test strategy this is a general approach to how you tend to handle testing problems. Typically the strategy isn’t going to change. When I think about a test plan I think about how I approach testing a specific area of the system, which could be a project, a sprint, a day, or even a few hours.
For example, a strategy could be: You will often find an SDET in product discussion meetings, planning meetings, code reviews, and asking questions for the system that is being tested. Their goal is to find as many bugs before any code is written. It is also expected that the SDET will be responsible for building and maintaining the E2E (DOM to Database) regression tests which give us confidence with our releases. The expectation is 50% automation/coding tasks and 50% of the SDETs time will be spent doing exploratory testing.
While a test plan could be: For the features this sprint, the SDET will plan to spend 25% of his/her time focused on exploratory testing efforts in that this is an area that the SDET is familiar with, and spend 75% of his/her time this week focused on building out additional automation E2E scenarios as we have low coverage in this area of the system, and during this sprint, the development in this area of the system is wrapping up. (typically I don’t like adding a lot of E2E tests when the system is still changing a lot, so our plan is to add the coverage now that the product is stable, and there shouldn’t be a lot of changes in system behavior). The plan could go even deeper in describing what areas we plan to add automation and what areas we plan to explore the system.