Your first week as the first QA hire usually looks the same regardless of the company. The bug tracker has 400 open tickets and nobody can tell you which ones are still real. Releases ship when the developer who wrote the feature feels done. Someone shows you a folder of automated tests that nobody has run in months. And leadership expects you to "add QA" — by which they usually mean "start writing automated tests immediately."
That last expectation is the one to push back on. After setting up QA functions from zero across dozens of engagements at DeviQA, the pattern I keep seeing is this: the first 90 days are mostly process archaeology and documentation, not test execution. Audit what exists, fix the bug tracker, write down what "working" means, then build smoke and regression suites and release gates. Automation comes last, because automation can only encode a process that already exists. Build it first and you encode the chaos.
Why developer-owned testing breaks down (and when it doesn't)
The failure mode is systemic, not a skills problem. Developers can test — they write unit tests, they check their own features. What's missing is ownership of the quality signal: nobody maintains the bug backlog, nobody defines what must pass before release, nobody tests the paths that cross feature boundaries.
BiznessApps, a DIY mobile-app platform for small businesses, is the cleanest example I've worked near. Before a QA function existed, developers were responsible for testing and executed it chaotically: the bug tracker was poorly set up with a messy board, bug reports were unstructured and uninformative, there was no test documentation, and releases were random, not preceded by thorough testing. The result was predictable — major and critical issues kept reaching production. None of that traces to bad developers. It traces to a testing process that no one owned.
The honest caveat: pre-product-market-fit, developer-owned testing can be a rational trade-off. If the product may not exist in six months, a dedicated QA process is overhead. It stops being rational the moment production incidents start consuming more engineering time than a QA function would cost — and at the macro level that cost is enormous: CISQ estimated poor software quality cost the US economy $2.41 trillion in 2022 (an older figure, but the most comprehensive one available). If you're being hired as the first QA engineer, someone has already decided the trade-off flipped.
Days 0–30 — audit before you change anything
The instinct on day one is to start fixing. Resist it. You can't prioritize what you haven't inventoried, and the audit is what turns "everything is broken" into a ranked list.
What a testing audit actually looks at
Four things, in order of how much they'll shape your next 60 days:
- The release flow as it actually happens. Not the documented one — the real one. Who decides a build ships? What gets checked, by whom, in what environment? At BiznessApps the answer was "releases were random," and knowing that early meant release criteria became a 60–90 day priority rather than an afterthought.
- The bug backlog's signal-to-noise ratio. Sample 50 tickets. How many are reproducible from the report alone? How many are already fixed, duplicated, or obsolete? The DeviQA team at BiznessApps began by retesting all legacy issues before changing anything else — tedious, but it's the only way to learn the product's actual state.
- Environments. Can you get a stable test environment that isn't production? Can you get test data? If not, that's a blocker to escalate in week one, not month three.
- Existing automation. Run whatever scripts exist and read what they assert. At RevenueHero, a lead-conversion platform, the audit found that the existing automation scripts were useless because they didn't check the required functionality. Green checkmarks, zero information. That's what automation built without a process underneath looks like — and it's why "just write tests" is the wrong day-one instruction.
One warning from experience: timebox the audit to two or three weeks. An audit that runs longer becomes a deliverable in itself, and you were not hired to produce a report.
Fix the bug tracker before writing a single test case
This is the highest-return early win, and it's unglamorous. An unusable board hides the product's real state from everyone — you can't build a regression suite around bugs you can't trust, and you can't argue for release gates when nobody agrees on how many open criticals exist.
The fix has three parts, all visible in the BiznessApps engagement: the Jira workflow was redesigned, obsolete entries were purged after retesting, and a bug-report template was introduced to formalize reporting — expected vs. actual behavior, reproduction steps, environment, severity. At Shops, a digital-products platform where QA had previously been one engineer verifying tickets, optimizing the Jira setup was likewise part of moving to a real process. This matters more than it sounds: per the State of Testing 2025 report, 77% of teams run their testing work through Jira, so the tracker effectively is the quality database. A minimal template that works:
Summary
One sentence: what is broken, where.
Environment
App version / branch, browser or device, test account.
Steps to reproduce
...
...
Expected / Actual
Expected: ...
Actual: ... (screenshot or log attached)
Severity
Blocker / Critical / Major / Minor — per the agreed definitions, not gut feel.
The trap here is political, not technical. The tracker is the developers' daily workflow, and redesigning it unilaterally breeds resistance that will follow you for a year. Propose the template, run it on your own reports for two weeks, show the difference in triage speed, then ask the team to adopt it.
Days 30–60 — test documentation and the first smoke suite
With a trusted tracker, write down what the product is supposed to do — starting from the critical paths, not from a coverage spreadsheet. Which flows, if broken, cost money or users within hours? Signup, checkout, the core workflow. Document those as structured test cases first; the smoke suite falls straight out of them.
Motion, a workflow-management platform, is the reference point for what this phase realistically produces. The starting state was absolute zero: no documented test cases, no smoke or regression testing, no automation, no CI integration. One full-stack DeviQA engineer built 80 structured, reusable test cases plus regular smoke and regression testing — and the whole engagement, including the automation that came later, ran five months. That's the honest scale for a first quarter with one person: dozens of solid cases covering critical paths, not thousands.
Don't chase full coverage on paper. Arklign, a dental-tech case-management platform, also started from nothing — no test cases, no release process, no QA process at all — and eventually reached 5,000+ web and 2,000+ mobile test cases at 95% coverage. "Eventually" is doing heavy lifting in that sentence: the engagement started in 2016. Writing five thousand cases in month two produces a documentation graveyard; writing forty that people actually run produces a smoke suite.
Days 60–90 — regression suite and release criteria
The regression suite grows outward from the smoke suite: same structure, wider coverage, organized by feature area so it can be split across people and later across automation threads. At Shops, that meant 500+ test cases covering more than 75% of the platform's functionality, with regression executable in one working day and smoke in under an hour — by a team of two, built over two years.
But the release criteria matter more than the suite's size. A regression suite answers "what do we check?"; release criteria answer "what must pass, and who signs off?" — and that second question is the one nobody has answered in a developer-owned setup. This is standard practice everywhere QA is established: 86% of testing teams have a say in release readiness per the State of Testing 2025 survey. A workable first version fits on one page: smoke suite passes 100%, zero open blockers or criticals, regression executed on release candidates, named sign-off.
BiznessApps shows where this leads. A clear release flow was established and QA joined the work on acceptance criteria; after the platform's rebuild, releases went out with zero major or critical production issues, support issues dropped by more than 50%, and testing surfaced over 1,700 issues including 300+ blockers along the way. Two honest qualifiers, though. That engagement ran six QA engineers over four years — your 90-day goal is a gated release, not that end state. And the support-ticket drop can't be attributed to QA changes alone; a lot changed at once, including the rebuild itself.
The automation roadmap is a 90-day output, not a day-one input
By day 90 you have what automation actually requires: documented critical paths, a smoke suite that's stable when run manually, and bug data showing where regressions cluster. The roadmap is now mechanical — automate the smoke suite first, then the regression cases with the highest execution frequency and the least UI churn.
Run in this order, automation compounds fast. At Motion, the same five-month engagement that started with zero documentation ended with 75+ automated end-to-end tests in Playwright and TypeScript, structured with the Page Object Model, running nightly and pre-release through GitHub Actions, covering 90% of critical features — and 40+ bugs logged, 7 of them critical. The nightly cadence is the part worth copying on day one of automation, and it's a few lines of CI config:
.github/workflows/nightly-e2e.yml
on:
schedule:
- cron: "0 3 * * *" # nightly, before the team's day starts
workflow_dispatch: # and on demand before a release
jobs:
e2e:
runs-on: ubuntu-latest
steps:
uses: actions/checkout@v4
run: npm ci && npx playwright install --with-deps
run: npx playwright test --project=smoke
RevenueHero shows the same sequence at larger scale: after the useless legacy scripts were replaced with independent tests using API-driven data creation, the suite grew past 200 scripts and 70 API scenarios, coverage exceeded 90%, and full regression now runs in 1.5 hours. Arklign's automated smoke runs in 10 minutes across 900+ E2E and 100+ API tests, supporting 100+ web releases. One caution when you take these numbers into a planning meeting: they're ongoing-engagement figures — RevenueHero has been running since 2022, Arklign since 2016. They're the ceiling the first 90 days makes reachable, not a Q1 target.
There's also a broader reason the sequencing question matters right now. GitLab's 2025 Harris Poll survey of 3,266 DevSecOps professionals found teams losing about 7 hours per person per week to inefficient processes — automating on top of an inefficient process just executes the inefficiency faster.
What this won't fix
A QA process makes the product's state visible and releases deliberate. It does not fix poor requirements — you'll surface ambiguity earlier, but someone still has to resolve it. It doesn't conjure test environments or test data where none exist. It doesn't replace headcount math: every case above had dedicated QA staffing, from one engineer at Motion to six at BiznessApps. And it doesn't mean developers stop testing — unit tests remain theirs; what moves to QA is ownership of the integrated quality signal. One more disclosure, since this article leans on them: the case evidence here comes from vendor case studies, including our own. They're real engagements with real numbers, but they're not controlled comparisons, and I've tried to flag the limits of each as they came up.
Day 90, done right, looks modest on paper: a tracker the team trusts, documented critical paths, a smoke suite anyone can run, a gated release with named sign-off, and a ranked automation backlog. The 90%+ coverage and zero-critical-release numbers in the case studies above are multi-year outcomes. The first quarter doesn't deliver them — it's what makes them possible. Reach for this sequence when you're the first QA hire walking into developer-owned testing; skip the process-heavy version if the product is still searching for market fit and a failed release costs you nothing but a redeploy.
