Confluence review for QA teams: pricing, alternatives and setup

Content lives in spaces, each with its own page tree, permissions and administrators. A QA team typically has one space, or a section of a product space, with a predictable hierarchy: strategy and standards at the top, then test plans per release or feature, environment and test data documentation, and run reports. Permissions are set per space and can be narrowed per page with restrictions, which matters when test documentation includes environment details or customer data that not everyone should see. Every published change creates a new version, so a test plan’s history and who changed the exit criteria are recoverable, and inline comments carry review discussions on the text itself.

With Jira connected, typing /jira in the editor or pasting a Jira search URL inserts a Jira work items element. It can show one work item, a selected set, a list driven by a JQL query with chosen columns, or just the count of matching items linked back to the search in Jira. Atlassian has been renaming issues to work items, and older documentation calls this the Jira Issues macro. Jira permissions still apply: Atlassian documents that the macro shows only the work items the viewer is authorised to see, so a stakeholder without Jira access can see an empty or shorter list than the author.

Space administrators create templates under Space settings, Look and feel, Templates. Templates built in the current editor support variables, typed as text, multi-line text or a list, that the author fills in when creating a page, and placeholder text that disappears when the page is published. Content properties, the macro formerly known as Page Properties, holds a two-column table of keys and values on a page. A report macro on another page collects those tables from every page with a given label into one table, so a test plan template with release, owner, status and sign-off properties yields an automatic register of plans.

Through the API, page bodies are exchanged in Confluence storage format, an XHTML-based markup, or in the Atlassian document format used by the editor. The Confluence Cloud REST API v2 creates and updates pages with a body in storage, atlas_doc_format or wiki representation, which is how a CI job can publish a test run summary. Version 2 endpoints identify spaces by numeric ID rather than key, use cursor-based pagination, and require the next version number when updating a page. Atlassian has deprecated many v1 endpoints in favour of v2, so older scripts and tutorials based on /wiki/rest/api/content need migrating.

Keep the tree shallow and predictable. A workable layout is a space home page with the plan register and links, then four branches: Strategy and standards, holding the test strategy, definition of done and defect triage rules; Test plans, one child page per release or major feature, created from the template; Environments and data, describing each environment, its URLs, owners and test data recipes; and Run reports, where pipelines publish summaries, grouped by month or release. Use labels for cross-cutting views, such as test-plan, regression or performance. Give every page an owner and a next review date in its content properties, so stale pages can be found by a report rather than by accident.

Build the template in the current editor so variables work. Start with a content properties table holding Release, Feature, Owner, Status and Sign-off date, since that table feeds the register. Then add sections for scope and out of scope, approach and test levels, environments, entry and exit criteria, risks with mitigations, and schedule. Use placeholder text to say what good content looks like in each section, because placeholders vanish on publish. Leave room for a Jira work items list driven by a JQL query on the release, such as fixVersion and issue type, so each plan shows its own stories and defects. Templates cannot hold images or attachments, so keep diagrams in a linked page.

Run the publishing script as a step after the tests, with if: always() so failed runs are published too, and keep credentials in repository secrets. Generate the storage format body from the test framework’s JUnit XML or JSON report rather than hand-building it, and link to the full report artefact instead of pasting thousands of rows. Put run pages under a parent page per month or release by passing parentId, otherwise every page lands under the space home page. Pipelines that publish on every commit flood the space; publish for release candidates, nightly runs and failures only.

For a dashboard-style page, such as the current state of the nightly regression, update the same page each run instead of creating a new one. The v2 update endpoint replaces the title and body and requires version.number set to the current version plus one, so read the page first. Confluence keeps every version, so history and comparisons between runs remain available from the page itself. If two jobs update the same page concurrently, one will be rejected because its version number is stale; retry by reading the page again.

Documentation decays faster than code because nothing fails when it goes wrong. Make review part of the release: the release checklist includes confirming the test plan’s status and sign-off properties, and a report macro listing pages whose review date has passed is on the QA space home page. Archive superseded plans rather than deleting them, so audit history survives but search stays clean. Prefer linking to the source of truth, a Jira query, a CI report or a repository README, over copying its content into a page, because every copy is a page that will eventually be wrong.