From QA Tester to Business Analyst: You Already Do Half the Job

A QA tester already does half of a business analyst’s job: reading requirements for gaps and writing acceptance criteria as tests. The half you are missing is elicitation, prioritization, and owning scope, and you can build it in six to twelve months without leaving your team. The move usually pays: a mid-level manual QA analyst in a US major metro earns US$72k to US$92k base, a mid business analyst US$85k to US$110k, a typical gain of 10 to 25 percent at the same level.

The best reviewer of my specifications on one payments program was not a senior BA. It was a QA analyst who read every spec the day it landed and came to refinement with a list. On a beneficiary validation change she asked: “What happens when the IBAN is valid but the account is closed? And when it was closed yesterday but the payment was created last week?” Two questions, two missing rules, one of them a reconciliation break that would have cost operations a week of manual work every quarter.

She found six gaps in my spec in an hour. A year later she was writing specs herself, and developers told me hers came back with fewer questions than mine. That is the pattern of a tester who becomes an analyst: the critical reading is already there, and the craft to learn is producing the requirement rather than attacking it. The path from a one-line business request to a spec a developer can build is what I cover in From Vague BR to Functional Requirements, with banking examples.

What does the move from QA to business analyst actually look like?

The move from QA to business analysis shifts your job from checking the requirement to producing it. As a tester you receive a specification and ask where it is wrong. As an analyst you start from a stakeholder who says “we need to stop the duplicate payouts” and you produce the specification, which someone like your former self will then attack.

As a QA analyst you…	As a business analyst you…
Read the spec and find the gaps	Write the spec and close the gaps before anyone reads it
Write test cases from acceptance criteria	Write the acceptance criteria, which are the tests in business language
Raise defects against the build	Decide with the business whether a defect blocks release or becomes a change request
Run UAT scenarios with business users	Agree with business users what must be true for the release to be accepted
Test what is in scope	Decide, with the product owner, what is in scope and what is not
Report on execution and coverage	Report on decisions, open questions, and risk to the business outcome

The QA role is described in full in what is a QA analyst. The view from the other side of the table, what analysts need from QA, is in working with QA, and it is worth reading before your first BA interview because it tells you what your future QA colleagues will expect of you.

What does a QA tester already bring to business analysis?

A QA tester brings four assets that many business analysts take years to build:

• Negative thinking. You ask what happens when the input is missing, too long, duplicated, or late. Analysts who come from the business often specify only the happy path. Put negative test design into the requirement itself and half of your future defects never exist.
• Test design. Boundaries, equivalence classes, and decision tables are also the best way to write an unambiguous business rule. A decision table written by a tester is usually a better requirement than three paragraphs of prose.
• Defect triage. You already sit in the meeting where severity, priority, and “defect or change request?” get decided. Defect triage for analysts is the meeting where analysts earn their seat, and you are halfway in it.
• UAT. You have worked with business users under release pressure. User acceptance testing is where the business decides whether the requirement was right, and a UAT lead knows exactly how requirements fail there.

Your acceptance criteria habit also transfers directly, including to the hardest case: acceptance criteria for AI systems, where outputs are non-deterministic and a tester’s instinct for bounds and properties is exactly what the spec needs.

What is the gap between QA and business analysis?

The gap between QA and business analysis is three skills a tester rarely practises:

• Elicitation. Testers receive requirements; analysts extract them from people who describe symptoms, workarounds, and solutions. The skill is asking the question behind the question and noticing what nobody mentioned.
• Prioritization. A tester wants every gap closed. An analyst has to decide which gaps ship in this release and defend that decision in front of a sponsor. Methods such as MoSCoW prioritization help, but the real skill is saying “Won’t, this release” to someone senior.
• Owning scope. In QA, scope is given. As an analyst you negotiate it, write it down, and hold it when a stakeholder adds “one small thing” in week six. Refinement for analysts is where that ownership shows up every sprint.

The honest self-test: can you run a one hour session with three stakeholders who disagree and leave with a decision written down? If not yet, that is the gap to work on first.

How much more does a business analyst earn than a QA tester?

