Working With QA: A Field Guide for Analysts Who Do Not Test

QA exists to find where the system disagrees with the specification. You wrote the specification. That single fact defines the entire relationship: most of what QA needs from you arrives long before testing starts, and an ambiguous requirement is not an obstacle for QA to work around, it is an analyst defect discovered at the most expensive possible moment.

Analysts often treat QA as the phase after theirs, a downstream team that receives a build and reports on it. Under that model the analyst hands over a document and waits, and the first real conversation happens in defect triage, where it takes the form of an argument about whether something is a defect.

The productive model is different. QA is the first team that reads your specification adversarially, which makes them the best reviewers you have. This guide is about being the counterpart they need without becoming a tester yourself. The test discipline behind it is covered in depth in API Testing and QA Mastery for BAs.

What does QA actually need from you?

Three things, and only the third one happens during the test phase.

Testable requirements, written before the build. This is the whole game and it gets its own section below.

Test data and the rules behind it. QA can generate a thousand records. QA cannot know that a corporate payment file from your largest client arrives with mixed currencies, contains one transaction with a missing purpose code because their ERP does not populate it, and always lands at 16:55 on a Friday. That knowledge is yours, and without it the test environment contains data that is technically valid and business-fictional, which is how a suite passes everything and production fails on day one.

Priority decisions during triage. QA can tell you a defect crashes the screen. Only you can say whether that screen is used four hundred times a day by the payment repair desk or twice a year by an administrator. That is defect triage, and it is the moment the analyst is least replaceable.

What makes a requirement testable?

Four properties. The practical test for all four is whether someone who attended none of your meetings can read the requirement and build the test without asking you a single question.

An observable outcome. “The payment is validated correctly” is not observable. What can a tester see? A status, a message, a record, a rejection code. If the only way to confirm the behaviour is to read the database or the code, say which table or make the outcome visible, because otherwise every test result is an interpretation.

A defined precondition. What state must exist first? An account in a particular status, a customer with a particular limit, a payment already at a particular stage. Testers spend a surprising share of their time reverse-engineering setup, and every hour there is an hour not spent finding defects.

Specific data. “A large payment” produces two different tests from two testers. “A payment above the 50,000 EUR approval threshold” produces one. Where a boundary exists, name it, because the boundary is where the defects are.

An unambiguous pass condition. One reading only. “The payment should be rejected with reason code AC01 and the customer notified” is two assertions and both are checkable.

Compare these two, which describe the same rule:

The system shall validate the creditor account and handle invalid accounts appropriately.

Where the creditor account number fails the check digit validation, the payment shall be rejected before submission with reason code AC01, the payment status set to RJCT, and the originating customer notified within the channel. Where the account number is valid in structure but the account is closed at the creditor agent, the payment shall be returned with reason code AC04.

The second one is longer and it is not more work, because the questions it answers are questions somebody was going to ask anyway, in a meeting, in week nine. It also happens to contain two test cases and the AC01 versus AC04 distinction that determines whether the payment is repairable, which is a business decision hiding inside what looked like a formatting detail.

How do you review a test plan when you are not a tester?

Do not review the techniques. You are not qualified to assess whether their automation approach is sound, and attempting it wastes everyone’s time. Review the coverage against intent, which you are uniquely qualified to do because you wrote the intent.

Five checks:

Every business rule has at least one case. Take your rules, one by one, and find the test. A rule with no test is either untested or unlinked, and both are findings worth having. Doing this systematically is what a requirements traceability matrix is for.

The negative cases exist and are specific. A test asserting that a bad payment “fails” is weak. One asserting it fails with a specific reason code is a real test. This is where domain knowledge shows up: only you know that returning the wrong rejection code sends the customer down the wrong remediation path.

Boundaries are tested at the edge, not near it. If the threshold is 50,000, the cases are 49,999.99, 50,000.00, and 50,000.01, not “a small one and a big one”. Off-by-one errors at business thresholds are common and expensive.

The messy real scenarios are present. The duplicate file. The payment amended after submission. The customer who cancels while it is in flight. You know these because you have watched the business work; a tester who has not sat with operations cannot invent them.

Someone has thought about what happens after failure. Not just that a payment is rejected, but where it goes, who sees it, and what they do next. Rejection paths are under-tested everywhere, and they are where operations lives.

