- System Testing
- Performance Testing
- Functional Testing
- Non-functional Testing
- Black box testing
- Unit Testing
- etc. etc.
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”
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”
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.