When requirements change late, testers decide what goes untested

Most writing about changing a spec mid-sprint counts the cost in rework: the code that has to change, the tickets that reopen. An interview study posted to arXiv on 29 September 2026 points at a cost that is harder to see, because it shows up as work that never happens. When requirements changed late, the testers it interviewed described cutting what they tested to fit the time left, with the decision resting on them.

The study

The paper, by Cristina Martinez Montes and Felix Dobslaw of Mid Sweden University and Pushpamalar Rajendran and Grace Karuri of Chalmers University of Technology and the University of Gothenburg, is about emotional intelligence in software testing. Requirements volatility is one of its three research questions, and the one with the most to say to people who write specs.

The method:

• Semi-structured interviews with 16 software testers in Sweden, all in teams that use agile practices, working in aviation, automotive, healthcare, IT services, administration, banking and pharmaceuticals.
• Participants were aged 26 to 54, with 1 to 22 years of experience, and did manual testing or test automation.
• Interviews were held in person, in English, and ran from 22 to 56 minutes.
• The transcripts were analysed with reflexive thematic analysis, an interpretive method, guided by Goleman's emotional intelligence framework. The analysis produced 146 codes, grouped into three themes.

One interview question asked directly how changing requirements had affected the participant's feelings and their decisions about what to test first. That matters for reading the results, and the authors say so (more below).

What the testers described

The change landed on testing last. The authors set the tester's position against the developer's. For a developer, a changed requirement means rewriting code. For a tester, the same change invalidates test cases, test data, environments and regression baselines, and it shortens the time left to run them, because the release date rarely moves when the requirement does. In the paper's summary of the role, every upstream delay comes out of the tester's time.

The reaction was frustration, and it became a decision. Testers described frustration, anger and disappointment, triggered mainly by changes that forced them to redo work, by unclear requirements, and by releases that still contained unresolved bugs. Those feelings shaped prioritisation: attention shifted to must-pass tests, and exploratory testing and edge cases were deferred.

The authors single out this link as the finding that bears most directly on software quality, and compress it into one line:

For testers, frustration converts into a coverage decision.

Not everyone narrowed. The paper describes three responses: narrowing coverage to must-pass tests, raising the process problem with a manager, and, where requirements were missing, finding workarounds by looking at similar systems. Some participants said adapting simply came with working in an agile team. Elsewhere in the interviews, testers described pushing for structured documentation and regular reporting, and noted that poor documentation could make defects more likely.

The decision sat with the tester. That is what the paper's most concrete recommendation targets. When a change lands late and the window shrinks, the authors write, the team should state in the sprint record which tests are being dropped or deferred and why, so the product owner and developers can see what will go untested. Doing that, in their words, "moves the weight of the coverage decision from the individual tester to the process."

The caveats, from the paper

The authors are direct about what sixteen interviews can carry.

• Small, self-selected and Swedish. Participants were recruited by personal invitation and were likely more interested in emotional topics than people who declined. The sample was chosen for variety, not representativeness. Sweden has comparatively high work autonomy, which the authors think shaped how freely participants described raising problems with managers. They make no claim that the themes hold where speaking up costs more.
• The central finding was prompted. Two interview questions contained potentially leading prompts about changing requirements and specific emotions. The authors write that the interview guide introduced the topic and participants then confirmed and expanded on it, so the findings may partly reflect the questions.
• Self-report, not measurement. Emotional intelligence was not measured with any instrument, and everything rests on participants' recollections. The paper reports themes, not frequencies: it does not say how many of the 16 narrowed their coverage, or how often.
• No comparison group. The authors know of no developer study reporting the same link from frustration to skipped work, but point out that developers under pressure also skip work, such as tests they do not write and refactoring they defer. Whether testers differ in kind is left open. That time pressure by itself lowers the quality of test work is cited from earlier experimental research, not tested here.

Their own list of next questions is the useful one: how often testers narrow coverage under late change, what gets dropped, and whether making the trade-off explicit changes what is dropped.

Why this matters if you change specs

None of this says requirements should stop changing. The testers in the study worked in agile teams where change is expected, and some described adapting as part of the job. The point is narrower: a late spec change has a cost that the change itself does not record.

The change costs coverage somewhere else. The companion post on changing a spec mid-sprint argues that every amendment should carry an Affects line naming the tickets and test cases that encoded the old behaviour. This paper suggests that line is half the story. The test cases that need rewriting are visible. The ones that will now not be run, because the date did not move, are not.

An illustration. Say a permissions rule changes in the middle of a two-week sprint. The Affects line lists the five test cases that checked the old rule. What it does not list is that the tester, rewriting those five, will drop the exploratory pass on bulk invites that was planned for the next day. Nobody decided that. It happened.

What gets cut is predictable. Exploratory work and edge cases go first, and edge cases are exactly what a good spec works hardest to name. If your spec separates the edge cases that must hold from the ones that are worth checking when there is time, a narrowed run can still cover the first group. If it does not, the tester chooses under pressure, without the context you had.

A coverage cut is a scope decision. Shipping with an edge case untested is a decision about what the release promises, and it belongs with whoever owns that promise. One line in the change entry makes it one. In the same illustration: "Not tested this sprint: bulk invite above 50 seats; deferred to next sprint; agreed by owner and QA." That is the authors' recommendation moved into the document people build and test from, rather than a sprint record few people reopen, and it gives the test plan something to come back to.

What to take from it

Not a measured effect. Sixteen accounts from one country, prompted in part by the questions. What they describe is plausible and specific: a requirement changes, the date holds, and the shortfall comes out of testing nobody listed. The cheapest response is the one the authors propose. When the testing plan shrinks, write down what was cut and who agreed, in the same place the change is written.

FAQ

What was studied? Interviews with 16 software testers in agile teams in Sweden, analysed thematically.

What happens when requirements change late? In the testers' accounts, the window shrinks and testing narrows to must-pass tests, deferring exploratory work and edge cases.

How strong is it? Exploratory: small, self-reported, partly prompted by the interview questions, and without frequencies.

What should change? Record what is being left untested, and who agreed, alongside the change itself.