Notice that all five are questions about the business, not about testing. That is the correct division of labour, and it is why the review is worth your time and not a courtesy.

Severity or priority: who decides what?

This is the most common source of unnecessary friction between analysts and QA, and it disappears entirely once both sides see them as two independent axes with two different owners.

Severity is technical impact, and QA owns it. Does the system crash, corrupt data, block a business flow, or is it cosmetic? A tester can assess this from the behaviour alone.

Priority is business urgency, and you own it. How badly does this need to be fixed before release, given what the business does with the feature?

They are independent, and the interesting cases are the ones where they disagree.

Defect	Severity	Priority	Why
Report screen crashes on an unused filter	High	Low	Nobody uses it; fix it next sprint
Debtor name truncated by five characters	Low	Critical	That name feeds sanctions screening
Typo in a label seen by every customer	Low	High	Brand and trust, trivial fix
Batch fails at over 10,000 records	High	Low	Our largest file is 4,000, revisit before growth

Row two is the one worth memorising, and it is the clearest example of why this decision cannot be delegated to QA. A cosmetically shortened name looks like nothing. If that field is an input to a regulatory control, the shortened value changes what the control matches on, which makes it a compliance question rather than a formatting one, exactly as described in the truncation ledger. A tester without payments domain knowledge cannot be expected to see that. You can, and if you are not in the triage meeting, nobody does.

What happens when QA says the spec is wrong?

They will say some version of this: “It works exactly as specified, and I do not think that is what the business wants.”

This is the most valuable sentence QA can produce, and the reflex to defend the specification is strong. Resist it completely. A tester who has spent three weeks operating the system as a user has information you did not have when you wrote the document, and they are handing it to you while it is still cheap. The alternative to hearing it now is a customer finding it, or a user acceptance testing cycle discovering it two weeks before go-live.

The right response has three steps. Confirm the behaviour matches the spec, so you both agree on the facts. Assess whether the spec is wrong, incomplete, or simply surprising but correct. Then raise it as a change with the business impact stated, rather than quietly rewriting the requirement, because a spec that changes silently destroys traceability and leaves the test cases pointing at a version that no longer exists.

There is a third category the two-way split hides, and it is worth naming honestly: the specification was ambiguous enough to support two readings, and the developer picked one. That is not a build defect and not a business change. It is an analyst finding. Recording it as such takes some professional composure and it is how a team gets better, because a pattern of them tells you something specific about how your specifications are written.

What about test data?

Test data is more of an analyst responsibility than most analysts realise, and it is where a lot of late failures originate.

The failure mode is a test environment full of data that is structurally valid and behaviourally fictional: every payment is well formed, every customer has complete details, every file arrives at a sensible time. The system passes. Then production delivers a file with a trailing blank line, a customer name containing an ampersand, and a batch that lands during the settlement cutoff, and none of those were in the suite because nobody who built the data had watched the business run.

Your contribution is the shape of reality: which fields are genuinely optional in practice regardless of what the schema says, which values appear in volume, what the timing looks like, what the largest realistic file is, and which weird recurring case operations complains about every month.

One firm boundary. The instinct to solve this by copying production data is understandable and usually not permitted. Real customer names, account numbers, and payment details in a test environment is a data protection problem regardless of how convenient it is, and the correct answer is masked or synthetic data that preserves structure and distribution. The structure is what the tests need. The real identities never were.

The takeaway

QA finds where the system disagrees with the specification, and you wrote the specification, so most of the value you deliver to QA lands before testing begins. Write requirements with an observable outcome, a defined precondition, specific data, and one unambiguous pass condition, and use the test of whether a stranger to your meetings could build the case without asking you anything.

Review test plans for coverage against business rules rather than for technique, and check the five things only you can check: every rule covered, negative cases asserting specific errors, boundaries tested at the edge, the messy real scenarios present, and the after-failure path considered. Own priority while QA owns severity, and stay in the room for triage, because a low severity defect in a field that feeds a regulatory control is the highest priority item in the release and nobody else will say so.

When QA tells you the system works as specified and the specification is wrong, that is the cheapest defect you will ever be handed. Say thank you and go and fix the specification.

Start with API Testing and QA Mastery for BAs for the test design that makes these conversations concrete, and Real-World BA Deliverables for the requirement and test case templates, 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: Business Analysis, QA, Collaboration, Testing, Requirements