A business analyst typically earns 10 to 25 percent more than a manual QA analyst at the same level. The figures below are indicative 2026 base salaries for permanent roles in large cities, excluding bonus.

Role	US (USD)	Canada (CAD)	UK, London (GBP)	Eurozone (EUR)
QA analyst (manual), junior	55k to 72k	50k to 62k	28k to 36k	34k to 42k
QA analyst, mid	72k to 92k	62k to 80k	36k to 48k	42k to 52k
QA analyst, senior	90k to 115k	78k to 98k	48k to 62k	52k to 65k
Business analyst, mid	85k to 110k	72k to 90k	42k to 55k	48k to 60k
Business analyst, senior	110k to 135k	90k to 110k	55k to 72k	60k to 75k
Technical BA, mid	95k to 125k	80k to 100k	50k to 65k	52k to 65k
Functional analyst, mid to senior	90k to 145k	78k to 120k	48k to 78k	52k to 80k

What the table says:

• At the mid level the gain is roughly 14 to 19 percent in every market, comparing band midpoints. US$72k to US$92k becomes US$85k to US$110k; C$62k to C$80k becomes C$72k to C$90k.
• Testers with SQL and API testing skills should look at the technical BA row. It sits another 10 to 20 percent above the BA row at the same level, and those are skills many testers already have.
• A senior QA analyst moving to a mid BA role may earn roughly the same. The raise comes at the first promotion, not the move.
• UK roles outside London sit roughly 15 to 20 percent lower, and smaller US metros 10 to 20 percent lower.

To verify for your market, read posted ranges where the law requires them: New York, California, Colorado, Washington, Illinois, and several other US states; British Columbia since November 2023; Ontario since January 1, 2026 for employers with 25 or more employees; and EU countries as member states implement the Pay Transparency Directive. In the UK, ITJobsWatch shows rates by keyword. The Robert Half, Hays, and Michael Page annual guides are useful cross-checks, as is asking two people one level above you. Every band is in the analyst salary guide for 2026.

Does it ever make sense to move from business analyst to QA?

Moving from business analyst to QA makes sense in a narrow set of cases. If you enjoy finding what is broken more than negotiating what to build, if the politics of scope wear you down, or if you want a concrete daily output, QA can be a better seat. The cost is real: a mid BA at US$85k to US$110k moving to mid manual QA at US$72k to US$92k takes a cut.

The version that pays is BA to automation. A mid SDET (software development engineer in test) earns US$100k to US$130k, above both mid BA and mid QA, and an analyst who already writes acceptance criteria and SQL has a head start. The route and its timeline are in QA analyst to automation engineer. The difference between the two testing seats is in QA analyst vs test engineer.

What does a QA to BA move look like in real cases?

The cases below are composites of moves I have watched on delivery teams, with details changed.

Hannah: manual tester in Leeds to business analyst at a building society

Start: manual tester on a savings platform, £33k, four years in, known for finding requirement gaps in review. What she built (10 months): a specification written from scratch for an interest rate change notification, reviewed by the lead BA; a UAT planning workshop she facilitated with branch operations; and a MoSCoW decision on a backlog slice she presented to the product owner. First role: business analyst at a building society in Yorkshire, an external move after an internal opening fell through. New pay: £38k, in the mid BA band once adjusted for a city outside London, a gain of about 15 percent. What she would do differently: stop volunteering for every regression cycle during the transition. Her team kept pulling her back into testing because she was the best at it.

Karim: UAT lead in Montréal to functional analyst

Start: UAT lead on a core banking replacement, C$86k, running business testers across three departments. What he built (6 months): configuration-level functional specs for two product rules he had previously only tested, a fit-gap workshop with the vendor, and a traceability view linking his UAT scenarios back to requirements. First role: functional analyst on the same program, an internal move. New pay: C$95k, inside the functional analyst band, a gain of about 10 percent. What he would do differently: learn the package’s configuration screens earlier. Certified specialists on packaged platforms sit 10 to 20 percent above the band, and he waited a year to start.

Lena: QA analyst in Berlin to BA, then technical BA

