ISO Multilingual Testers – How knowing to speak other “languages” leads to better testing.

ISO multilingual tester must be able to translate and interpret business requirements from Project Managers/Business Analysts in order to assist developers in creating software that End Users can use with little fuss and much gratitude.

Do you work with other business units/teams?  Have you gotten acceptance criteria from a Project Manager or Business Analyst and questioned its purpose?  Do you take time to explain to the developers why this certain feature needs to function in this way?  Do you ever have to sit with end users work through the development?  Wouldn’t it be more helpful if a QA/Software Tester’s job ad looked more like the one above?  In this article, we are going to explore the unique experience of speaking multiple “languages” and how that, in turn, leads to an improved testing experience.

Project Manager-ese – This language is part Sales manager, part developer speak and will occasionally include end user speech.   Project manager-ese shares roots with Sales in that the purpose is to sell the business unit and upper management that this particular feature is beneficial to the company and will be completed by the agreed upon time.  Bringing this to the development team runs the risk of things getting lost in translation, i.e. benefits to the company, timeline constraints, etc.  On some occasions, if the development team declares the timeline is too constrictive the project manager does not seem to have a way to translate that to the business unit.  This will cause a large language gap that is hard to bridge.  As a QA, knowing project manager-ese and cultivating the ability to recognize that certain project manager constraints are self-imposed rather than promised to the business unit will go far in the QA being able to work with the development team to create the best possible product within the project manager-ese constraints. This ability to translate helps the QA determine how and which items to test and an approximate timeline needed in order to complete testing.  Translating this back to the Project Manager will get slightly tricky, especially if the testing could push the timeline further than promised.  At this point, the QA should use any sales-ese they have at their disposal to start negotiations with the project manager to ensure that proper testing time will be taken in order to deliver a great quality product for the Project Manager and End User.  By speaking the Project Manager’s language, the QA can ensure good quality in a workable timeline.  In order to get the idea to translate into Project Manager-ese, however, you also have to know how to speak Developer.

Developer-ese – This language is built on highly technical terms, programming language and fandom for their favorite sci-fi/fantasy/etc. stories.  This language can occasionally be overly complicated and hard to follow.  When first learning developer-ese, one must work slowly and consistently.  It is an excellent idea for a QA just starting with developer-ese to utilize many of the resources available to learn technical terms and programming languages.  Getting a baseline knowledge of how the company’s chosen programming language works is helpful.  If you are still having issues, do not hesitate to ask a developer questions.  One finds that, though the speech feels out-of-reach, stopping to ask a developer for help will assist in bridging that knowledge gap.  If you still have trouble starting the conversation, listen to their conversations with other developers about the fandom that they follow.  If you can brush up on your fandom, you can open the door to starting that technical conversation.  Do not be afraid of developers or developer-ese.  Most developers are quite helpful and willing to teach a QA about what they are writing.  Their code is a point of pride and if you can follow it and comment on how well it is doing, or you are able to follow it and point out something they may want to look at, they will become more helpful.  Learning developer-ese will also create a symbiotic relationship where the developer, and other non-developer members of the team will look to you to get their point across to the other side.  So, because you have added both Project Manager and Developer to your language tool box, not only does your job as QA become easier, but you can speak their language to help them understand what you will need and/or expect going further into projects.  There is another language you will need to add to your tool belt as well – End User-ish.

End User-ish – This language is the language of the people.  It gets its roots in sarcasm, expectations and disappointment.  It can be found with the group of people that are the recipients of the software the QA has been testing.  You have spent time thinking like the end user, but there are things they know that you just will not know.  They will speak in terms of their job and how awful the software is to use. You will believe that, after all your hard work, the end user will be impressed and instantly fall in love with what your team has done.  They will not.  Do not be discouraged.  They simply speak this language.  They are unhappy with what they currently have but they are so used to it they do not want to change anything.  You will try everything you have to convince them that this new software is more efficient and will help them improve their work.  They will tell you that you are wrong.  Your next step is to engage them.  Ask them questions as to what they do in a day, how they use the system now, why they think your improvement will not help them.  Agree with them.  They are right; it is different and they do not know how to use it.  Show them.  Get down in the weeds with them and learn from them.  The more you know about the end user’s use of the system, the more of their language you will learn.  They are not trying to be negative on purpose; they feel unheard, left out, unappreciated.  Learn that their language does not mean to pick everything apart; they are just showing you what it is they do and what you are missing.  If you can master end user-ish, you will be able to communicate their needs, wants, uses into your tests and to the rest of the team.  You will be able to translate to the developer that, while they think putting this button over here will be better, it is better to leave that button right where it is because the issue that really needs solving is that modal opened by the button is too small.  You will be able to raise points in the meeting with the Project Manager about how the use will actually use the system.  When it comes time to meet with the end user again, you can use your end user-ish to explain that, in order to fix that modal, the button had to move, too.  There will be an amount of trust created with the end user because you took the time to learn end user-ish.  The rest of the team will appreciate that as well as the fact you took time to learn their languages as well.

Being multilingual as a QA is not about knowing French, German, Spanish, Cantonese, etc, though knowing another language is never a bad thing.  It is about knowing how to interact with your different team members.  It is about being able to tell the developer they did a great job but the end user really wants that button to do something else.  It is being able to tell the end user that the project manager designed that popover modal to look that way because it fits with the rest of the design of the site.  It is being able to communicate to the project manager that the workflow they created works great but the end user really uses the system like this.  It is about learning, communicating and getting the best product out the door, efficiently and on time with as few defects as possible.  Most of all, being multilingual makes you an incredibly beneficial member to have on the team.  My parting advice: do not be afraid to learn a new “language”; it could turn out to be helpful and fun!

Author bio

I am a Quality Analyst for FanThreeSixty, a sports fan engagement software company based in Kansas City.  I am always on the quest to learn something new, be it new testing techniques, how to better edit my photos, or how to raise my children to live up to their dreams.  I live with my husband, 2 children, a cat and a dog near Kansas City.

Feel free to contact me on LinkedIn: https://www.linkedin.com/in/amanda-perkins-bbaa3020

Reviewed by

Russell S. Perkins, M.S., M.A.

Registrar and Director of Institutional Research

University of Saint Mary

Leavenworth, Kansas