Building a QA Function Inside a Team That Had Shipped Without One
A product company with no QA function was relying on developers testing their own work — conscientiously done and structurally insufficient, because you cannot reliably find the case you did not consider in code you just wrote under a deadline you set. Envion’s QA lead started with incident archaeology instead of tooling: every production issue categorised by area, root cause, and detection point, producing the team’s first real risk map — and it was not the one the team expected. On that foundation: written release criteria, charter-based exploratory practice, a defect triage process with severity definitions agreed in advance, automation started small and high-value in CI, and shift-left involvement at requirements stage. The intended end state was never "one person tests everything" — it was a team that finds the bugs without them.
The challenge
Developers tested their own work, which they did conscientiously and which is structurally insufficient — you cannot reliably find the case you did not consider, in code you just wrote, under a deadline you set.
Nobody on that team was careless. That is the part people get wrong about this situation. Developers testing their own code is not a discipline problem, it is a blind-spot problem — you test against the model of the system in your head, and the bug is always in the part of the system your model got wrong. The symptom that triggered the engagement was a run of production incidents, most of them regressions in features that had previously worked.
Decision path
With no historical defect data to score against, the first two weeks were spent generating some. Incident archaeology: every production issue from the recent period categorised by area, root cause, and detection point — which produced the first real risk map, and it was not the one the team expected. A coverage inventory answered what was tested, by whom, and at what level; most of the answer was "at the end, by the developer who wrote it, manually." And a cost-of-failure conversation with product and commercial stakeholders meant priority could be argued with numbers rather than instinct.
Before writing a single test: know where this product has hurt people before. Incident history is the cheapest risk data a team will ever get, and most teams never read it back.
Envion contribution
Five things were established, in deliberate order. Release criteria, written down — the first artifact, because it makes quality a shared standard rather than one person’s opinion, and it survives after the engagement ends. Exploratory testing as a practice, not an activity — charter-based sessions, time-boxed, with findings recorded so the sessions compound instead of repeating. A defect triage process with severity definitions everyone agreed to in advance, because arguing about whether something is a blocker during a release is the most expensive time to have that conversation. Automation started small and high-value — critical-path tests in CI before anything else, so the team saw a red build catch a real regression within the first weeks; adoption depends on that moment more than on any document. And shift-left habits — QA involvement at requirements stage, where a testability question costs a conversation and later costs a sprint.
Delivery
The intended end state was not "the QA engineer tests everything." It was developers owning unit and integration coverage, QA owning risk assessment, exploratory depth, and release criteria, and product owning the cost-of-failure input that makes prioritization possible — built for handover from the first week rather than at the end.
If quality depends on one QA engineer being in the room, you have not built a QA function — you have hired a bottleneck.
Outcome and evidence
The team moved from end-of-cycle judgment calls to a shared, written standard for "are we ready?", with automation catching regressions in CI before release. Outcome instrumentation — production incidents per period, regression incidents as a share of total, defects caught pre-release versus post-release, time from bug report to triage decision, and critical-path automated coverage at handover — is tracked by the client's team rather than asserted here.
The toolkit
The toolkit this practice runs on
Tool choice follows the risk model, not the other way round — the stack for each engagement is selected after the risk map exists, not before.
From the engagement lead
What I’d tell anyone considering this
“My job is not to be the person who finds the bugs. It is to leave behind a team that finds them without me. If quality depends on one QA engineer being in the room, you have not built a QA function, you have hired a bottleneck.”
Evidence gate. This page publishes only what Envion's project records and client disclosure permissions support. Outcomes are added once verified against a baseline, a measurement period, and an approved source.
FAQ
Questions about this case
Facing a similar challenge?
Shipping on developer self-testing and crossed fingers? Envion builds the QA function around your team — criteria in writing, risk mapped from your own incident history, ownership that outlives the engagement.
Discuss a Similar ChallengeKeep exploring
Similar case studies
Executive Technology Leadership
Support for high-stakes product and AI decisions
Bring senior technology leadership into the business when the roadmap is unclear, delivery is at risk, an AI initiative needs stronger ownership, or the company needs an experienced technical voice before hiring a permanent CTO.
Discuss Interim CTO SupportCore responsibilities
- Align product and technology priorities with business goals and measurable outcomes.
- Review architecture, delivery risks, data foundations, security needs, and AI readiness.
- Lead internal teams and external partners through a practical execution plan.
- Clarify team structure, ownership, decision rights, and delivery cadence.
- Support investor, board, partner, and due-diligence conversations with credible technical judgment.
New experience
Prompt-to-Page — try it right here
Describe the landing page you want, in your own words. We turn it into a finished page and email you a private link in 5–10 minutes — no briefs, no calls, $0 to see the result.
- Describe what you want to create.
- We structure, write, and compose the page.
- You receive a private link when it is ready.
Start with a sentence — the interactive builder takes it from there.
Generate My PageSafe, respectful content only. No obligation.