At STRV, we the QA team referred to ourselves as QA Testers for a long time — and for the most part, the label was accurate. Methodically scouring a product in search of broken layouts, buttons that don't work and faulty design implementations is one of, if not the most important aspect of a QA team’s responsibilities. But what about the rest?
What about the time we spend thinking about all the ways to improve the product at its core? The little things that could make the app as user-friendly as possible? Being the proverbial extra pair of eyes? To do all of our responsibilities justice, we’ve decided to do a little rebranding, and thus, the STRV QA Analyst was born.
Let's tackle the big question first.
What Is the Difference Between a QA Tester and a QA Analyst?
The answer can be easily derived from the actual job title. While testers mechanically look for more and more bugs to report to the engineers, analysts strive to do more than that. They analyze the product as a whole. This includes, but is not limited to:
- Creating a thorough testing strategy at the beginning of each project that determines the overall trajectory of testing on the project;
- Writing test cases from scratch;
- Maintaining a “healthy distance" from the project itself to see the full picture, not just a glimpse of it.
But enough of the theoretical mumbo-jumbo. Let’s get into real-life examples.
QA Testers vs. QA Analysts in Practice
Imagine a generic design and engineering company — let's call it VRTS. VRTS is in the running for developing a new mobile app for a major client, and the QA Tester on the project — let's call her Amy Stake — just got her hands on the very first build of the app. After carefully trying each button and user flow, Amy only finds a few minor bugs, such as incorrect font styles and whatnot, because all the buttons work as they’re supposed to and each flow gets her to where she is supposed to be. Amy reports these bugs, closes her laptop and moves on to her next task.
And that's pretty much it. Amy does what is expected of her and that's that. Sounds like she did all she could in a QA position, right? Well, not quite.
Imagine another design and engineering company — let's call it STRV. As luck would have it, STRV happens to be in the run for developing a mobile app for the very same client as VRTS.
The first build is developed and the QA Analyst on the project — let's call her Maxie Mumm — gets her hands on it. Maxie starts by taking the same steps as Amy. She tries the buttons and the flows, then notes down the bugs. But Maxie knows this is not the end of the road.
Maxie rolls up her sleeves and gets down to it. This time, she doesn't concern herself with finding any technical bugs. Instead, she carefully goes through the app and tries to figure out how the app feels, how it behaves, whether it is intuitive, and whether it makes sense overall, as a whole.
This leads to Maxie writing a two-page document where she lists all her comments regarding the UX/UI app design and how it could be improved. The engineering team then takes these notes into consideration and rebuilds the app accordingly, which results in the final app being much more user-friendly and instinctive than it was before.
Maxie’s extra mile eventually helps convince the client that STRV is the way to go, and STRV lands the deal.
Everything a Tester Has, and Then Some
In the outlined hypothetical scenario above, Maxie’s effort sets STRV apart from the competition. It also showcases why a mere tester skillset (and mindset) doesn’t suffice when joining STRV as a QA Analyst.
Of course, the skills of a tester are a must for every QA Analyst at STRV — they’re just not enough. But on top of those, we also require:
- An excellent eye for UX design - “Should it work like this? Does it make sense to change it to this?”
- At least basic knowledge of how mobile/web programming languages work - “Is what I am proposing technically possible/doable?”
- Empathy - “Would a user actually do this? Would they figure out this is how it's supposed to work?”
As you may have noticed, UI design isn’t on this list. That's because having a good eye for UI is a basic part of a tester’s skillset. Every tester has to be able to see the differences between the designs and the actual app; what they aren’t always required to do is to look at the app from a UX perspective. As analysts, this is something that we’ve long been doing every single day. Just because we rebranded ourselves to QA Analysts quite recently doesn't mean that we didn't do this kind of work before. We did — we just didn't have the right name for it.
Acting as the Devil’s Advocate
In short, being a QA Analyst essentially requires you to be both a tester and the devil's advocate – voicing the unpopular yet necessary opinions that will immensely improve the overall quality of the product. Since STRV is all about building exceptional products, having detail-oriented people like QA Analysts as an integral part of the development process is an absolute must.
Providing the design and engineering team with hard-to-swallow pills in the form of hypercritical feedback is never frowned upon. It is actually encouraged — and that, of course, is not limited to just the QA Analysts but includes the whole team working on a project. Because as always, the devil is hidden in the details.
Where Do We Go From Here?
You may be asking: “If QA Analysts need to know all of these things, why wouldn’t they go for being a UX/UI designer or an engineer instead?” Theoretically, the argument makes perfect sense. And that's exactly why STRV not only allows but actually encourages such transitions within our company. Some former members of the QA team now work in other STRV departments. We’re always happy when people find their passion in a different field — and if we can help with that transition, we will.
But there’s one luxury the QA team has that stands out. While other departments are hard at work building something from scratch, we’re the ones who get to put on a metaphorical monocle and be professionally nitpicky. And if you ask me, there’s something wonderful about that.