A test strategy you can actually staff
A written plan covering what gets automated, what stays manual, and what is deliberately left untested. Sized to your release cadence and the people you have, not to an ideal team you do not employ.
Fractional Teammates · Technology & Quality
A senior QA engineer inside your team, part-time
A senior QA specialist from the OlDevs team, embedded part-time in your organisation. They own the test strategy, the automated suites in your CI, accessibility checks and the release decision, working in your repositories and your standups.
A senior specialist, not a junior placement You own the work and the accounts Reply within one business day
build-orchestrator
mainsrc/
queue.ts
pool.ts
retry.ts
types.ts
index.ts
1
2
3
4
5
6
7
8
export interface BuildJob {
repo: string;
region: "ca-west-1";
}
export async function queue(
job: BuildJob,
): Promise<Run> {
return await pool.add(job);
212
Tests passed
0
Type errors
1.4s
Build time
Watching src/ — optimised rebuild on save
What a qa & testing engineer is
OlDevs puts a senior QA and testing engineer inside your team for an agreed number of days each week, ongoing rather than project by project.The role owns quality end to end: the test strategy, automated regression and end-to-end suites running in your CI, exploratory sessions, accessibility checks to WCAG 2.2 AA, bug triage, and the go or no-go call before each release. They work in your repositories, your test runner, your issue tracker and your standups, so the suite belongs to you from the first commit. It suits teams shipping often enough to need dependable release confidence, but not often enough to fill a full-time quality role.
Key facts
- 01Group
- Technology & Quality
- 02Model
- Part of a senior week, every week, ongoing
- 03Works in
- Your repositories, CI, test runner and issue tracker
- 04Standard
- Accessibility tested to WCAG 2.2 AA
- 05Typical commitment
- 1–2 days a week
- 06Judged on
- Escaped defects · Suite runtime · Coverage of critical paths
Technology & Quality
What your QA teammate owns
What this teammate takes off your plate
Automated regression suites in your CI
Unit, integration and end-to-end tests running on every pull request and before every release, wired into your existing pipeline so a failure blocks the merge instead of arriving later as an email.
Coverage of the journeys that pay
Checkout, sign-up, booking, form submission, payment callbacks. The paths where a silent failure costs money get scripted first, with stable selectors and seeded data so the tests survive a redesign.
Exploratory and accessibility sessions
Time-boxed testing that probes what automation cannot: confusing states, odd input, behaviour on real devices. Accessibility is checked to WCAG 2.2 AA with keyboard, screen reader and contrast passes every release.
Bug triage that keeps the backlog honest
Every report reproduced, labelled by severity, deduplicated and routed to an owner. Your developers get steps that reproduce first time instead of a screenshot, a version number and a shrug.
Release sign-off with a written record
A go or no-go call before each release, backed by suite results, a smoke pass on staging and a note of the known issues shipping with it. Rollback criteria are agreed in advance, not improvised.
Benefits
What a dedicated tester changes about shipping
01
Release decisions stop being a vote
Sign-off stops turning on whether anyone had time to click through the screens. The team ships knowing which paths were exercised, which were not, and what risk it is accepting, in writing that still makes sense a month later.
02
A failing build means something again
Flaky tests get fixed or deleted rather than re-run until green, so a red result stops being something developers scroll past. The suite goes back to being evidence about your product rather than about itself.
03
Customers stop being your regression pass
Regressions surface in exploratory and automated passes before a release rather than in a support ticket. Escaped defects become a number you review on a schedule, instead of the thing that sets your week's agenda.
04
Accessibility stops being an assumption
WCAG 2.2 AA moves from something the team believes it meets to something exercised on a screen reader, by keyboard and at zoom, on named templates. When evidence is asked for, it already exists.
05
Testing stops trying to cover everything
Effort goes where failure actually costs you, because deciding what is not worth a test takes years of watching suites rot. Very few teams have enough of that work to fill a specialist's week, so the call falls to whoever is free.
06
The suite outlives the engagement
Test plans, fixtures and seed data sit in your repositories and run on your own CI, with the risk reasoning written beside them. The next engineer inherits why a path is covered, not only that it is.
How it works
How the first quarter goes
A read of your last few releases
We look at what broke after each one, which tests existed, and which failures reached users. You get a written picture of where quality actually breaks before any new code is written.
A strategy your developers agree to
What gets automated, what stays exploratory, what is out of scope, and which journeys are covered first. Reviewed with your engineering lead and revised until the plan is realistic.
Named access to the pipeline
Accounts in your repositories, CI, staging environments and issue tracker at the permission level you choose. Nothing is created in a studio account you cannot see into.
First suites on the journeys that pay
Coverage starts where a silent failure costs money, wired into your CI so results land on pull requests. The early weeks buy stability rather than a large test count.
A weekly rhythm, with cover written in
Your teammate joins standups, triages incoming bugs and demos every week. The strategy lives in your repository, so a second OlDevs specialist can run sign-off if they are away.
Who it's for
Where fractional QA fits
Fractional QA fits a specific shape of problem. It works when quality is a continuing need rather than a project, and when your team can give a senior outsider real access to the pipeline they are being asked to protect.
Teams shipping faster than they can test
Developers test their own work between features, regressions reach production, and nobody owns the release decision, so it gets made by whoever is least tired that afternoon.
A test suite nobody trusts any more
The suite exists but fails so often that red builds get ignored. Someone has to stabilise it, delete what is dead, and make a failing pipeline mean something again.
Anyone with a WCAG 2.2 AA obligation
Public bodies, associations and regulated businesses that must meet the standard on every release, rather than once a year in a panic before an external audit.
Products going through a replatform
You are rewriting or migrating, and you need a regression net that proves the new thing behaves like the old one, journey by journey, before anyone switches traffic across.
12+
Years of studio experience since 2014
1–2
Typical commitment — 1–2 days a week
EN/FR
Languages this engagement can be delivered in
Other fractional roles
Often paired with
01
DevOps & Cloud Engineer
A senior DevOps and cloud engineer from our Vancouver studio joins your team for a defined part of each week.
Explore02Cybersecurity Specialist
A senior cybersecurity specialist from the OlDevs studio joins your standups for a defined part of each week.
Explore03Full-Stack Developer
One person who takes a ticket from design through front-end, API, database and deployment without a handoff.
ExploreFAQ
Before you bring someone in
Yes, and that is usually what we recommend. Migrating frameworks costs weeks and buys little while the current one still runs. Your teammate starts by reading what exists, fixing the flaky tests that taught everyone to ignore red builds, then filling the gaps. We propose a change of tooling only when the current one blocks something specific, with the reason and the effort written down first.
They keep writing tests; someone senior now owns whether the whole thing can be trusted. Your teammate decides what belongs at unit level and what needs an end-to-end path, reviews test code in pull requests the way developers review features, keeps the suite fast enough that nobody skips it, and takes the release decision off whichever developer merged last.
You see it every week. Each demo covers suite pass rates, what was added, which flaky tests were fixed, defects caught before release against those found after, and accessibility issues opened and closed. All of it lives in your issue tracker and CI dashboards, visible without asking us. We do not promise a defect count or a quality score; we report what the runs show, including the weeks that look bad.
That is the point of building it in your repository. Test code, fixtures, CI configuration and the written strategy sit beside your own code from the first commit, reviewed by your developers as they land. Tool accounts and licences are registered to your organisation, with us as members rather than owners. On the last day we hand over a state-of-quality note and remove our access.
Hire once quality work genuinely fills a week: a permanent tester builds product memory a part-time person cannot. A testing agency runs a fixed round of tests and hands you a report, which helps before a launch and does nothing the month after. Fractional sits between them, and we will not claim it is cheaper than hiring. It buys seniority and continuity at hours you can justify.
When the real work is hours of manual verification every day across a device lab, a slice of a week will not cover it and you should staff it properly. When you need one pre-launch test round and nothing after, that is a project, not an ongoing role. It also fails outright if nobody on your side can grant pipeline access or merge a pull request.
Let’s connect
Let’s talk about the qa & testing engineer gap.
Tell us what is not getting done and roughly how much of a week it needs. We’ll reply within one business day with who would cover it and a tailored quote — no obligation.