What's your approach to testing in agile teams when requirements change mid-sprint?

Mid-sprint requirement changes are the agile reality, not the agile failure. The question is whether your testing approach absorbs them gracefully.

Be in the conversation early. If you find out about the change in the sprint review, you've lost. Three-amigos sessions on each story (PM + dev + QA) catch ambiguity before development; daily stand-ups surface scope shifts mid-stream. Most "the requirement changed" stories are really "the requirement was always ambiguous, and we discovered it late."

Keep the test design lightweight. If your tests are 50-step scripts, a small spec change means rewriting the whole script. If they're small, behaviour-focused, and use shared helpers, a spec change usually means updating one or two cases. Lightweight test design is what makes agile testing possible.

Treat the change as scope, not as work-creation. When the spec changes mid-sprint, the QA effort changes too. The right response isn't silently working overtime; it's "this change adds 4 hours of test work, here's what we'd cut to fit it in the sprint, or do we want to extend the sprint?"

Automate the stable, manual the volatile. During a feature's design phase, automating tests is expensive because the tests change daily. Wait until the spec stabilises (often the last few days of the sprint) to invest in automation. In the meantime, exploratory testing keeps coverage going.

Push back on undefined acceptance criteria. "We'll figure it out" is not an acceptance criterion. Either negotiate concrete criteria or flag the story as not-ready-to-accept.