I think people use ‘standard’ testing phrases too much. e.g.
- System 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 ,
tests” (I forget the actual words of the label)
- I said “Fine, let’s write some
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.