What does your test strategy look like?
Is it a document, a mindmap, a drawing on a whiteboard, something else?
What does your test strategy look like?
Is it a document, a mindmap, a drawing on a whiteboard, something else?
A test strategy != test strategy document.
A test strategy is the set of ideas that guide the test design;
The test strategy is hard to explain what is represented like in my head.
I model my test strategies with goals/risks mainly besides others.
The test strategy changes, adapts, it’s enriched, as I learn more things or move between targeted areas (a few times per day).
As for the documentation it can range from:
Recently one of my colleagues asked: “ Do we have any test framework / strategy document that describe the purpose and which type of projects need which testing: Unit testing, Functional testing, Data Handling testing, Integrity testing,” … +16 other testing activities.
The test strategy, to me, is which of the 16+ you choose. Plus it also needs to answer:
Recently I’ve been exploring: What is the value for the decision maker for each part of the test strategy? Perhaps a Wardley map can help me?
In the end I usually summarize the strategy in a document, and will include a drawing or two.
I’m not sure I understand the point:
The test strategy is to you the selection of test techniques?
Why would you limit your testing to the techniques before having detected the risks and getting some test ideas?
hi Stefan,
Sorry if I was being unclear. I was trying to describe what a test strategy looks like, to me.
to me the test strategy looks at the bigger picture - based on the business drivers, which test activities should we have - in the first place… risk and time-to-market are just two drivers, there might be more. Then the test case design strategy, test automation strategy, requirement coverage strategy, test technique comes next.
My strategy at present is a mindmap for my own use while I put it in a format (series of confluence pages) which I feel comfortable sharing and discussing
This is an interesting prompt.
I started a brief collab with an old colleague to try and come up with a template that we could agree on and always run with.
In all honesty, it always comes down to context.
If I can avoid using a document that no one will really ever read, then I will do. I like to reference things like the Heuristic Testing Strategy Model by Bolton, Bach et al, as well as things like the Agile Testing Quadrants from Lisa Crispin…lots of whiteboarding and or mindmapping as with @sjprior
Whatever is manifested from these conversations on approach will need to be a ‘living document’ that can be adaptable and housed where the team can all see.
While I’m not the world’s greatest Atlassian fan, I have used their suite in most places, so just have it living in Confluence with a direct link on the JIRA board.
A dogs breakfast.
Can I say that here? Well that’s not entirely true, but that’s what it looks to me at times. Due to product size, the automation dashboard together with the support team ticket resolve times, rapidly becomes the only source of truth.