QA Analyst, Software Tester, UAT Test Analyst, Test Engineer, and any combination thereof.
The number of software test job titles I’ve held since 2007 is equal to the number of jobs. It’s no wonder there’s still an industry-wide shoulder shrug when asked what a tester does.
Even among software testers the job description is vague. Testing is not taught as a discipline. You can’t get a major in software testing. As a result, testers learn what it is from the first company they work for. Ponder that for a moment.
This is one reason why testers are still trying to overcome the long held perception (or actual practice) of software testing and development as a competitive game like a tennis match. A developer knocks over their code and the tester volleys it back.
So you want to learn to be a tester
There is an endless number of articles about testing good practices and procedures, tools and techniques, and the latest and greatest philosophy. But what is not discussed often enough is that the software tester is the communication builder on your team.
The primary skill of a tester is as the interpreter for each discipline involved in a project: developer, project manager, requirements manager, designer, and analyst, not to mention the client and the user. First and foremost, a tester must be able to hear, understand, and explain what everyone else knows, says or asks.
Interpretation alone, though, is a passive skill. Expertly applying it fulfills the tester’s primary purpose which is as an advocate. A tester advocates for everyone who has a voice in the project; they help everyone cross the finish line. This way, testing is offensive instead of defensive and the project is a team sport.
Learn to be a user, a developer, and a stakeholder
There are three ideal outcomes for a software project: user delight, technical excellence, and client satisfaction. The key to succeeding at all three is for the software tester to advocate for each. To do this, testers build the team’s language.
Testers must speak user
Everyone on the team has the user in mind but the software tester should be an expert at being a user. Whoever the target demographic is, a tester should know how that user would approach the application, how they would or would not use it, and what frustrates them.
This is one reason why you hear testers ask so many questions: obvious questions, the same question over and over, or “why” and “how” about everything. The answers help them reconcile the technical and business choices with the actual user experience.
Client and team focus can become microscopic during a project. A tester helps the focus return to the outcome of user delight.
Testers must speak developer
“Which endpoint will the data come from?” “Do we save the user response after each question or at the end of the survey?” “Is there any personal data saved locally on the device?” “Where does the app get the timestamp?” “Which error states and empty states are handled?”
Instead of being a tennis match, the developer and tester are more like the pitcher and catcher relationship in baseball. This is described perfectly by Stephen Kerr in an interview with MLB catcher, Matt Walbeck.
"Building such trust allows the pitcher to concentrate on his main job: getting batters out. A catcher will develop instincts on the proper time to make a mound visit, when he should get in the pitcher’s face as opposed to backing off, or when to throw a ball back especially hard to get his attention.
You can talk to just about any catcher, and he’ll tell you there’s nothing greater than that feeling of being connected with a pitcher, and having him trust you so much that no matter what you put down, he’s going to throw with conviction,” Walbeck said.
Testers and developers should begin a project by collaborating on technical decisions and quantifying outcomes so they have the same game plan. The result is efficient, high quality development with more opportunities for innovation.
Testers must speak client
“We need users to be more engaged with our brand.” “Most users get halfway through the reservation flow and quit.” “Why are our distributor’s sales dropping?” “We want to market this app as AA compliant?” “We need to know how many users go all the way to the shopping cart.”
Very quickly after the discovery and requirements phase, the client’s outcomes become a checklist of acceptance criteria. Outside of having and achieving the technical needs of the product, how is the client’s voice and brand maintained in the team’s choices? Like any earnest partnership, test learns the client’s ‘delight’ language. This not only helps keep the team on track but allows them to show off in ways the client may have never dreamed of, not with bells and whistles that showcase how clever we are, but crafted solutions that show how well we listened and understood the client.
Testing is about people, not tools
It might be a surprise that the testers on your team are actually speaking three different languages other than just Test, but it’s true. And the ability to simultaneously advocate for the best outcome for multiple people means testers are made of great empathy and care, something beyond simply being detail oriented.
Testers are not on defense to challenge ideas or solutions. What they challenge is anything that is not good for the client or the user or the developer. When you work with a good tester, you should experience a clearer path for your own personal growth and an ease at achieving everyone’s outcomes.