I am writing an STP document for a “library” program.
One of the tested functions is denying deletion of an already borrowed book.
How extensive should I be when describing how I am going to test this function in the STP doc?
What should I leave for the STD doc?
I may ask this with a specific example, but please refer to general case as well - When it comes to “how to test”, what I elaborate in the STP, what I leave for the STD?
Thanks!
You can have a plan without a document.
Who do you write the document for?
What is STD? googling it returns info on the medical issue.
Start from the mission of testing, consider the audience you write it for. Find the briefest way to express your plan on testing the thing: logistics + strategy; One page is fine.
Only you know your context. Some things that you might include: who does the testing, who owns it, who are the helpers if there are any, who do you report to and in what format, where do you report the bugs found, how do you organize the testing(mention the methodology/approach); which platform do you use, what tools/resources are available, product/version/s in scope, deadline or milestones, a few phrases on the set of ideas that would guide your test design.
I remember my team debating the titles of the automation folk in the test group.
We ruled out Software Testing Developers quite quickly.
Welcome to the community @liormof . My opinion, is to play it by ear.
I sometimes threaten to write 2 documents, a test plan AND a test strategy. But what you are describing is not a plan, but a test CASE, which is in your STD (I assume you mean Software Test Description?)
At a high level my “plan” will describe what hardware I will want to use, and if anything is missing I take actions to acquire it. The plan lays out duration and resourcing and where bugs will be filed for example. I list tools and people mainly in my test plan.
At that same high level is my Test Strategy, which will describe which areas I will cover, not “areas” can mean different things to different people, and specific techniques, not tools. I will go into what risks I see, and how I’m going to mitigate them.
Usually I only write one of these 2 documents, or I roll them into one, but explicitly state when I do so that I’m just saving paper if “plan” is unchanged from last time.
As for test cases, I think you have to sometimes decide after a test fails if it is a test case. It’s easy to get stuck deciding if an “implicit” requirement is worth a test case. That’s a good place to waste time often as most implicit test cases pass 99% of the time and hardly ever regress, so it can be a waste of time to run them for every release. I write 50% of my test cases beforehand and 50% after I explore and learn about implicit and corner cases that really matter because I had to raise bugs from what I found.
Are you using a test case management tool?
Hi! Thanks for the reply. I have just started using JIRA, I’m barely familiar with this platform, the only thing I use it for now is reporting bugs. Could you recommend please other functions that this program offers?
Jira supports plugins, which are in some ways a way for Atlassian to sell you more stuff, but depending on if your Jira instance is hosted by you or in cloud, the costs vary to add a plugin. Everyone hates Jira, that’s no secret, but it’s like Excel for workflows and ticketing, so learning how to mine it’s data for your own good is a skill every tester eventually has to master. So don’t avoid learning about other things Jira can do for you 
We use a testcase management plugin for Jira and although it’s expensive, I love it.
I hope you weren’t Googling for “STD” from a work computer…
I like to keep test plans as light as possible. In my opinion the value that they offer tends to be in the act of having to come up with a test plan and think about things, rather than the document itself.
I’ll admit that I can conflate test plans and strategies. But as a rule, whenever I’m writing that is higher level than specific test cases (not that I write them if I can avoid it), I like to get people working on the product/feature/epic/story in a meeting, use a Mural with a template of sticky notes to answer then we chat about what needs doing, what we’ll need and the risks. We then copy-paste that into Jira because my org wants to see test documents, even if they don’t care to read test documents.
If you have stakeholders who need/want to see a test plan, I’d ask them what they need then include only that and what I/the team needs.