What’s preventing flow for testers — and what is it doing to us?

Discussions
, ,
1

I recently spoke with a junior tester who has decided to move into development. One of the reasons they gave was constant context switching.

Context switching has been a pain point in testing for years, but I’d never really thought about it as something that could make someone want to leave the profession.

Testers can spend a day moving between sprint work, releases, issues, automation, environments, investigations and supporting other teams. Each switch means rebuilding context before you can properly focus again.

And now AI is increasing the amount and speed at which code can be produced. In organisations where testing, testability, environments and engineering practices haven’t matured at the same pace, I wonder if we’re simply pushing even more work and cognitive load towards testers.

For me, this is becoming less about productivity and more about wellbeing and whether the job remains enjoyable and rewarding.

I’m curious whether others are feeling this lately.

What’s preventing flow for you as a tester? How much context switching are you dealing with, and what impact is it having on your stress, motivation and enjoyment of the role?

And most importantly — what have you seen teams do that actually improves it?

2

the biggest flow killer for me is having five investigations open with none of them left in a resumable state.

what helps is a hard handoff rule before switching: write the question being tested, current browser state, last action, first mismatch, and the next thing to check. if it is a browser bug, preserve the path instead of relying on memory or a screenshot. then coming back is continuation, not reconstruction.

teams can also protect testers by limiting active work, routing interruptions through one person, and treating “can you quickly check this?” as real work that displaces something else. ai producing more code should not quietly become unlimited inbound work for qa.