Remote B2B QA: embed without becoming a bottleneck

A QA bottleneck rarely announces itself. A column called “Ready for test” gets longer, a question about expected behaviour sits unanswered overnight, and a release waits for one person to say it is fine. When that person is a remote contractor the queue is harder to see. Nobody walks past a desk and notices the pile. They see a board that has stopped moving and draw their own conclusions.

I work with European product teams remotely and B2B, meaning through my own company and not as an employee. Embedded means I sit inside the squad: its sprint, its tools, its ceremonies. The arrangement works when work flows past me. It fails when every decision about quality has to pass through me first.

How embedded QA becomes a bottleneck

The cause is almost never slow testing. It is that QA has become the only route to a decision. Each row below is a small queue, and a team can have all of them at once.

Remote work adds one more: the reply. A question sent as someone’s day ends and answered the next morning has cost the team half a day, even if the answer took two minutes.

What to agree in writing before a remote QA embed starts

Remote B2B works when expectations are boring and explicit. I ask for four things in writing in the first days. Each exists to remove a wait.

• Response windows. How quickly I answer in working hours, and what is urgent enough to interrupt. People can plan around a known wait. An unknown one stops them.
• Ceremonies. Which ones I attend and what I bring to each. Refinement and triage need a tester in the room. A status round can usually be read.
• Where findings live. In the team’s tracker, linked to the story, visible to everyone. Never in a private document or a direct message.
• What “release ready” means. The evidence a release needs and who decides. Left unwritten, it defaults to “when QA says so”, and the queue forms there.

I work in the squad’s own tracker, wiki and chat, and my own company’s administration stays on my side. Nobody should have to climb a vendor wall to find out where their release stands.

How to push quality decisions out to the team

Removing the queue means giving each decision to the person who should own it, and making it possible for them to take it without me.

Severity. I co-write short severity rules with Product and Engineering, using examples from the team’s own tickets. Once a developer can classify a defect sensibly late in the evening, triage stops waiting for my morning.

Defects that do not bounce. A ticket that comes back marked “cannot reproduce” or “what is expected?” has made two trips through the queue. A defect template of mine cut developer returns by about 40%. I share it so developers and Product can raise findings without routing them through me. What goes into one is in Defects Product thanks you for.

The release call. I publish a readiness note that people outside the test team can read, with my recommendation in the first line. Product and Engineering decide. That is where the decision belongs, and it means a release never waits for a tester to feel comfortable.

Capability. I pair with the team’s testers and developers on the hard tickets and then step back, as I describe in Mentoring QA without cloning yourself. In a week when I am away, someone else should be able to run the smoke checks, write the note and hold the severity line.

Written evidence carries most of this. A short pack that says what was verified, what is open and who owns it can be read at any hour, in any timezone. It is how I keep stakeholders in the loop without adding meetings.

The objection: QA is just handing work back

A Head of Engineering sometimes hears “push ownership outward” as a contractor doing less. Testers raise the opposite worry: if developers verify their own fixes and Product owns severity, the bar will drop.

Neither holds if the split is made by risk. I keep the work that needs a tester’s judgement: the journeys that carry revenue or trust, the integration points, exploration around whatever changed, the readiness evidence. What I give away is routine verification and decisions that were never mine. Then I sample what I gave away. If developer-verified fixes start reopening, the rules or the examples need work, and I say so openly.

The harder problem sits with the consultant. Being the person everyone waits for feels like being valuable, and a contractor has a commercial reason to enjoy the feeling. I treat it as a warning. Once a week I look at the board for anything waiting on me alone: a question only I can answer, a status only I can move. Each one is the next thing to write down, hand over or teach.

A good embed shows in three places. Velocity stays honest, because “done” includes evidence. Users stay protected, because more than one person can check the critical journeys. And the team is stronger on the day the contract ends than on the day it began. If the practice only runs while I am online, I have built a dependency and called it a service.