What Is a QA Analyst? Quality Engineering for Real Systems

A QA analyst proves a system behaves correctly by testing it end to end, not by reading the spec and hoping. The role is quality engineering for real systems: run real and broken inputs through the whole chain, and assert the truth at every hop.

A QA analyst is the person who refuses to believe a system works until they have run something through it and watched it behave. The job is not to click through a screen and tick a box. It is to design tests from the requirements, push valid and invalid inputs through the system end to end, and confirm the actual behavior matches the intended behavior, including all the error and edge cases the specification glossed over. A QA analyst is the proof layer of a delivery team: the person whose sign-off means the build does what it claims, because they checked, hop by hop.

I have done quality work on payment engines where a single missed reason code could mean a customer is told their money moved when it did not. That stakes-level testing taught me the core truth of the role: documentation tells you how a system is supposed to behave, and testing shows you how it actually behaves. The gap between those two is where defects live, and the QA analyst is the one who finds them before production does. The full walkthrough of how I learn and test a payment system end to end is in You Don’t Understand the System Until You Test It, which is the foundation for everything here.

What does a QA analyst actually do?

The QA analyst designs and runs the tests that prove a system is correct, and uses what the tests reveal to sharpen the requirements themselves.

It starts with test design. You take a functional specification and derive the cases: every valid input that should succeed, every invalid input that should fail, every boundary, every state transition. Then you execute, but not by clicking through a UI. In a modern payment system most of the behavior has no screen at all. You submit a message, follow it through the API response, the Kafka event, the database row, the status endpoint, the logs, and the callback, and you assert the correct behavior at each one. When something is wrong, you do not just log a defect; you trace it to the hop that caused it, which is what makes a QA analyst’s bug reports worth acting on.

The part people miss is that good testing improves the spec. When you run a payment and discover the status enum has nine values in the database but only four in the requirements, you have not just found a bug, you have found a hole in the analysis. The QA analyst who feeds that back is doing functional analysis as much as quality work, which is why the two hats sit so close together. I built Automate Kafka Validation with Postman around exactly this kind of event-level verification, because Kafka is where most analysts in payments hit a wall.

What is the difference between a QA analyst and a tester?

A tester executes test cases. A QA analyst designs the strategy, derives the cases, understands why each check matters, and treats testing as a way to learn the system, not just to confirm a script.

The distinction shows up the moment something unexpected happens. A tester following a script hits a result the script did not anticipate and does not know whether it is a defect or expected behavior. A QA analyst knows the system well enough to judge, because they understand the data model, the message flow, and the intended behavior at a level deeper than the script. They are technical enough to test across service boundaries, query the database to confirm state, and validate an event on a queue directly, rather than being limited to whatever the user interface exposes.

This is why I think of the modern QA analyst as quality engineering rather than manual testing. The role has moved toward technical verification of systems that are mostly invisible from the front end. The QA analyst who can only test through a UI is testing a fraction of the system. The one who can chain API calls, read the database, and consume Kafka events is testing the whole thing. That technical depth is the same depth a technical business analyst carries, which is no coincidence: analysis and quality are two hats on one discipline.

What skills does a QA analyst need?

A QA analyst needs enough technical range to verify a system at every layer, plus the test-design discipline to know what to verify in the first place.

API testing is the baseline. You work with REST, status codes, and JSON payloads daily. You know that a 202 means received and not yet validated, and you test what happens between that 202 and the final status. Chaining requests, where each call feeds the next, is how you mirror the real flow of one transaction.

SQL lets you verify state. After a payment processes, you query the row and assert the status and reason code are correct. Without SQL you are trusting the UI to tell you the truth, and the UI often does not.

Event validation is non-negotiable in event-driven systems. You subscribe to a Kafka topic, filter by the transaction id you captured upstream, and assert the event fired with the right type and payload. If the event is missing, the failure is upstream of wherever everyone was looking.

Test design is the analyst part. You systematically cover the happy path, then break it on purpose: invalid accounts, amounts over the limit, duplicates with the same id, timeouts that leave a payment stuck. The unhappy path is where you learn the most, because production is mostly edge cases.

