How do testers cope with this one especially working with new teams/projects where team members come from many different backgrounds and years of industry experience?
Example - I was in an interview and a developer asked me if I had much experience with Sequel? I sat there thinking what does he mean but then he elaborated talking about the db and the penny dropped where I asked did he mean SQL?.. the rest of the conversation is history. But this has me thinking we use so many different acronyms, slang terminology and even the latest methodology language to say the same thing.
Does anyone out there find this painfully confusing???
Does anyone feel it might be possible to have a standardisation of reference language, which is global, that could become good communication practises within the software development industry?
I agree with you @kimberleyā¦there are test jargons unique to projects/clients,for instance,simple example is test case/test scripts/test modelsā¦I have also faced such situation but even after language has been standardised by Testing boards, people customise as per their wishā¦not sure what can be doneā¦can you imagine not even in testā¦recent in Agile world people have created their own dictionary and using those freely rather than standard agile framework terms ā¦
Totally agree, after writing this I had a very animated conversation with my partner (developer for over 20yrs) and he highlighted my short-sightedness which is true. I find it difficult coming from such a legalistic background of insurance where words = power to more of a collaborative convention where words are interchangeable.
Your right about ISTQB hahaā¦ I have yet to see much of that in action within the organisations I have worked in. Everyone tends to have their own language or as I say ālingoā within the department.
I usually just ask for clarification. There are SO many acronyms or pet terms for things, it is impossible to know them all. If something isnāt clear, asking gives the other person an opportunity to help you out, (people often enjoy sharing what they know).
Sometimes I phrase it like, āOh, I havenāt heard that acronym, what is that?ā Iāve also created my own glossaries and passed it along to new team members.
I think that an attempt to standardise language is a fundamental mistake born of a misunderstanding of the communication and the evolution of language.
I donāt think itās possible, nor desirable, to standardise language, and even if it were weād next be talking about the confusion over competing standards, how to police a standard in the community, how to translate a standard internationally, how to keep the standard up to date with latest trends, and so on.
Standardising language also restricts creativity and process improvement. People think in language and must be permitted to use it in an exploratory manner. When I run workshops on communication one point I try to get across is that people generate their own linguistic shortcuts to communicate a repetitive idea and this evolution is designed to communicate an idea or emotion or plan with greater efficiency without becoming too broad and being misunderstood. Standardisation is the opposite of this process.
I think itās a far greater investment to improve communications than to try to codify something like domain language. The only form of āstandardisationā I could agree with is education about poor language that fails to communicate effectively to certain people in certain situations so that people use the right words at the right time, and use language more responsibly (or are at least aware they might not be).
Seconded so much, @kinofrost! Where I work now, the document thatās called a āUse Caseā is actually a horrific hybrid of use case, functional spec, and technical spec - but it serves its purpose and the people who work with the thing know how to read it. Trying to standardize terms there would just cause confusion.
The best Iāve managed is to get an agreed-on company lexicon so that the people doing the work all know what they mean when they use the work. This does make interviewing there challenging, but Iāve found that if I donāt recognize a specific term, asking for more information will usually get me to where I can say, āOh, I hadnāt come across that particular term for it before.ā Iāve also been quick to point out words that Iāve read but never heard spoken - something any avid reader will encounter but which can make for awkward problems at times and explain you not getting a term because the pronunciation isnāt what you expected it to be.
Part of the reason for this line of questioning came from during an interview I had where a developer asked me how much experience I had with sequel. I totally sat there with this complete blank look on my face until he mentioned the db then the penny dropped. I mentioned this to a couple of my friends a dev & a tester who went āReally???ā but both of them have at least 20 yrs in the industry where I am coming up to my first 5 yrs. I guess its always going to be about open conversations with everyone and not feeling awkward to say āOh, I hadnāt come across that particular term for it beforeā. BTW I am going to implement that response into my memory banks as I think its a great one.
In case it ever comes up (I consider you black belt levels of testing, or I wouldnāt nerd at you, but accept my preemptive apologies), thereās some very nerdworthy text about the relationships between standardisation and communication, and why domain language is useful, and why asking for explanations and examples helps sort out communication problems.
Harry Collins, hallowed be thy name, in Tacit and Explicit Knowledge writes about the difference between language and strings (between human communication and in-principle lossless string transfer like in computers) using the ātransformation-translation distinctionā. He writes that a string (stuff with patterns on it, like sound waves in speech or paper with words written on it) can be transformed into another string and back again without loss of (physical) information - so you can change text into numbers and back via a lookup table for example. Language fundamentally cannot be transformed in this way, only translated with risk of loss of meaning that we cannot necessarily measure.
Human language carries with it a fundamental flaw in communication of meaning because it has to go through an interpretation stage after itās transmitted - when I say something to you I take my meaning, inscribe it on some stuff, give you the stuff, and you have to turn it into something you can access and then pull meaning back out of it, via all your internal models and experiences and emotions. So to reduce information loss in string translation we repeat the string exactly over and over again, like using redundancy against packet loss. When we try to make meaning in transmitted language more clear we use completely different and varied strings - thereās no point in repeating the same thing to get an idea across, I have to explain it in different ways or use varied examples.
So, with that in mind, itās variety in language, born of exploratory performances, that makes communication clearer. Standardisation carries all the problems of individual interpretation that requires more string variation to solve - so you give everyone a standard and they still have to sit around talking about what they mean when they use it anyway. There literally are no absolute linguistic standards, just language affordances - guidelines towards shared ideas. Thatās why people love metaphor - it carries with it a broad affordance of meaning that one can attach to communication, like an information plaque next to a confusing art piece in a museum.
Sorry if that was a bit heavy handed, Iām summarising a very well-written chapter via a couple of paragraphs, an evening whisky and a Coltrane playlist; but if you havenāt gone through Tacit and Explicit Knowledge I canāt recommend it highly enough. Collins changed the game.
Chris I love itā¦ in another universe I could see us discussing testing animatedly over a pint for a hour or two so donāt ever hold back or apologise to me about being passionate. This is awesome stuff
Oh yes - that is a wonderful description of the problem and why the answer is not simply standardized terminology.
If you read Terry Pratchett, some of his commentary on how his translators work falls into much the same area: itās hideously difficult to translate that many layers of meaning in a way that will have the same kind of impact on readers.
Honestly, Iām inclined to think that testing should be considered an art more than a science. (Much the same goes for development for much the same reasons). No two projects are ever the same. There are rarely if ever enough similarities for any form of prediction to be more than a broad heuristic. The skills we use have a scientific basis, but the actual implementation is a matter of judgment and experience - we evaluate the situation, and based on what we can see decide what a viable course of action might be.
Communicating all of that canāt be standardized, even if the basic terminology is set. Thereās still too many variables, too many usable solutions, and no single ābestā answer.
Hi Kim. I have seen this conversation a number of times over the decades.
Some early conversations highlighted that people who have been around a while (seniority) tend to know the acronyms and jargon. So it feels like a way to say, āIām more senior than you, thus my opinion matters more.ā Almost a little passive-aggressive.
Years later I was reading the original text on the cartesian plane (X-Y graphs). It was 3 pages long. A REALLY good example of how a picture is worth 1000 words (or more). I also noticed how advanced math used a lot of jargon. For example, Andrew Wiles paper on Fermatās Last Theorem is 250 pages long but only a dozen people on the planet can read and understand it. To ādumb it downā would probably make the paper tens of thousands of pages. So, sometimes the jargon and acronyms are just to keep it a reasonable length.
The down side come from different groups of people using different jargon to mean the same thing. SQL was originally called Sequel but the term Sequel was copyright by someone else. So they shortened it to SQL. Many people called it sequel because that is what it was called originallyā¦ before they found out Sequel was copyright. Old people will see SQL and say āsequelā, even though we shouldnāt.
Iāve seen people on a team try to create an Acronym/Jargon document but trying to do it across different companies just isnāt going to happen. Iāve worked at Fortune 500 companies where different departments had different acronyms for the same thing and the same acronym for different things.
Additionally, as a consultant I now work for different clients. Each client has its down set of acronyms and jargon. Get everyone to agree on one set just isnāt going to happen. If Iām in retail and you are in airline, you might feel your set of acronyms works for you and REALLY donāt see the business value you aligning with every other company out there. Especially if we arenāt going to converse with each other. It would be great as a consultant if everyone used the same acronyms and jargon but I just donāt see that happening.
My best solution right now is to understand that it is okay everyone on the team comes from different places/backgrounds and will have different acronyms and jargon. Creating a document on what these are for your team/company as part of say an onboarding document would help.
Thank you Darrell for your explanation around the Sequel incident as it did leave me going ??? but it all starts to connect with these discussions were having here. Itās awesome to be able to glean from peoples experiences here that can only be gained from boots on the ground kind of thing.
Looking forward to reading more of your inputs in the future
Google has an internal glossary. If someone mentioned an acronym you werenāt aware of a quick search would usually help enlighten you. If the search didnāt turn up anything it would observe the searches/suggest you put forward a definition.
Damian Synadinos gave an interesting keynote at Australian testing days lately on how words matter (sorry itās not recorded) but he has a related blog post here.
One thing in a new position that I try to establish early on is my intense curiosity and need for clarity. Knowledge is gated by understanding, education, region, and industry. I think with new positions it is easy to fall into the impostor syndrome mode of operations where you attempt to appear like you know more than you might in the initial weeks, to affirm the companies decision to hire you. Even in interviews, I have found asking for clarity is so deeply humbling of an act, that done in the right way can create a level of intimacy between yourself and the who you are asking the question of. This can lead to better working situations and a feeling that even though you may be in charge of quality of the software at any given moment there is no ego involved in the work, just the desire to learn and create quality in relationships and software across the board.
Good point Sam and cheers for the reference material. I guess I was not referring to not understanding the acronym but more when teams or business applies it several different ways dependant on their own experiences etc. What seemed important to take away from everyoneās comments including your own (thank you ) was to try and speak the same language as whatever team/company your in. Definitely keeps us on our toes
ā¦
