As I see this words having different meanings in different contexts, I suggest you to ask your people what they intended to do with them. Your context matters first.
I cannot really differ them too and see no good universal definition.
In my experience is a test strategy often something on project level, a long-term thing. It covers such things like āwhy and how should be tested what in general?ā . What tools you intended to use etc. . This might be changed over the course of project by the things you experience.
But I have test strategies also seen related to issues. āHow do we think we test topic X best?ā
A test plan is is my experience often about of what to test in time frame X. A list of features and properties which should be covered (why, and which not). I use it often related to issues, but also to something like regression testing a release.
It can vary in size in depth and evolve over time while testing.
And donāt mix the activity, planing, with the artifact, plan.
Not filling a document is the important part, but making a plan. No matter how it is stored.
When the strategy tells what approaches of testing you will use, the test plan tells you what you cover by them. This can be applied to different scopes and time frames.
But also this words are sometimes used interchangeably.
If you havenāt yet, diving into your user statistics is a great way to determine your test strategy. For instance, I donāt test on some browsers because only 1% of our user base uses one of the browsers available. Our client-facing documents detail which browsers to use. So, I only test the functionality in the browsers recommended.
Kat Obring also dives into the topic of test plan vs. test strategy. I highly recommend her resources to learn more about what might be beneficial for you.
Test strategy basically refers to the strategy the testing team will adopt while testing the feature/module/components.
For e.g., if itās an application, then how the testing team will approach the testing of the application, what testing process will be followed manually or automation, and if automation then which types of tools and framework will be chosen, what testing to be covered like regression, functional, ui/ux testing, etc.
Whereas the test plan is the official document that contains all the details about the testing process that the testing team will follow, like the ticket details, time, environment, device, what to be tested and what not to be tested, exit criteria, and entry criteria, testing team details, etc.
Lastly test plan is always documented and most of the time it is documented by the testing team lead where whereas the test strategy is in verbal form and it is not always necessary that it will documented and it can be documented by anyone.
Also, a test strategy is high-level testing detail on how the application will be tested whereas a test plan contains the test planning in detail.
Its one of those questions that everybody is wrong and right!
To go dead simple, I define it as a Test Strategy is how we test a product, a test plan is how and when we will test a specific product release. Use a meaning that works for your situationā¦no-one in my organisation complained I was wrong and they understood it, so job done
Hi @the_testing_game
Not to add to the confusion on how context matters. But I would have to agree with @ghawkes that itās one of those topic everyone is wrong and right about and that is probably because we all approach it ever so differently.
A few months ago, I shared some thoughts on Test Strategy in the below article. You can take a look and see if you find any of it useful.
I donāt know if you have access to ISO29119 (software testing standard). If you do, Schedule 3 of the standard describes the key information captured in various testing docs including test strategies, test plans, defect reports to name the key ones. Itās a really useful reference that ensures you adhere to a recognised industry standard.
Hereās a brief summary of the definitions in the ISO.
Test Strategy
A Test Strategy is a high-level document that outlines the overall testing approach and objectives for a project or programme. It includes:
Testing objectives: Goals and outcomes expected from testing.
Testing scope: Boundaries and extent of testing activities.
Testing resources: Human, hardware, and software resources required.
Testing schedule: Timeline and milestones for testing activities.
Risk management:Identification, assessment, and mitigation of risks.
Entry and exit criteria: Conditions for starting and concluding testing.
Test Plan
A Test Plan is a detailed document that specifies the test objectives, resources, schedule, and scope for a particular testing phase or activity. It includes:
Test objectives: Specific goals for the test phase.
Test scope: Detailed description of what will and will not be tested.
Test resources: Specific resources allocated for the test phase.
Test schedule: Detailed timeline for test activities.
Test deliverables: Documents and artifacts to be produced.
Test environment: Hardware, software, and network configurations.
Test data: Specific data sets required for testing.
Test cases: Specific scenarios to be executed.
They can also be combined to contain all the above if a plan for each phase is excessive. In this case you should detail each phase and what is expected in terms of entry, exit criteria, environment, key resources etc.
And good to gain insight from the replies on this topic.
Hereās my take:
A Test Strategy sets out a high-level testing approach to a particular thing such as a project, team, product and more. My go-to for a Test Strategy is to lay out an approach under these headings: Why/What/Where/When/Who/How.
A Test Plan is a low-level detailed artefact focusing on specific elements of a project, team, product and more. This could include defining risks, unanswered questions, items in and out of scope, high-level test ideas, areas of focus.
I echo the good replies to this, a test strategy for me is an overall plan for how I am going to test a piece of software whereas a test plan is more for how I will test a specific feature or attribute.
I believe you can easily find some formal/official/common definitions and content explanations for those artifacts (people shared a lot of such stuff in the comment above) on the internet or by asking AI. There might even be some significant conflict between them.
Your context is crucial, is it just some kind of theoretical research in formal QA definitions of some terms? Do you really need both of them? Personally, I often donāt think about such nuances, I need to do some work, achieve some results, introduce some improvements, etc - this is the main goal, I just do it in a way that will work for my situation, company, team, that will be efficient and easy to use and understand for others. I can mix several artifacts in one, including some retrospective issues + long- and short-term strategies, etc, and call it a high-level strategic QA vision or so (and Iāve done this). The most important here is that itās working, if you understand what youāre doing, why and your goals so I believe you donāt need to spend time just to follow some controversial āformalā terms definitions to succeed.
Iāve seen how people call e2e user flow test scenarios with multiple checks by a Test Plan or when half-baked timeline QA effort planning was called a QA strategy, and similar weird stuff So my point is that sometimes itās better to focus on the results in your particular situation and the content instead of following āformalā guides
I usually end up in horrible sports analogies when I try and differentiate strategy from plan.
My suggestion is start by coming up with a quality goal; in my sports analogy that might be āwin the leagueā or āavoid relegation,ā and in software maybe āminimise defect found in production and the time taken to deliver a fixā or āthe user experience should be reassuringly slick and professional.ā
You can then ask, how are we going to achieve that target? For sports it could be āfocus on attacking playā or ārock solid defenceā. I think in testing this means you choose which activities the test team will spend their time on; maybe youāre only allowing 20% of tester time to be spent on automation, or the reverse, maybe automation is the focus and that your automated tests will never be more than one sprint behind development. Or youāre not going to do extensive performance testing because youāve got a lot of monitoring in production and itās easy to scale up when needed. That might lead you on to other decisions (Testers arenāt doing to do activity X because we team Y are going to handle it, or āWe need an easy way of deploying test environmentsā.)
Write down your decisions and assumptions and make sure the whole team (product as well as dev and test) know about them. (And perhaps that audience is another difference between strategy and plan: I think the strategy will have a broader audience.)
The test plan is more detailed and specific to a particular feature, just as the development plan for each player on a sports team would be different.
For me, test strategy is more about general approaches, considerations, important quality aspects, etc., which can be applied at large. A test plan is more specific and usually attached to a specific release or goal.
In some settings, strategy is more like the what, and the plan is more like the how. In my experience, a strategy is an ongiong effort which can be improved and enhanced. A plan can be executed, and has a defined end.
I think audience, and itās purpose is important to know before assigning them definitions and making them align to your businesses overall strategy, What actionable items should these generate?
More specifically to your question though, for us we just created a standard around both of these and made them very separate things so they can align with our overall strategy.
Test Strategy this is mostly a high level document explaining the approach which could include, environments, UAT processes, special requirements/permissions, what data clean up looks like, what tooling is available, what general gaps/risks exist, what does regression look like.
Test Plan this is the sprint to sprint, or feature to feature tests. This is where we get granular where we talk about the work items and how they need to be handled. āFor this feature, I have 10 things I need to test. Hereās where weāre going to automate and hereās where we are going to manually test, hereās how Iām going to test these specific items, and the associated risks to the specific featureā
Disclaimer: This is just my own head canon definitions
I always thought of a Test Strategy as something I leave for the person who is filling in for me when I leave on vacation. These are the number of cats I have, this is what they eat, water these plants, watch out for this neighbor.
A Test Plan is the plan they then execute to do those things on a particular day.
Iāve worked on projects that, due to size or circumstance, it wasnāt really useful to separate them. If Iām doing a prod support item that is quick and relatively small, I donāt need to develop a test strategy (but maybe I refer to a higher level one that already exists for that system). I guess in that case, Iām the cat sitter.
The fact that this question is being asked, is the beginning of clear communication, and thatās a huge positive. For me, strategy is what you can share with someone in the elevator on the way to your floor, while plan is all about time scale/resourcing.
Although there are blurring lines, I often will write just one of these per release. I will create both if there is a big feature coming, to keep the strategy and ideas separate from the plan of execution.