Creating a Test Strategy From Scratch


(Heather) #1

I see variations of

I have to create a software testing strategy from scratch. Does anybody have any advice/resources/templates

asked a lot online.

I’ve only ever had to write a draft testing strategy once for an external client. The audience was entirely business people with limited knowledge of what their contracted developers had provided beyond what they could see on the screen. It was a complex system under the hood so I had a lot to digest before ever approaching writing the strategy.

@cassandrahl wrote a great blog post about this late last year

My experience was similar to Cassandra’s in that I knew little to no testing had taken place before I was approached to test this software. My experience differed because there wasn’t a team I could approach easily to get information. Because it was all contractors who billed per hour of their time, I had to be very sure of the questions I needed to ask before I approached anyone.

It showed me that creating a test strategy from scratch really does depend on the situation you are in but there are similarities.

@ezagroba approached it with mind maps

How have you approached creating a software testing strategy? Did you use approaches similar to Cassandra and Elizabeth? Did you try something different?


SWTC Cambridge - Testing in Agile
(Shey) #2

Tips which spring to mind immediately -

  1. Realise that you are writing a document that is unlikely to be read by anyone else but you - sounds flippant, but unfortunately is true with most documentation on a project
    SO…
  2. Use bullet points and quick tables in the document, and keep it as short as possible - the shorter the better, so people will possibly read it, and therefore will feed back to you
  3. Where possible, keep it as a living document - reference working documentation, api swagger docs, code repos, etc.

(Alan) #3

Talking with the domain experts and being frank about what are the worst things that could possibly go wrong? Starting off with heuristics is fine and presenting a product owner or team with your first guesses would be fine. There are some commonalities to all software that is going to carry over for every product. The most super valuable to me as a business owner is if a domain expert points out issues with compliance or risk that does not encapsulate just the risks of software. Sheymouse’s tips are all great keep it visual and light and mindmaps could be a good fit if there are relationships to show.


(João Farias) #4

I’ve found that Bach’s Heuristic Testing Strategy Model leads to well-thought and not extensively long strategies.

The original paper can be found here (5 pages).

I have created a mindmap with each point of the model; you can find it here