The domain data model tells you what correct even means. In payments that is ISO 20022 message types and reason codes. You do not memorize the standard; you learn enough to know that a closed account should produce AC04 and not AC01.

The full progression through these skills, from SQL to APIs to event streams, is the map in The Technical Skills Guide for BAs, which applies to QA analysts just as much as to BAs, because the underlying skills are shared.

What does end-to-end testing actually look like?

End-to-end testing means following one transaction through every system it touches and asserting correct behavior at each hop, instead of poking services in isolation.

Here is the shape of it in payments. You submit a pain.001 to the ingestion API and capture the identifiers, the payment id and the UETR, into variables. You assert the API returns the expected received status. Then you confirm the event reached Kafka, keyed by that UETR. Then you query the database and assert the stored status and reason code. Then you poll the status endpoint the way the customer’s channel would, and watch the status move. Then you check the logs in your observability tool, filtering on the UETR you have carried since the start, and confirm no service errored. Finally you assert the pain.002 callback returns the expected group status with the same UETR intact.

// Chain one transaction through the whole system
bru.setEnvVar("uetr", res.body.uetr);          // 1) capture id from the POST
const event = await waitForEvent("payments.received", { uetr });  // 2) Kafka
const row = await db.query(                      // 3) database state
  "select status, reason_code from payments where uetr = :uetr", { uetr });
expect(row.status).to.equal("ACCP");

That single discipline, follow one transaction the whole way, is what turns a pile of disconnected service checks into proof that the system works. It is also what makes the test repeatable: once the chain is wired, you can run a hundred different payments through it and watch how each behaves. The complete method, hop by hop with the war stories behind each check, is in You Don’t Understand the System Until You Test It.

Why the unhappy path is where QA earns its keep

The happy path proves the system works. The unhappy path proves you understand it. If you only ever test valid inputs, you have verified maybe a third of the system, because production is mostly rejections, retries, and things going sideways.

So you break it on purpose, one variable at a time. Submit a closed beneficiary account and confirm the rejection returns the right reason code and the right customer-facing message. Submit the same payment twice with the same id and watch what idempotency really does: rejected as a duplicate, silently accepted, or processed twice into a double debit. I have seen all three in the wild, and only one is correct. Kill a flow with a timeout and find out whether the payment sits pending forever, retries, or gets marked failed, and what the customer sees in the meantime. Each broken input reveals a behavior, a status, and a message a real customer could hit, and each one is a defect caught before it became an incident.

This is where the QA analyst stops being a checker and becomes an investigator. The best findings come from the weird cases nobody specified, and surfacing them is the whole value of the role. The systematic technique for designing these cases, and the templates for documenting them, are in Real-World BA Deliverables.

Where the QA analyst fits in the five hats

In the Analyst Engineering model, QA analysis is one of five hats on a single discipline: business, functional, QA, developer, and systems. The QA hat is the proof layer. It takes the behavior the Functional Analyst hat specified and confirms the build delivers it. It leans on the Developer Analyst hat to read code and automate checks, and on the Systems Analyst hat to know how the services connect, so a failure can be traced to the right hop. And it feeds back into the Business Analyst and functional hats, because the gaps testing reveals are gaps in the requirements.

The QA analyst who can wear those other hats tests deeper and reports better. Reading the code tells you where to look. Understanding the system map tells you which hop owns a failure. That is why the QA Analyst hub treats quality not as a separate department but as a mode every technical analyst should be able to switch into.

The takeaway

A QA analyst proves a system behaves correctly by testing it end to end, then uses what the testing reveals to sharpen the requirements. The role is quality engineering for real systems: run real and broken inputs through the whole chain, assert the truth at every hop, and find the defects before production does.

Get good at this and you become the sign-off the team trusts, because your approval means you checked rather than assumed. Start with Automate Kafka Validation with Postman and The Technical Skills Guide for BAs, or browse everything at The Tech BA Toolkit.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Software Testing, QA, Payments, API Testing, Career Growth