Are we talking about the same thing?
I’ve always found it fascinating how people can use the same words but be referring to something entirely different. There seems to be a tendency for people to attach different meanings to concepts, words and ideas based on their previous experience to these things.
On a personal level, before our daughter came along “a s*** sleep” used to refer to 5-6 hours of sleep. Nowadays 5-6 hours of sleep sounds amazing and “a s*** sleep” refers to 3-4 hours (or less!). The experience of having a child brought a whole new meaning as to how bad sleep can get.
On a professional level, I see people use the same words as me, but have entirely different understandings of how I view the same concepts; words and ideas. That’s not to say that one of us is wrong or right - but I think it’s important to realise when we are talking about the same thing and when we are not.
I’ve been part of interviews for people to join as developers where one of the questions centres around “Agile”. But I find it helps to dig deeper here and ask the candidates to expand on their work environment in “Agile” projects. Here I want to see if it corresponds to our company’s understanding of what “Agile” is. Such a simple word can be interpreted in many different ways. I’ve seen people claim they have worked in an Agile environment since:
- They do daily stand-ups
- They don’t do any documentation
- They were told they are working Agile
From a testing perspective, the idea of Are we talking about the same thing? becomes a whole lot more fun.
Here are some examples of how I have seen things and how others have seen things
How others have seen things
- Exploratory testing is ad hoc testing where you don’t do any documentation
- Test documentation is test cases, test plans and test strategies
- Bugs can only be written against written requirements
How I have seen things
- Exploratory testing is structured testing based on Session Based Test Management
- Test documentation is written documentation of what you plan to test, how you plan to test and what you have tested - this can be test cases, test plans and test strategies, but there are other ways of presenting this information
- Bugs can be written against oracles, including written requirements - which determines if the behaviour you are seeing is desired or not.
I need to remind myself time and time again that since people can use the same words to refer to entirely different things, I need to check to see if we are indeed referring to the same thing. This, of course, means I have probably seemed dumber than I am to my colleagues and people I have interviewed - but let’s be honest, isn’t it even more stupid to assume and then inevitably later turn out to be wrong?
Some useful questions I have found to check if we are referring to the same thing include:
- What do you mean by XXXXXXXXX?
- How did you implement XXXXXXXX?
- What did you find most beneficial about XXXXXXX?
The key part here is that you are not trying to determine what something means, but what does something mean to you? And what does something mean to someone else?
In my opinion, there isn’t much value in having/knowing the correct definition of something if nobody else has the same understanding.
It is, however, important to know when those understandings align, and even more so - when they don’t.