If you’re the kind of person who loves puzzles or doing escape rooms, then QA might be for you.
“If you see a challenge or something, and you want to solve it and your brain works that way, you’d be a great QA [analyst],” Emily Reaves, a QA analyst, said.
What Is a QA Analyst?
A QA, or quality assurance, analyst is someone who makes sure a software product is as good as it can be. They use tests to fine-tune products and their goals are to make apps, programs, systems, sites and games work as expected and provide the best user experience possible.
Companies are increasingly integrating QA analysts into software development teams, which means a QA analyst can have a massive impact on the products they work on, right from the very start.
QA Analysts Work Towards Improving User Experience
There is no typical day for a QA analyst, according to Reaves, who is lead QA analyst at Professional Case Management, a home care provider for nuclear weapons and uranium workers. But the day-to-day unpredictability makes the role fun, she said.
This is due in large part to the variety of projects QA analysts work on. On a slow day — one where there are no bugs to fix and no code to test — Reaves and her team often review existing testing plans, develop testing plans for early stage projects, keep up on their own training and learning, or cross train other members of the team. A busy day, like when a developer delivers code in need of testing, means launching into a whole suite of tests according to testing plans.
But there’s one goal all QA analysts have in common that guides every other element of the role: to improve the user experience of whatever product they are working on.
User experience defines the role of a QA analyst, according to Alan Nguyen, senior technical QA analyst at Riot Games, a video game developer and publisher. For his role as a QA analyst working on video games, he works on making sure players have a seamless experience as they log on to their account, open their game, see their friends in the game and their characters and items in their account. There’s a lot that goes into making even those first few seconds of interaction with the game work perfectly, and that’s what he and other QA analysts like him are there for.
“That’s what defines quality; everything has a certain bar to be met so the player audience has the experience they signed up for and expect,” he said. “QAs in general want their products to work as expected.”
Tests Are the Tools of the QA Trade
Getting products to work as expected means all QA analysts spend a majority of their time on testing and fixing bugs.
Testing is so fundamental to the QA analyst role that some QA analysts are often just referred to as testers or have “tester” in their title. But testing is not just about running tests.
The process starts with gathering testing criteria for a project. The product team or a business analyst will generally outline a new product or new functionality on an existing product, including what it will need to do. The QA analyst will take this information and must figure out how to test that product or functionality to make sure that it meets requirements.
From there, the QA analyst — or a QA engineer or the analyst’s manager or team lead, depending on a company’s QA approach — draws up a test plan, which covers their test strategy, their objectives and associated timelines and resource needs for a project.
There are many different types of tests that can be run — for example, functionality tests, reliability tests, security tests — depending on a test objective. Testing can also be manual or automated.
Automated testing basically turns the process of testing code into a program that must be coded out by testers. Automated testing usually falls into either unit testing or integration testing. Unit testing focuses on individual pieces of a software product while integration testing looks at it as a whole and makes sure all parts work together.
The benefit of automated testing is that it is fast and can be prepped before the code it is investigating is done. It’s also fun, according to Ray Vitatoe, QA Engineer at 84.51°, a retail data and analytics company.
“I almost enjoy writing tests as much as I enjoy writing code,” he said. But he’s not just writing tests to validate or fine-tune the products, he’s also turning that same attention to the tests themselves. He investigates how often tests fail because of the test itself or because of the code. Basically, he figures out if the tools he is using are the right ones for the job.
For Reaves, one of the most enjoyable parts of testing is the exploratory element. She explained that a lot of software developers and automated testing is “happy path testing.” Basically, if a user takes the proper steps, will the product do what it’s supposed to do? Of course, users don’t always do what they’re supposed to do and not all paths are happy — so what happens then?
“In QA it’s, ‘What if I don’t do step one? Or if I do step two before step one? Or go right to step three? Or what have I put in 15,000 exclamation points in this field — what happens?’” she said.
The QA testing mindset is sometimes about trying out the absurd. If a user has the ability to do something with or in a product, a QA analyst needs to have done it first and know what happens as a result. While this can be done to some extent with automated testing, this is often where manual testing comes into play.
Manual Testing for Quality User Experience
Manual testing used to be the primary way software products were tested in the past and is still the main way user interface testing is done, making it very important for improving the overall user experience. When doing manual testing, QA analysts interact with a program or product as though they were a user. If the product is a game, for example, that can mean booting it up, logging in and playing parts of the game according to testing objectives or a specific test path.
Every software product has numerous usage pathways and end results and these paths must all be tested. Jillian Munson, technology project manager at QuickFi, an end-to-end B2B digital equipment lending platform, gave the example of using the QuickFi mobile app. One test path might see her download the app as though she was a user, create an account as though she was a customer and — using test data that she knows the app will approve — she will make a transaction to test through one path a user might take through the app. In another, she might go through the process but use test data she knows will be rejected to test the declined credit path.
“You have to be prepared for every case and make sure that your UI is seamless and is intuitive to no matter who uses it.”
“There are just so many ways to do things in the avenue to make sure you hit all of those different branches and paths in order to successfully test a product,” she said.
User interface testing, particularly when done manually, is stepping into the user’s shoes, Munson said. And that means a QA analyst must consider widely different perspectives.
“Some [users] may be incredibly well-versed in an iPhone because they’ve owned one for 10 years, and someone might have bought their first smartphone yesterday,” Munson said. “You have to be prepared for every case and make sure that your UI is seamless and is intuitive to no matter who uses it.”
Testing With Everyone in Mind
Considering different perspectives means QA analysts should also be testing for accessibility.
Kim Krause Berg, a QA analyst of human experience design at BM Technologies, a digital banking platform, and a Certified Professional in Accessibility Core Competencies, serves as a subject matter expert on accessibility laws and best practices and applies them to QA.
“I test what people see and touch because that has to be accessible to everybody,” she said.
A lot of people, according to Berg, think about accessibility related to software products like websites or apps only in terms of people with visual impairments. That is certainly part of her accessibility work — like testing for text contrast and how readable a page or app is to a screen reader — but testing for accessibility is far more than that. For example, she tests to see if the desktop version of BM Technologies’ app can be navigated entirely with a keyboard by tabbing to test for accessibility for those who cannot use a mouse.
There is a lot of repetition in what she does to test for accessibility since an app or its website version must be tested in every environment a customer might use to access it. Additionally, every accessibility tool like screen readers have different commands, so she has to make sure her company’s apps and sites work with them all.
Berg’s accessibility-focused QA work is just a specialized part of the overarching goal of all QA analysts to improve the user experience.
Bugs Are a Constant for QA Analysts
Just like testing software is essential to being a QA analyst, so is finding and fixing bugs. Tests and user feedback can identify bugs, but the first part of fixing them is prioritizing them.
Nguyen, of Riot Games, explained that his team — like most QA teams — has a four-part hierarchy for prioritizing bugs based on their severity and impact on the player experience: minor, major, critical and blocker. A minor bug for video games might be something like minor clipping of a character’s hair while a major bug might be that a character is missing limbs. A critical bug might be something like a player logs into their game only to find characters or items missing. A blocker bug — much like the name suggests — blocks any forward progression through the game (like game crashes).
Bugs can also be less obvious. For example, modal windows or pop-ups on websites and apps are almost always invisible to screen readers, according to Berg. Since such elements often include important information like instructions or warnings, this represents a major bug.
“A good QA [analyst] knows how to navigate the human element to it because, in the end, you want to have the least bugs.”
But while QA analysts might want to identify and fix every single bug in a software product, that’s not realistic, Nguyen said.
“There comes a point where there’s diminishing returns on how many hours you sink into tests, how many bugs you’re gonna get,” he said.
The reality that no software product will ever be perfect and free of flaws is something that keeps Munson up at night. But, for her, the agile method of focusing on delivering something functional over perfect helps temper that worry.
“We would rather get something out there that we’ve tested pretty well and looks pretty good, rather than keeping something inside for months trying to get out every single tiny, little bug,” she said.
Another challenging but engaging aspect of being a QA analyst, according to Munson, is the level of attention to detail and patience that is required. That patience is especially important with the frequent experience of having someone, a user or someone internal, complain about a problem with the product without offering a solution. It requires a high level of creative problem-solving as well as interpersonal skills.
QA analyst’s job to anticipate problems in designs or point them out to teammates after they’ve cropped up, Nguyen said. But bringing those issues up with other members of the team can be a challenge.
“That’s always a hard conversation, no matter how minor it is,” he said. “But a good QA [analyst] knows how to navigate the human element to it because, in the end, you want to have the least bugs.”
Agile Has Changed How QA Analysts Work
As a result of widespread adoption of agile, the daily work lives of most QA analysts look a lot like those of software developers, according to Vitatoe, who was a software developer for over 20 years. For his team, each product cycle begins with identifying the minimum viable product.
“For example, if we have a process where we manually enter data into 20 different Excel documents, we could see a time savings if we start with automating just one of those documents,” Vitatoe said. Automating that one document would be the minimum viable product. Once that has been created, the team can add functionality in an iterative process of creation and improvement. In Vitatoe’s example, automating those additional 19 documents could represent added functionality to the product.
In this iterative approach to development, the QA analysts are constantly testing the product as it is being designed, making sure it matches the expected parameters of what the team had outlined. In many cases, Vitatoe said the QA team is able to design and build their test plans as the product or added functionality is being developed.
“Obviously, if they haven’t developed it yet, every test is going to fail, but that’s what we expect,” he said. “As they build the applications, all of a sudden those tests start passing. And then what we have at the end is we have new code that is basically ready to go into production almost immediately just because we’re able to build the testing frameworks while they’re building the code.”
“QA begins in the planning process of that first step — we determine what it will take to develop that functionality and, at the same time, we determine what tests we need to wrap that functionality in.”
But it didn’t used to be this way.
The experience of a QA analyst working under agile is very different from one working under the waterfall methodology. In waterfall, the development process is very linear with the QA team getting to see a product only at the very end. This often resulted in the QA team not knowing what they were going to be getting and not really knowing much about the product since they were not involved in its creation. This meant most (if not all) of the testing they did had to be manual, which is usually a very slow process. Given the length of time between product design and development to testing and release, some products might not be needed or wanted by the time it is finished and released.
Vitatoe worked under both systems and said the industry shift to agile had a massive impact. QA isn’t treated like an afterthought anymore, he said, but is instead part of the whole process.
“QA begins in the planning process of that first step — we determine what it will take to develop that functionality and, at the same time, we determine what tests we need to wrap that functionality in,” he said. “We make sure our tests are as well planned out as the features we are developing.”
Along with the transition to agile methodology, many QA analysts and teams are becoming more integrated with development teams. At Riot Games, embedding QA analysts into the development teams means there’s a QA analyst in every pod — a team focused on specific elements within the games — according to Nguyen, whose pod focuses on skins for League of Legends. This integrated system allows both developers and QA analysts alike to learn from past production cycles and try to address problems before they arise. If, for instance, certain skin features are known to be prone to clipping issues and the project is on a tight timeline, the QA analyst on the team could bring that up during concept design.
Also, depending on the company and the project, the lines between QA and development can get blurry. Vitatoe, for example, had been a developer for over 20 years before transitioning over to QA because he wanted to improve his testing skills. Developers also run tests on their code and products, but that testing is limited and Vitatoe wanted to do more. Plus, he said that those doing QA have a unique power within a development team; in a way, they get to define what is important within a project.
“There [are] guidelines, but there’s no right answer for every particular situation,” he said. “So it’s just one of those situations where you kind of feel it out and figure out ‘What’s the best way to go about this?,’ which makes it a lot of fun.”
But this doesn’t mean development and QA are the same. There are different mindsets involved, according to Reaves. While a developer thinks about how to build something, a QA analyst thinks about how to break it. This isn’t an adversarial relationship, she said, but a complementary one where both sides have different focuses to produce a well-rounded, quality product.
QA Analysts: More Than Just Testers
Vitatoe described the role of a QA analyst as almost like insurance. A QA analyst safeguards the reputation of the company by ensuring the products it puts out are of high quality. And being a QA analyst is just as creative and enjoyable as his time as a developer, he said. Just like a developer, his best days are those where he can tune everything out and just delve into the strategy and creativity of writing and coding out automated tests.
The synergy that can exist between QA and development teams can increase the fun of the role, too. Vitatoe described a time his team did some test-driven development — where tests are written before the code — as one of the best of his experiences in QA. He described it as almost like a game of checkers as he and the developer he was paired with switched off making coding moves. First, he wrote a test, then the developer would code to meet and pass that test. They proceeded like that, each time with Vitatoe’s tests preceding the developer’s increased coding of the product with the tests driving the improvement of the resulting product.
Ultimately, he urged anyone thinking about a job as a QA analyst to not come to the role with preconceived notions of what it is.
“My advice would be not to think of it as a tester role, but to think of it as a thought leadership role,” he said. “We’re basically proving that what we’re putting out there is high quality.”
