Less is more

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.

8 thoughts on “Less is more

  1. Test Cases are not written that way to be helpful, but to provide deluded confidence in the testing.

  2. Yeah, there’s a balance between detail anarchy, and efficient use of time while testing.

  3. Rob you have it spot on the money here, not just in terms of test cases but any form of writing regarding testing, be that a blog, book, or a strategy. Down with the fluff! I still firmly believe in test cases being written the have many uses, but only if they are lean. Thanks for another excellent post

  4. Hi peeps,Thanks for all of the comments.@Anne Marie – absolutely. Missed that angle of what test cases can represent.@ Veretax – Thanks for the comment. Indeed. A fine lin that is often crossed.@ Darren – Thanks for the kind words. Down the fluff. I like it.

  5. I think that you are spot on for a certain group of testers, probably the ones that one would consider good and/or experienced testers.I do think though that testers who are new at testing or don’t have in depth knowledge about the AUT/SUT can really be helped with a detailed step-by-step testscript.They can either learn that those details matter and they can easily reread previous steps to comprehend the situation that they are faced with after completing it.It might be an idea to create a testscript in which you can ‘hide’ details that become obvious after getting some experience with the subject so that expreinced testers can still follow the script but are not ‘bothered’ with details

  6. Hi emile,Excellent suggestion and I’ve seen people doing this at various companies. the problems of maintenance and clearly identifying which section is relevant will still cause some headaches but I’ve seen teams with this style of test working very well indeed.I do think guidance scripts can be very valuable for new starters, but in my experience there is no substitute for exploring and playing with the system. It is what I encourage all new staff to do – explore and find out what it does by playing :)thanks for the comment.Rob..

  7. Hi Jesper,Thanks for the comment. Nice post and I like that quote. CheersRob..

Comments are closed.