A team was heading into a release that was larger and riskier than its usual cadence — a change that touched parts of the product customers depended on, with little room for a bad week afterwards.
The developers were fully committed to building it, which left testing as the thing that would get squeezed. Their instinct, to have the same people who wrote the code also test it under deadline pressure, was exactly the situation in which things get missed.
They needed proper QA capacity for the release window, from people who could test seriously and independently, without taking on permanent testers for a peak that would pass.
What the gap really was
- The release was big enough that testing it properly was beyond the team’s spare capacity.
- Developers testing their own work under deadline is where defects slip through.
- The need was tied to one release, not an ongoing rise in volume.
- The team had to be able to keep testing to a decent standard once we left.
How we approached it
We brought in experienced QA who could get to grips with the product quickly and test it as a user would, not just against a checklist.
They worked inside the client’s process and to its delivery lead, raising what they found early enough for it to be fixed rather than at the point of no return. Independence from the people who wrote the code was part of the value, and we kept it.
Rather than only running tests, the QA we placed left behind the cases and the approach so the in-house team could carry on testing to the same standard. As the release shipped, the extra capacity came off, with the lasting part — better test coverage and a clearer way of working — staying with the team.
Where it stands
The release went out with the awkward cases found before customers met them rather than after. The team came through the window without burning out its developers on testing they were not set up to do. They kept the test cases and the habits, so the next release does not start from nothing.