Navigating a common language – especially in a global landscape where English is a shared medium – demands precision.
TL;DR: Using the right terminology is crucial!
In the realm of communication, Plato’s emphasis on defining the meanings of our words and establishing terminology resonates profoundly.
Now, in an era where English serves as a universal language, it becomes crucial to recognize the diverse interpretations that words can hold, particularly when not everyone speaks English as their native language.
Imagine the chaos if every meeting began with a marathon session attempting to align our understanding of the words we use – a situation reminiscent of Socratic dialogues where such pursuits were the norm.
This underscores the contemporary significance of standardized terminology, an industry lexicon that serves as a beacon for shared understanding.
But who needs to understand the testing terminology, and what other terminology does a tester need to understand? Is there a giant pool of IT terms which we all who work in this industry need to be familiar with?
Well, as always, let’s try to take a closer look through practice and daily life.
As long as everybody sticks to their area of expertise it is not a big problem that we don’t exactly know what the others mean by this and that, when they are talking only among each other. For example when two developers are talking about the technology they will use in the implementation, it is not always necessary for a tester to understand the concept in full depth. I’d like to emphasize that I’m writing about the moment of talking, and even sort of decision-making where we won’t have a say. However, when it comes to testing we will have already had to educate ourselves on the topic.
And similarly if a test manager is doing the testing, including creating the strategy and the test plans, it is fine if a project manager does not understand which testing level is which.
All of the problems start when people who don’t understand the field, who are not experts, think that they should tell the other party what to do and how to do it. And this happens a lot with testers.
In my experience there are two roles who tend to believe that they know better about how to test: developers and project managers.
I’ve encountered many times when PMs were talking about end-to-end (E2E) testing and Acceptance testing on a level where we needed unit tests, and talking about automation where manual testing was significantly more effective.
This is one problem, when a non-expert thinks he/she knows it better. As the gatekeepers of quality we need to stand up in these situations and make them face the reality: they are talking nonsense. We need to explain to them the real meaning, the real definition of the words they are using. And believe me, we only have to do it a few times. After that they will understand that testing is a profession, and not an activity which could be carried out by people in a completely unrelated field.
But to do this we need to understand our technical jargon, and we have to use it well.
And here we arrive at the next problem: I’ve met a lot of testers throughout my career who used a lot of the terminology wrong, and they were just nodding when the PM was talking about how to do this and that.
Many of us are wondering why testers and horribile dictum testing itself is not taken seriously. Just imagine walking to a bakery where the baker can’t explain the difference between a rye and a wheat bread.
It is our duty (like everybody else’s in any other fields) to always educate ourselves and learn about our profession. I find worldwide certifications (like ISTQB or CSTE) a big help in this matter.
It makes a real difference talking to an ISTQB certified tester and another one who is not. Either we talk the same language, or I have to stop twice in every sentence to explain what static testing is, what the difference between test levels is, or when we do test analysis.
So if you are a tester but you don’t have any certifications, I encourage you to get one ASAP. If you have one, let’s plan the next one. If you need help, contact me or check out my courses, so we can speak the same language.
Until that let us review here a few examples I found in many cases misused:
Test levels
Test levels are different stages of testing connected to different stages of the development itself, with different goals, test types and techniques. This includes unit, unit integration, system, system integration, and user acceptance testing.
Test types
Test types are collections of test techniques aiming to verify and/or validate different aspects of the software. There are many test types, like functional testing, non-functional testing, and black-box testing.
Test techniques
Test techniques are methods helping the tester during test analysis and design in creating the most efficient set of test cases. With using the right test techniques the number of test cases can be reduced, significantly focusing the testing effort. E.g. boundary value analysis, decision-statement testing, exploratory testing.
Static testing
The best way to think about static testing is as a review, where the goal – depending on the review type – can be finding anomalies, creating agreement, or helping to reach a decision. It is important that the test objective (e.g. the reviewed document) is not executed (e.g. if it is a code), it is only reviewed, therefore this testing activity can be also performed in the earliest stages in the software development lifecycle when we only have some documentation, or even just ideas.
The list is of course really unending. If you’re interested in more, join one of my courses. See you soon!