Stanki Guild

Guide · Confluence

When is "everyone has read it" actually true? Testing read and understood in Confluence

Attestation Flow for Confluence 3.1.0 is the production version (30 October 2026). Last updated 1 November 2026. On the Atlassian Marketplace.

By Bartosz Stankiewicz, founder, Stanki Guild.

The worst thing a read-and-understood tool can do is show green when it shouldn't. A missing name is annoying. A false "all acknowledged" on a security policy is the thing that hurts you in an audit, because someone relied on it.

Most of the ways to get this wrong come from time and change. The page gets edited, so last month's confirmations are for a different text. A group gains a member who hasn't read anything. Jira or Confluence can't tell you who is in a group for a moment, and the app has to decide what that means. A yearly re-read comes due.

The test

#

Every night a server builds random reading requirements: some named readers, one or two groups, sometimes a due date, sometimes "read again every 30 days". Then it plays 30 random events on each: someone confirms, the page gets a new version, days pass, someone joins or leaves a group, the group lookup fails for a moment. Confirmations are written the same way the app writes them.

Next to the app, the test keeps its own simple record of who confirmed what and when, and after every event it compares:

  • the number of people who must read it: named readers plus group members, each person once
  • who counts as done: only a confirmation of the current version, inside the re-read window; a confirmation of an older version never counts
  • green only when everyone required has confirmed and no group failed to load; never green while a group lookup failed
  • each person's status (not required, unknown, read, lapsed, outstanding) matches the simple record
  • a confirmation, once written, keeps its first timestamp
  • overdue only when there is a due date, it has passed, and someone is still missing

A million requirements, about ten minutes a night, a new random seed each time.

Breaking it on purpose

#

We removed the check that keeps the page from going green while a group can't be loaded. The test failed. We removed the 30-day window, so old confirmations counted forever. The test failed. Good. A test that passes whatever you do to the code is worse than none, because it makes you relaxed.

No bug in the app so far.

What it doesn't cover

#

Attachments, calendar-based re-reads, carrying confirmations over a minor edit, and the quiz and minimum reading time are not in the random test yet. I'd add the minor-edit rule next, it's the one with the most judgement in it. The suite runs against the next release; the installed version runs its regular tests every night.

When a policy page changes, do you want everyone to confirm again, or only after real changes?

#