Start: QA analyst on a payments API, €50k, strong on Postman and SQL. What she built (8 months, then 2 years): a spec for a refund rule change, a three amigos format she introduced to her team, and later API requirements and contract reviews. First role: business analyst at a Berlin fintech at €56k, a gain of 12 percent; two years later, technical BA at €63k. What she would do differently: apply for technical BA roles straight away. Her API testing skills were already at that level, and the detour through a generic BA role cost her two years of the higher band.

The BA interview will test the half you are weakest at, elicitation and prioritization. The questions, what each one tests, and how to answer from real QA work are in The BA and Technical BA Interview Guide.

What is the six month plan to move from QA to business analyst?

Six months is enough to build the evidence if each month produces one artifact. Check where you stand first on the technical analyst skill matrix and the roadmap; the other routes out of QA are on the career paths page.

1. Month 1: shadow elicitation. Ask the BA on your team to let you sit in two stakeholder sessions and write the notes. Artifact: the notes, plus a list of the questions you would have asked.
2. Month 2: write a spec from scratch. Pick a small change and write the business rules, data, and acceptance criteria before any test exists. Use a decision table for the rules. Artifact: a spec reviewed by the BA and a developer.
3. Month 3: facilitate a workshop. UAT planning, a three amigos session, or a current state walkthrough. Prepare the agenda and write the decisions log. Artifact: the log with owners and dates.
4. Month 4: make a prioritization decision. Take a backlog slice of eight to twelve items and propose Must, Should, Could, and Won’t with a reason each. Present it to the product owner. Artifact: the agreed list, with what changed and why.
5. Month 5: own a story through refinement. From request to ready, including the questions developers raise. Artifact: a story that passed refinement without being sent back.
6. Month 6: make the move. Take the five artifacts to your manager or the BA lead, rewrite your CV around analysis outcomes, and prepare for interviews. The internal route is usually faster; see changing role inside your company, and for the CV, rewriting your CV for a role change.

For models of what a finished spec, test case, and process map look like on real banking projects, Real-World BA Deliverables (20 Templates) gives you 20 of them to adapt.

How can a tester practise analysis outside the day job?

A tester can practise analysis on a realistic system and keep the result as portfolio evidence. The Labs mission Analyze a payment API suits testers well: you read an OpenAPI contract against requirements, sample responses, and business rules, and produce a gap register. You will find the gaps fast. The analyst part is ranking them by severity and writing each as a question the API team can answer, which is prioritization and elicitation in miniature.

The missions follow the Become a Technical Analyst track. A free account saves your progress and unlocks the solutions and self-assessment, so you can compare your register with mine.

What mistakes stall the move from QA to business analyst?

• Staying the tester in meetings. Pointing out gaps without proposing the rule. An analyst closes the gap in the same breath: “here is the case, here is what I suggest the system does”.
• Specifying everything. A tester’s instinct is full coverage. A spec with forty edge cases for a two-day change will not get read. Rank them.
• Avoiding conflict. Elicitation means asking a senior stakeholder why, twice. Testers used to raising defects in a tool often find this harder than expected.
• Leaving your CV full of execution metrics. “Executed 400 test cases” says tester. “Found 14 requirement gaps in review, 3 release blocking” says analyst.
• Ignoring the technical option. If you already use SQL and Postman, read how to become a technical business analyst before you settle for a generic BA offer.

The takeaway

A QA tester who moves to business analysis already has the critical half of the job: reading for gaps, thinking about the unhappy path, and writing acceptance criteria as tests. The missing half is elicitation, prioritization, and owning scope, and you prove it with three artifacts: a spec from scratch, a workshop you ran, and a prioritization you defended. The move typically pays 10 to 25 percent more at the same level, and more again if your technical skills take you to the technical BA row.

To learn the part testers rarely practise, turning a vague request into a buildable spec, start with From Vague BR to Functional Requirements. If you want someone who has hired analysts to review your plan or your CV, book a 1:1 Tech BA Coaching Call. The free downloads are a good start, and everything else is at The Tech BA Toolkit. More on the testing side lives in the QA Analyst hub, and on the requirements side in the Business Analyst hub.

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: Business Analysis, Quality Assurance, Career Change, Software Testing, Banking