As a keen writer and communications fan I spend a lot of time looking at how I (or we) can improve our communication and one of the best techniques is to remove the bits of communication that people skip.
In the world of writing this means removing the sentences, words or entire chapters that you *think* or *know* people will skip. With my own writing this is a very subjective process. I don’t know which bits to remove but I do know I self edit my work quite heavily.
It’s like using twitter. It’s amazing how you can still get your point across in a few characters. It’s a good practice to get in to. Brevity of writing is a good thing.
Much of my writing gets drastically chopped down but no doubt there are still huge amounts of it that are what I call “fluff”.
And it’s important to realise that this idea of fine tuning can be incredibly valuable in our testing world too.
Let’s take a test case. One of the typical ones with plenty of steps and lots of detail. This is not uncommon, there are loads of teams still using highly scripted tests. In fact, I’d go so far as to say it’s the “norm”
There are several audiences for these test cases and if you are dishing these out to people simply ticking the boxes then the more detail the better. The fact that this approach is insane, wasteful and insulting to these testers is something best left to another blog post.
But give your scripted tests to a software tester and observe. Ask them for feedback too on the overall effectiveness of the test case. Here is what I believe you will find:
- They will not follow the test case step by step
- They will read the whole test case in advance to get the gist of it, to formulate an idea about the intentions of the test case
- They will often make extra notes or areas to concentrate/focus on
- They will often re-read this test case a few times to truly understand the intentions or expectations and to double check any missing prerequisites or knowledge
- They will draw on all of their domain knowledge and experience
- They will perform the testing but not as a step by step process. Instead they will tend to complete the whole test and revisit the test case to tick all of the boxes after, just to check they got everything asked for in the right way.
- They will probably explore or diverge slightly from the test, but no so far that they don’t fulfill the intentions
- They will mark the test case with edits, suggestions, ideas and improvements.
- They will probably suggest several new test ideas too
- They will note down observations which in turn often get fedback to the test case
- But most importantly they will not be guided by a step by step process
These are just my own observations but I encourage you to study your own work and that of your colleagues. I suspect you will see the same thing.
And here’s the point. Don’t include the unneccessary, the verbose, the irrelevant, the obvious, the waste or the *skipped* detail. In ommiting this “fluff” you will probably end up with what I call “Guidance Level Tests” (it’s an old post on my old blog but the sentiment remains the same).
If testers are skipping sentences, ideas or sections because they are not needed or irrelevant or verbose – get rid of them. In the end you’ll end up with a checklist to guide, not a document to steer. And this moves the thinking to the tester running the test. And this is a powerful thing.