State & Caching Bugs

1 The Hook

A fictional NZ council, Tasman Ranges District Council, ran a rates and consents portal as a progressive web app. A resident reported that after their session had been open a while, clicking “Submit consent application” did nothing visible — the button greyed, then the form came back blank with no error and no saved draft. The test team could not reproduce it. They opened the portal, filled the form, submitted, and it worked every time. Closed: no repro.

The resident was right and the testers were unlucky. The portal used a signed token (a JWT) to authenticate each request, and that token expired after thirty minutes. A fresh tester, opening the portal and submitting within a few minutes, never hit the expiry. The resident, who filled in a long application over the better part of an hour, did. When they finally hit submit, the token was expired; the request failed authentication; and because the app had no handling for “token expired mid-session,” it discarded the unsaved form and silently returned a blank page. The bug only appeared as a function of time and state — never on a quick fresh attempt.

It got worse. After the council shipped a fix, some users still saw the old broken behaviour for days. Their browsers had cached the old version of the app in a service worker, and nothing forced an update, so they kept running the buggy build long after it was patched. Now there were two stale-state bugs stacked on top of each other: an expired token discarding work, and a stale cached app refusing to take the fix.

Here is the lesson hidden in that story. The team tested the form on a fresh session with a fresh build, which is the one state in which both bugs are invisible. State and caching bugs do not live in the steady fresh state — they live in the stale, aged, in-between states that real users reach and testers rarely set up. Finding them means deliberately ageing the state, not refreshing it away.

2 The Rule

3 The Analogy

4 Where State and Caches Live

To test this class of bug you have to know where state and cached data hide in a modern web app. There are several layers, and a bug in any of them can outlive the steady state a tester sets up.

In-session state and auth tokens

The data a session holds while it is open — the form being filled, the user’s logged-in identity, the auth token authorising each request. The token in particular has a lifetime, and that lifetime is the source of the Tasman Ranges bug. Aged in-session state is the most common hiding place for “works on a fresh attempt” defects.

localStorage and stored client data

Data the app writes to the browser to persist across sessions — preferences, a saved draft, a cached identity. It survives a reload, which is its value and its danger: if it is corrupted, partially written, or left over from an older version of the app, every future session inherits the bad data until it is cleared.

The service worker and app-shell cache

A progressive web app caches its own code in a service worker so it can load instantly and work offline. The benefit is speed; the danger is that the cached app can be a stale, old version that keeps running long after a fix ships — the second Tasman Ranges bug. A service worker that does not update correctly serves yesterday’s broken build to today’s user.

HTTP and data caches

Responses cached by the browser or an intermediate layer so they need not be fetched again. The risk is the classic one: cached data that is now wrong — an old rates balance, a stale price, a status that has since changed — shown to the user as if it were current because nobody told the cache it was out of date.

5 The Four Bug Classes

This kind of defect clusters into four recognisable classes. Knowing them turns a vague “no-repro” into a targeted test.

The expired-token race. An auth token expires part-way through a session, and the app handles the resulting failure badly — discarding unsaved work, looping on a failed refresh, or showing a blank screen instead of cleanly re-authenticating and preserving the user’s input. The Tasman Ranges submit-after-expiry is this class. The fix and the test centre on what happens when a request fails because the token has aged out: the user’s work must survive, and they must be re-authenticated, not dumped.

The stale service worker. A cached old build of the app keeps running after a new one ships, so users see bugs that are already fixed or miss features that are already live. The test is whether a deployed update actually reaches a user who already has the old version cached — and how quickly, and whether it can be forced.

localStorage corruption. Stored client data is partially written, malformed, or left over from an older schema, and the app trusts it blindly — reading a half-saved draft, parsing data in an old format, crashing on a value it no longer expects. The test is whether the app validates and recovers from bad stored data rather than assuming it is always well-formed.

Stale cache / failed invalidation. Cached data that is now out of date is shown as current — the old balance, the changed status, the superseded price. The test is whether, when the underlying data changes, the cache is correctly invalidated so the user sees the new value and not the comfortable old one.

6 Cache Invalidation & Versioning

Most of this class comes down to one famously hard problem: knowing when cached data is no longer valid and replacing it. A tester does not have to solve it, but must know the controls that manage it and check they work.

Expiry (time-based). Cached data carries a lifetime, after which it is treated as stale and refetched. Simple, but blunt: too long and users see old data, too short and the cache barely helps. The test is that data does expire and refresh on schedule, and that an expiry chosen for performance has not been set so long that users see dangerously old values — an old rates balance, say.

Versioned assets (cache busting). Static files are given a version in their name or query string, so a new deploy produces new file names the browser has never cached and must fetch fresh. This is the standard defence against the stale-app problem. The test is that a new build genuinely changes the versions and that an old cached asset is not silently served in its place — the exact failure that left Tasman Ranges users on the old build.

Service worker update flow. A new service worker should detect the new build, install in the background, and activate — ideally prompting the user or updating on the next visit, never leaving them stranded on the old version indefinitely. The test is the full update path: deploy a change, load as a user who has the old version cached, and confirm the update is picked up within a defined and acceptable window.

Event-based invalidation. When the underlying data changes, the cache holding it is explicitly cleared or updated, so the next read is fresh. This is the precise control for the stale-balance class. The test is that changing a value at the source causes the cached copy to be invalidated, so the user sees the new value rather than the old one.

7 What to Test for State & Caching

The practical checklist for any app that holds state or caches data:

• Token expiry mid-session: let the auth token expire during a long task, then act — the user’s unsaved work survives and they are cleanly re-authenticated, never dumped to a blank screen.
• The long-session path: deliberately age the session well past any token or cache lifetime before the key action, rather than always testing fresh.
• Stale service worker / old build: a deployed update reaches a user who already has the app cached, within a defined window, and can be forced if needed.
• Corrupted localStorage: seed malformed, partial, or old-schema stored data and confirm the app validates and recovers rather than trusting it blindly or crashing.
• Cache invalidation on change: when source data changes, the cached copy is invalidated and the user sees the new value, not the old one.
• Expiry tuned for safety: cache lifetimes are not so long that users see dangerously stale data — balances, statuses, prices.
• Cross-tab and multi-session consistency: a change in one tab or device does not leave another showing contradictory stale state.
• Clean logout: logging out actually clears stored tokens and sensitive cached data, so the next user of the device does not inherit the last one’s session.

8 Building State & Caching Test Cases

A strong state-and-caching test case sets up the aged or stale state explicitly — it does not start clean — and asserts on what survives and what the user sees. Here is a worked case written to catch the Tasman Ranges expired-token bug:

Notice what makes this catch the Hook bug: the precondition ages the session past the token lifetime rather than testing fresh; the action is to submit after expiry, which is the one state the original testers never set up; the expected result asserts the form is preserved and the user re-authenticated, not dumped; and there is a server assertion that the application is recorded exactly once. The state condition is named at the top so a reviewer knows the session was deliberately aged.

9 Common Mistakes

10 Now You Try

Three graded exercises across the state and caching bug classes. Write your answer, run it for AI feedback, then compare to the model answer.

There are at least four real bugs here; any three well-explained earns full marks.

1. Expired-token race — The 20-minute token expires mid-session and a failed call just shows a blank panel, so a member who lingers loses the view with no error or re-auth. Bug class: expired-token race. When it shows up: only after the session has been open past 20 minutes — never on a quick fresh login.

2. Stale cache / failed invalidation — The balance is cached on first load and never refreshed, so after a contribution the member still sees the old balance as if it were current. Bug class: stale cache / failed invalidation. When it shows up: after the underlying data changes within the same session.

3. Stale service worker (no versioning) — The PWA caches itself with no versioning, so a new deploy may never reach members who already have the old build. Bug class: stale service worker. When it shows up: after a deploy, for users who already have the app cached.

Bonus — localStorage corruption: the last-viewed fund is read on startup with no validity check, so a removed or renamed fund (or a corrupted value) breaks startup. Bug class: localStorage corruption.

The trap: every one of these is invisible on a fresh login with a fresh build — exactly the state a tester starts in.

Test ID: STC-JWT-014

State condition: Auth token expired while the clinician filled a long referral, before submit

Risk category: Referral discarded silently on token expiry mid-task

Pre-conditions: Clinician logged in; token lifetime known; a long referral partly completed but not submitted; the token forced to expire (aged or cleared) before the submit.

Action: 1) Fill the referral. 2) Let the session sit past the token lifetime, or force the token to expire. 3) Click submit.

Expected result: 1) The app detects the expired token and does NOT discard the referral. 2) The clinician is cleanly re-authenticated (silent refresh or re-login prompt). 3) The entered referral data is preserved and the submit then completes. 4) No blank page and no silent failure at any point.

Server assertion: The referral is recorded exactly once with the entered data, after re-authentication.

Evidence required: Token expiry time vs submit time; screen states through the flow; the preserved referral data; the server record of the referral.

Traceability: Risk register R-08 (session expiry discards unsaved clinical work without warning).

What makes it strong: the precondition AGES the session past the token lifetime instead of submitting straight away, the action submits AFTER expiry (the state the original never set up), and it asserts the work survives and the user is re-authenticated, ending on a server assertion of exactly one referral. The original could only ever pass.

STC-01 | State set up: token expired mid-session before a key action | Acceptance criteria: the app preserves the user's unsaved work and re-authenticates cleanly; 0 blank pages or silent failures | Evidence required: token expiry vs action time; preserved data; screen states

STC-02 | State set up: app cached in a service worker on an OLD build, then a new build deployed | Acceptance criteria: the user on the old cached build receives the new build within a defined window (or on next visit); the old build is not served indefinitely | Evidence required: build version before/after; time-to-update; service worker update log

STC-03 | State set up: localStorage seeded with malformed / old-schema / partial data | Acceptance criteria: the app validates the stored data, recovers gracefully (ignores or resets it), and does not crash or show garbage | Evidence required: the seeded bad value; app behaviour on startup; recovery state

STC-04 | State set up: balance cached, then a payment made that changes it | Acceptance criteria: the cache is invalidated on the change so the user sees the new balance, not the old cached one | Evidence required: balance before/after payment; cache state; the value shown to the user

STC-05 | State set up: a logged-in session with stored token and cached personal data | Acceptance criteria: logging out clears the stored token and sensitive cached data; the next user of the device cannot resume the prior session | Evidence required: storage contents before/after logout; attempt to resume after logout

Strong plans: each case sets up a specific aged/stale state, has a measurable criterion, names concrete evidence, and together they cover expired-token (STC-01), stale service worker (STC-02), localStorage corruption (STC-03), stale cached balance (STC-04), and clean logout (STC-05). Weak plans say "test caching works" five times — that is the difference being marked.

11 Self-Check

Click each question to reveal the answer.

12 Interview Prep

Real questions asked in NZ QA interviews for web and PWA roles. Read the model answers, then practise your own version.