It’s often the way that people get hung up on the names of testing artefacts, instead of focusing on what they CONTAIN. Yes, naming conventions are important for anything in your testing / quality system, but they’re not the be all and end all.
Let’s be clear, content is king, the quality of the information an artefact contains and communicates is more important than the name you give it. That isn’t to say we should be naming a Test Plan something that no-one would guess is a Test Plan. But… if you call it a Test Plan or Test Approach, there really isn’t much difference… or is there?
Well, actually to some degree there is, but there’s another aspect to consider. That is what the artefacts are FOR and that comes back to what they contain. You were expecting that though right?
For example, the most common document you’d expect a software tester to be walking around with is the Test Plan. Now that might be a Functional or System or Security or Performance or… Test Plan, but it’s still a Plan. It’s not a Test Schedule, it’s not a departmental procedure and it’s not a workstream or programme Test Strategy. That’s what I mean about hierarchy and how we recognise different documents by their content and not the name (kind of…).
In my world of software testing process and practice we have:
· Procedures > Strategy > Test Plan
I don’t bother with Master Test Plan usually, but if you had a big enough project it could be useful.
So what’s the difference?
A Procedure applies to the entire testing department, it’s focused on overall working processes that apply no matter what the project or workstream, product or technology being tested. Doing a data migration testing project from Oracle to Microsoft? How about a web site deployment where you’re doing the performance testing? No difference, the Procedure relating to the management of defects and associated Triage process (for example) will apply to them all.
A Strategy is a level down, this would describe the high level strategy to testing a work-stream or product perhaps. This will contain all that stuff you keep cut and pasting into your Test Plans or that you leave as ‘template text’ in your Test Plan. You know the stuff that makes it 30 pages long, yes… I’ve seen your Test Plans.
Test Plans are a level down again and should contain ONLY what is specific to the particular release. That means items like exactly what defects fixes this release addresses, just what’s changed in this release, some quirky variation from the general Test Strategy. Then your Test Plan can be less than 10 pages long.
Thoughts? Send a message!