Tuesday, 31 May 2011

Use Real Words to Communicate, Not Testing Phrases

I think people use ‘standard’ testing phrases too much. e.g.
  • System Testing
  • Testing
  • Performance Testing
  • Functional Testing
  • Non-functional Testing
  • Black box testing
  • Unit Testing
  • etc. etc.
The user of each phrase holding the assumption that the reader/listener of each phrase understands the phrase the same way as the user. They don’t, they have their own models that underpin that phrase.
Try using real words.
One recent example from the world in which I inhabit:
  • I could have said “we need to build automated integration tests for these stubs”.
  • Instead I said “we need write some automated scripts which check that our stub behaves the same way as the system we have stubbed”.
  • I received the answer. “Ah, I call those , <xyz> tests” (I forget the actual words of the <xyz> label)
  • I said “Fine, let’s write some <xyz> tests”
Now we have a label, for the concept. And more importantly we have agreement on what we intend to do.
I used real words to communicate.
You can do this for all aspects of your testing, resulting in contextual communication of your test planning process:
  • performance  testing might become “check that the user can use the logged-in page in under X milliseconds after logging in”
  • load testing might become “check that the server (web and app) don’t show any signs of stress under the estimate load of the first two hours after launch (we’ll monitor it on the server side”
  • any testing phrase” might become “some other set of words in your language of choice that communicates what you mean”
Feel free to inform your planning process, if you must, with concepts such as “performance testing” or “load testing” or <insert any other testing phrase here>. But do not use them to communicate.
I think that eventually you will wean yourself off those testing concepts and start to work from first principles and communicate in simpler, non-buzzword and less ambiguous terms.
I recommend you try it:
  • to communicate your test planning.
  • when asking questions on LinkedIn.
  • when thinking.
  • just try it.

3 comments:

  1. My favorite in that list is definitely "Integration Tests". I learned over the course of the last half year that there are different understandings of the term "Integration Test". Whenever I hear that term, I ask for clarification.

    In my classes I use an exercise to come up with testing terms, and map them on a grid. I almost always have to ask for clarification on certain terms there. Thanks for bringing this up as well.

    ReplyDelete
  2. Alan Richardson31 May 2011 at 03:33

    Thanks for leaving a comment Markus. Glad to hear of other people going below the surface of the words.

    ReplyDelete
  3. Leslie Crandall8 June 2011 at 08:59

    Yup, I can concur that using standard testing terms has bitten me on more than one occasion as I gain more experience working as an embedded tester.

    Integration tests always gets misinterpreted. So does unit test, for some reason.

    I like Markus' mapping idea. I usually have good luck when working with a developer if I explain the behavior I want to validate instead of saying "I want to create an integration test that does ."

    ReplyDelete