Like with a lot of terms in software testing, people tend to use these terms interchangeably and differently based on their context. The key thing is to understand the context you need and learn how to share that as a part of what you’re doing.
A need for describing how we will approach testing at an organisational level to build a quality of culture.
A need to describe the who/what/where/when/how of testing on a project.
It can feel frustrating that we don’t have standard and universal names for these things. My advice is: use what works with the people around you. If your org uses the term test plan then use that, if they call it an approach then use that. The main thing is that we get to share understanding about how we’re going to test
I just wrote up my Test Strategy today. I’ve been in this job as a dedicated tester for 5 months and had not written down what the team has agreed to in one place yet. I finally boiled it down to 6 points. But first I need to give some context: I’m the first dedicated/permanent test resource, test have always been done by customers by virtue of the scale of integration needs, or by developers having to build fragile and complex jigs. There are essentially 5 products and very product has a huge learning curve. So I have a lot of runway and a lot of green open field, and a lot of areas I just have to ignore initially. So these might not fit everyone.
Do not attempt to test everything, focus on priority components and product features first
Learn how an individual product functions and create simple automated checks as well as testing “tools”
Turn the checks into tests that run in CI/CD
Share tools or learnings back out to the eng. teams and to customers
Unearth new test cases, previously ignored features and any old tests that can be re-used
