QA inside the sprint

"We'll test it at the end of the sprint" sounds efficient — one dedicated testing pass instead of interrupting development all week. In practice it is the single most reliable way to turn a two-day bug into a two-week one, because the person who wrote the code has moved on to the next ticket by the time a defect surfaces.

The cost curve nobody draws

A bug caught while the feature branch is still open costs one conversation and a small diff — the context is still loaded in the developer's head. The same bug caught a week later, after three more branches have merged on top of it, costs a bisect, a re-read of code the developer half-remembers, and a fix that now has to account for whatever shipped in between. We have watched a half-day bug turn into a three-day one purely because of when it was found, not what it was.

What "inside the sprint" actually means

It does not mean no dedicated QA pass. It means QA starts reading the ticket the same day development does, writes test cases against the acceptance criteria before the branch is done, and runs them against each meaningful commit rather than waiting for a "ready for QA" handoff. By the time the feature is code-complete, most of the obvious defects are already found and fixed — the end-of-sprint pass becomes a confirmation, not a discovery process.

• QA reads acceptance criteria at ticket start, not at handoff — ambiguities get caught before code is written around them.
• Test cases are written against the criteria, not against the eventual implementation.
• Every meaningful commit gets a quick pass, not just the final one.

Automation is a multiplier, not a replacement

We write regression suites so the same manual checks are not repeated by hand every sprint, freeing the QA engineer to spend their attention on the new behavior instead of re-verifying old behavior. Automation that only covers happy paths gives false confidence; we weight coverage toward the edge cases a rushed manual pass tends to skip — empty states, permission boundaries, and what happens when a network call fails mid-flow.

test('rejects upload over the 5MB resume limit', function () {
  $response = uploadResume(sizeMb: 6.2);
  $response->assertStatus(422)
    ->assertJsonValidationErrors('resume');
});

The honest tradeoff

Testing inside the sprint costs more visible QA hours per week than a single end-of-sprint pass — it is not free, and clients sometimes ask why the QA line item looks bigger than expected. It is smaller, reliably, than the hidden cost of late-found defects: the re-investigation time, the delayed release, and the fix that has to be threaded through everything that shipped since. We would rather that cost be visible on a timesheet than invisible in a slipped deadline.