Nexus — Product guide

Test management that lives inside Jira. For QA leads, testers, release managers and Jira administrators evaluating or rolling out Nexus.

What Nexus is

Nexus adds test management to Jira Cloud without asking your team to leave Jira. Test cases, test sets and test executions are real Jira issues, with real workflows, links, permissions and JQL. Everything Nexus adds (steps, runs, data sets, environments, releases, reports) sits on those issues or inside the Test Hub page of each project.

Nexus is available now on the Atlassian Marketplace, with all features included. This guide covers the Nexus 2.0.1 product baseline. Check your installed version and project settings before rollout; administrators can disable optional capabilities, and Jira permissions still govern access.

Every Nexus site gets:

• test design, repository, cycles, manual and exploratory runs;
• test data sets, versions, the personal-data scanner and data-driven runs;
• CI results ingestion and the CI API;
• the environment catalogue, deployments, releases and readiness gates;
• reports, saved views, dashboard gadgets, JQL functions, digests, Confluence and Excel export;
• rule-based requirement checks, impact scoring and Quality Score;
• model-based testing (state machines and decision tables);
• AI requirement analysis and AI test generation, one requirement at a time;
• direct migration connectors for Xray, Zephyr and AIO Tests.

Prices scale with your Jira user tier; see pricing on the Atlassian Marketplace, which also manages licensing and billing. Nexus is free for up to 10 users. AI features run on your own AI account (Anthropic, OpenAI, Google, Moonshot Kimi or xAI Grok), so Nexus never bills you for AI usage and sets no usage cap of its own. Until a Jira administrator connects an AI account, Nexus uses no AI and every other feature works as normal.

Get a project ready

Both company-managed and team-managed projects are supported, with different setup paths:

• Company-managed: a Jira administrator opens Nexus Setup (Apps menu) and presses Create now. Setup creates the Test Case, Test Set and Test Execution work types, statuses, workflows and guard rules. The administrator then adds the three work types to the project and checks its health.
• Team-managed: a project administrator first creates the three work types in the project's settings, then uses Nexus Setup → Team-managed Projects to detect them and configure the project's statuses and workflows. Follow any manual rule-attachment instructions shown by Setup.

Setup shows a live checklist and health check. You can add a sample project or sample data to try everything first.

Built to stay fast for large teams

The Test Repository and test-case pages read Jira data directly from the user's browser. This reduces server-side Jira calls: the verified development build made about four per test case opened, compared with 40–49 previously. In the verified checks, the Associations tab was about three times faster and repository and cycle pages were up to 20% faster. These measurements do not establish a concurrent-user limit.

Project settings to decide early

A project admin sets these in the Nexus tab under Project Settings. All are off, or keep today's behaviour, until you change them:

• Test case folders → Folder required. Every test case created or copied in Nexus must go into a folder. Cases made in Jira's own Create dialog, by AI, by import or by a migration are not checked.
• Execution behaviour. Assign the run to whoever records its result (only if the run is unassigned, or always; results recorded by hand only). Count failed runs as done is on by default; turn it off and a failed run stays "to do" in progress figures.
• Bugs Nexus creates. Priority, assignee, components, labels, a summary template and description header text for the Bugs Nexus raises.
• People → Restrict @mentions to project people. By default anyone who can browse the project can be @mentioned in a Nexus comment; this limits it to the people in the project's Jira roles.

Execution behaviour settings apply once the project uses its own settings rather than the site defaults.

Tour the Test Hub

Open a Jira project and select Nexus in the project navigation. The Test Hub is the working area for that project. Its pages share the same Jira issues and links, so moving between them changes the view of the work, not the underlying record.

The top bar also has Create for common Nexus records. The gear menu opens My Settings, Project Settings, Import / Export and Audit Log. Help explains the page you are on. A Test Case opens in the Test Hub in place of the Cases list, so you can edit it and return without losing the repository context.

Nexus also puts the same work on Jira issues: Test Steps on a Test Case, Run on a Test Execution, Cycle on a Test Set and Testing on a requirement. Use those cards when you are already working on the Jira issue; use the Test Hub when you need project scope, filters, comparison or coordination.

Use Modules beside the settings gear to see which optional tools are enabled. Project administrators can change those switches; other users see their current state and can ask an administrator to enable a tool. Switching a module off keeps its data.

Configure Nexus

Settings are split by scope. This prevents a tester's preference from changing a project rule, and prevents one project's process from changing another project.

My Settings: choices for one person

Open the gear menu and select My Settings. Today this page sets your default project, used to pre-select a project in cross-project pickers such as reporting. It does not change the project you have actually opened and does not affect anyone else.

You can also choose Compact navigation, grouping pages into five areas, or Expanded navigation with individual tabs, where those options are available. Use Ctrl/Cmd+K to search Nexus and pin shortcuts to pages you use often. These personal choices keep the same pages and Jira permissions.

Project Settings: how this project works

A project administrator opens gear → Project Settings. Each section has its own Save action; a change applies to this project only. Site defaults continue to apply until the project opts into its own value.

Several sections are deliberately read-only summaries of Jira configuration. Nexus uses Jira's priorities, permissions and workflows instead of maintaining a second security or status model. Follow the link from the summary when the change belongs in Jira.

General Preferences deserves an early review. It controls the Nexus work types in the project, what counts as a requirement, folder rules, execution behaviour, Test Case types and the defaults for Bugs Nexus creates. Changing these after a large library is in use can alter what new work requires, so agree the rule with the QA lead and project administrator first.

Workflow Manager is a health view and repair point. It shows the three workflows Nexus provisioned and whether their validators, conditions and post-functions are attached. Run it after someone edits Jira workflows, after an app upgrade, or when a transition no longer enforces the expected rule. Use Auto fix or the guided Jira step shown by Nexus; do not create a second parallel workflow with similar names.

Nexus Setup: site administration

A Jira administrator opens Apps → Nexus Setup for settings that affect the whole site:

• provision and health-check the Nexus work types, statuses, workflows and project roles;
• set up individual team-managed projects and repair drift;
• connect the site's AI account and choose the provider and model;
• create sample data for evaluation; and
• export or restore a whole-site or project backup.

Project administrators can open the site-wide destination from the link at the bottom of Project Settings, but Jira still enforces the administrator permission required for site changes.

Change settings safely

1. Record the behaviour you want to change and which project or site it belongs to.
2. Change one related group at a time and press that section's Save button.
3. Run a small proof: one transition, one manual result, one CI delivery or one AI draft.
4. Check Audit Log, Workflow Manager or the relevant delivery log for the recorded outcome.
5. Copy settings to other projects only after the pilot behaves as expected.

Understand the workflows

Nexus uses real Jira workflows. Conditions decide who may attempt a transition; validators decide whether the record is ready; post-functions update traceability, coverage and defects after the transition. The result is visible to Jira Automation, JQL, boards and dashboards.

Test Case workflow

Mark Ready checks every project-required field. When the project requires steps, each step also needs an expected result. A case cannot become Obsolete while it has linked Not Run or In Progress executions. Once a case has terminal execution history, Nexus locks the steps unless the case is In Repair, preserving what earlier evidence meant.

Test Execution workflow

Manual and automated results use the same post-transition path, so coverage and defect behaviour do not depend on how the result arrived.

Test Set and cycle workflow

Use the Jira Test Set status and project permissions to control completion.

End-to-end delivery workflow

1. Define scope. Start with Jira requirements and choose the sprint, Fix Version, release or JQL scope that matters.
2. Design and trace. Create Test Cases in Cases or MBT, link each to the requirement with Tests, review the design and mark it Ready.
3. Assemble reusable scope. Put stable groups into Test Sets such as smoke, checkout or regression. Avoid rebuilding the same selection for every cycle.
4. Plan the run. Create a cycle, choose environments and data, add cases, set assignees and confirm the planned count before execution starts.
5. Execute through one record. Testers record manual evidence and CI sends automated evidence. Both create Test Executions and update the same coverage model.
6. Triage failures. Link or raise a Jira Bug, keep the failed execution, fix the product, then add a new run for the re-test. Do not replace the failed evidence.
7. Check currency and coverage. A newer deployment can make an older pass stale. Use Coverage and Environments to find the exact tests that need another run.
8. Decide and retain evidence. Review release gates, investigate exceptions and record the go/no-go sign-off with the release evidence.

1. Design tests

Choose the right test design

A test case is a Jira issue. It has its own workflow (Draft → Ready → In Repair → Obsolete), links to the requirements it tests (Tests), and appears in JQL, boards and dashboards like any other issue. Mark Ready applies the configured required-field and design rules. A design is mandatory when the project or workflow rule requires it; every existing step in a step-based case needs an expected result. Steps are locked while an execution is in progress.

Choose the design that fits the test:

• Step table: action, data and expected result per step, with preconditions, inline images and a size meter.
• Gherkin (BDD): Feature and Scenario text. Each Gherkin test case exports as a .feature file tagged with its issue key, so Cucumber results map straight back.
• Checklist: a list of items, each recorded Pass, Fail or N/A.
• Free text: a narrative or checklist of up to 8,000 characters, recorded as one result per run.

Format when it helps. Test steps, preconditions and free-text cases support bold, italic, inline code, code blocks, bulleted and numbered lists, and links. Use the small toolbar and preview to check readability. Existing plain cases remain untouched until someone turns formatting on.

Edit steps quickly. Find and replace works across a test case's actions, test data and expected results (match case, whole word, all or selected steps). Tick several steps to delete them at once; both come with an Undo, and nothing is saved until you press Save.

Reuse, parameterise and version

Step Library. Project administrators curate reusable manual steps in Project Settings. Insert a library step into a case, keep its link for shared updates, or detach it for a local variation. Review the impact preview before applying a library change to linked cases. This complements calling another test case; it is a separate reuse tool.

Typed step fields. Add structured values such as dates, radio choices, multi-select choices and people to steps. Project administrators define the fields and options so testers can record consistent information alongside the action and expected result.

Reuse instead of copying. A step can call another test case in the same project; the called steps expand when a run starts and every caller is flagged for review when the called test changes. Shared libraries let you copy a test case into another project with a link back to its source, so you can see when the original has moved on.

Parameters and datasets. Write the steps once with <<<name>>> tokens and give the test a table of values; every run then has one iteration per row. A Test Configuration (for example "Staging, Chrome") can override values for a whole run.

Versions. Save a version of a test case's steps with a note, compare any two versions step by step, and restore an earlier one. A version is also cut automatically each time the test case reaches Ready. Up to 50 versions are kept per test case. Archive a version to hide it without deleting it, and choose to copy the test case's comments into a new version (the newest 50; restricted comments are never copied).

Test Case branches. Where branches are enabled for the project, keep an alternative design on the same Test Case, compare it with Main and choose the design when planning or running a test. Promotion to Main requires a reason and a conflict check; it replaces Main rather than merging text automatically, and preserves the previous Main as a branch.

Generate coverage from a model

Model-based testing. Draw a feature as a state machine, or fill in a decision table, and Nexus generates ordinary test cases from supported paths and rules, with no AI involved. Generation is bounded; review any truncation or skipped-case warnings before relying on coverage.

Organise and migrate the library

Organise the repository. Nested folders, search with filters and saved views, bulk actions, custom fields (up to 20 per work type, optionally required), and Test Sets that work either as reusable libraries or as execution cycles. Reorder folders with Move up / Move down or by dragging, create a subfolder in place, and move cases into a new folder from the Move to picker; a copied test case stays in its folder. A custom field can carry a short description that testers see as its "?" help, and a field can be deleted together with its stored values. Selected test cases can have their Automation Key set in bulk (up to 50 at a time, for example {caseKey} for each case's own key), their requirement links removed in bulk, and their custom field values updated from a CSV file after a preview. People pickers list you first.

Retire and bring back. A test case you no longer need is marked Obsolete. It is then left out of new cycles and ignored by automated results. If you retired it by mistake, Reopen it from the test case page and it goes back to Draft.

Remove and recover. Deleting a Test Case, Test Set or cycle through Nexus moves it to Trash, where authorised users can restore it. Use Obsolete when you want to retain a case in the library as retired; use Trash when you want it removed from the working lists.

Moving from another tool. Import starts with "Where are your tests coming from?", shows how to export from that tool, maps the columns of its CSV automatically, and lists what it found and what will not carry over before anything is written. A file can carry each test case's owner (matched to a person who can be assigned in the project) and its requirement links, and required Nexus custom fields are checked in the preview. You can export a folder with or without sub-folders as CSV, JSON, Excel or Cucumber .feature files. Import .feature files into folders using their @folder: tags. Test Sets and cycles support JSON export and import for a round trip, plus CSV export. Imports preview first and can be undone. Check a representative sample and the supported fields before depending on an export for migration or recovery.

2. Manage test data

Tests often say "log in as a customer with an overdue invoice" and nobody knows which customer. Nexus keeps governed, synthetic test data next to the tests that use it.

Keep data repeatable and safe

• Data sets live on the project's Test Data page. Each set has typed columns and rows with a row key such as cust-3. You edit a draft and publish it as the next version; a published version never changes, so a past run always shows the data it used. Versions can be compared row by row.
• Classification and scanning. Every set is marked synthetic, masked or sensitive. A scanner flags likely real personal data on import and edit: card numbers, New Zealand IRD, NHI and bank account numbers, phone numbers, and e-mail addresses outside reserved test domains. Real card numbers are always refused; the payment providers' public test numbers are allowed. Values in a sensitive set are masked for everyone, and revealing one is logged.
• Environment scoping. A data set can be limited to the environments it is valid in, so a run in Production cannot pick up Staging-only accounts by mistake.
• CSV import and export handle large sets (5,000 rows by 50 columns round-trips exactly), with a preview of how each value will be read and protection against spreadsheet formula injection.
• Linking and running. Link a data set to a test case, pinned to a version or following the latest. Steps use the same <<<name>>> tokens as parameters, and the step editor offers an "insert value" picker. A run then has one iteration per chosen row inside one Test Execution, never one Jira issue per row. Planning a cycle can bind each test case's data at the same time.
• Traceability. Linking, running, exporting and revealing are recorded, so every data row can be traced to the test cases and runs that used it. Old usage records are removed by the same retention settings as the rest of Nexus.

3. Plan and execute

Plan a cycle

Test Plans. Capture scope, strategy, risks and entry/exit criteria alongside the cycles. Plans support status, comments, links, change history and administrator-defined fields. A dynamic plan selects Test Cases using structured rules or JQL: preview the membership, refresh it when needed, and start a cycle from one recorded generation. Closing the plan freezes its membership; a cycle keeps the scope copied when it was created.

Cycles. A Test Set can be an execution cycle: add test cases, assign testers, and Nexus creates one Test Execution per test case. Cycles show progress and the runs in scope.

Several environments at once. When you plan a cycle from a set of test cases, pick more than one environment and Nexus plans one run per test case and environment, for example "40 cases × 4 environments = 160 runs" (up to 1,000). The cycle's own Add Cases picker works the same way.

• Choose your columns. A Columns button on a cycle's execution screen shows test case fields (priority, owner, components, labels, automation and your own custom fields), latest-run fields and cycle fields. Your choice is saved for you, per project.

Execute and capture evidence

Execution Mode and My Testing. Start or resume a cycle's testing queue from the cycle or your personal work. Execution Mode keeps one test in focus: record and save its result, then move to the next test. Your place is remembered per cycle. My Testing brings execution, reviews and failures together; Quick View drawers let you inspect related work without losing your place.

The manual runner. Testers run step by step in the issue's Run card or the Test Hub: record a result per step, attach screenshots and files as evidence, see elapsed time against the estimate, and log time to Jira if your project uses worklogs. A failed step can create a Bug that is already linked to the run, the test case and the requirement. Starting a run is protected against two people starting the same execution at once.

Defects are Bugs. A Bug raised from a run can be linked to the requirement in the same step (Also link to the requirement, ticked by default). The Bugs Nexus raises use your project's Bug settings, and the description header text goes above the failure details. Only Bug-type issues count as defects in Nexus reports, the Defects tab and the requirement's Testing panel.

Comments with @mentions. Type @ and a name in a Nexus comment box (test case comments, a run's Comments, the linked-issue view) to mention someone, up to 10 people per comment. Jira sends its own "mentioned you" notification.

The requirement's Testing panel lists each linked test case with its run count and last result, and an Open in Nexus link. It has a Defects tab, Show failed steps for a case whose latest run failed, sorting by key, result or last run, a Hide obsolete switch, and a quick Pass / Fail for a case's newest Not Run run, behind a confirmation.

Exploratory sessions. Run a timed session against a charter with no test case behind it. Record findings as you go (note, outcome, evidence), raise a Bug from a finding in one click, and keep the session log with the cycle.

Offline UAT. From a cycle, choose Execute offline to export an Excel or CSV worksheet for testers working outside Jira. Choose whether to include steps, distribute the worksheet, then import the completed results and review conflicts before applying them. The authorised Jira user performs the export and import; sharing a worksheet does not grant Jira access. Keep exported evidence under your organisation's data controls.

Environment context on runs. Record an environment for each run that needs environment-aware evidence. Nexus can preserve the selected or planned environment and optional build, commit and component. Runs without environment context cannot establish deployment currency.

4. Connect CI

Store and review Playwright scripts

Where enabled, a Test Case can hold a Playwright script with versions, review and approval. New versions start as drafts; approve the version intended for runs according to your project's policy. Locator repairs remain suggestions: accepting one creates a new draft for review, while assertion changes require manual review. A repaired test passing once does not establish that its assertions still prove the intended behaviour.

Keep Cucumber features in sync

Nexus API v1 can read and update a Test Case's Cucumber .feature content. Compare repository changes before writing, use revision checks to protect newer Nexus edits, and review conflicts explicitly. See the API reference for scoped access and the downloadable OpenAPI contract.

Start a run from Jira; execute it in your infrastructure. From a cycle, Run in CI can start GitHub Actions, GitLab.com, Azure DevOps Pipelines or Bitbucket Pipelines. A project administrator connects the target, branch, workflow or pipeline and access token once. Nexus sends only the selected context values and results return to the same cycle. Tokens use Forge secret storage, are never shown again, and are deleted when the connection is removed. A double press within 60 seconds is blocked and every request is recorded in the audit log. Self-hosted Jenkins or GitLab uses the customer-hosted Nexus runner. See service setup and example pipelines.

How a CI result becomes Jira evidence

• One endpoint per site, one API key per project. A project admin creates an API key in the Nexus project settings, on the CI page (shown once, stored only as a salted hash, revocable). CI posts results with Authorization: Bearer <key> and ?project=<KEY>. When you create a key, choose what it Can use: send results, the CI API, automation runner or read test data. Read test data is off by default and is never added to existing keys.
• Formats: JUnit XML (JUnit, pytest, Cypress and Playwright's JUnit reporter), Robot Framework output.xml, NUnit 3 XML, TestNG testng-results.xml, Cucumber JSON, xUnit.net v2 XML, Mocha JSON, mochawesome JSON, Playwright JSON and a plain JSON format. Nexus detects the format, or you name it with &format=. Playwright, Selenium with pytest, Cypress, Cucumber, JUnit and Mocha have been verified against the current development build. Robot Framework also works.
• Matching is exact. A result is matched to a test case by the Automation Key in the test's title (for example NEX-123: login works) or, for Cucumber, a scenario tag. Where a name can't start with a key, the key can sit inside it (test_login[NEX-11]), be written as NEX_11 for Java, .NET and Python names, or be set as a test_key property or trait. A result with an unknown key is counted as unmatched in the delivery log rather than guessed, because a wrong match is worse than none. A result for an Obsolete test case is skipped and counted, never recorded.
• Context: add &environment=, &build=, &commit=, &component= and &testSet= to put results in the right place. With &dataSet=<id>, a test named login works [cust-3] becomes the cust-3 iteration of one data-driven run.
• The CI API does more than results: create or update test cases (idempotently, with your own external key), add one or several (up to 25) to a cycle, record a single result, set or clear a run's assignee, and record a deployment or an environment event, in batches of up to 25 operations.
• What happens on receipt: Nexus reuses or creates the Test Execution, links it, snapshots the steps, rolls up the result and transitions the issue, exactly as a manual run would. One bad result never stops the rest of the batch. The last 100 deliveries are listed on the project's settings page.

Copy-paste pipeline steps for GitHub Actions, GitLab CI, Jenkins, Azure Pipelines and Bitbucket Pipelines are in Sending test results from CI.

Ready-made integrations

You don't have to write the upload step yourself. Download a helper from the integrations page: a Playwright reporter, a pytest plugin (Selenium suites included), a GitHub Action, or the nexus-upload command-line tool for any other CI system. Each reads your results URL and API key from CI secrets, never prints the key, and retries once if the network drops.

Use the Nexus reporter for Playwright, the Nexus pytest plugin for Selenium, the Cypress reporter or JUnit upload, Cucumber JSON upload, JUnit XML upload, or mochawesome JSON upload for Mocha. Results match by Automation Key or issue key, record pass/fail per run, and failed runs can raise a linked Jira Bug. Jenkins uses the same upload tool; Run automation can also queue work for the customer-hosted nexus-runner, which executes the tests and posts results back.

Read test data without changing it

A project administrator can enable Read test data on a project API key. Use the read-only API for paged JSON test cases, cycles, runs, step results and coverage. Jira issue-secured records are excluded, sensitive values are always masked and people appear only as Atlassian account IDs. Each key is limited to 60 requests a minute and 2,000 an hour. See the API reference and Read API OpenAPI file.

5. Track environments

A pass proves only the build it ran on. Nexus records what is deployed where, so it can tell current evidence from stale evidence.

• Environment catalogue. Define environments per project (or site-wide defaults), with aliases such as stg for Staging, a type and a promotion order. Environments are retired, never deleted, so history stays readable.
• Deployments and events. Record a deployment (version, build, components) by hand or from CI, plus events such as an outage, a data refresh or a configuration change.
• Currency. A pass stays current until a newer build, or another event that invalidates results, reaches that environment. After that the result is marked stale, requirements show it on their Testing panel, and a Re-run stale tests plan puts exactly those tests into a cycle.
• The Environments page shows a card per environment in promotion order with its latest deployment and booking, plus Deployments, Health and events, History, Drift (expected against deployed version per component), Configuration snapshots compared side by side, and Bookings. Anyone on the project can book an environment; freeze windows are set by admins. Overlaps and deployments during a freeze are flagged, never silently blocked.
• Found in. A Bug raised from a failed run records the environment it was found in, which feeds the defect escape report.

6. Govern releases

Release governance brings together the test evidence already attached to requirements, executions, environments and builds. It gives release owners one place to assess that evidence and record the decision.

• Releases group Fix Versions, sprints or a saved search, with target environments, milestones from built-in templates (Standard, Hotfix, Emergency), links between releases, your own properties and a status history.
• The Matrix shows every release against every environment: Verified, Stale, Failed, or Deployed during a freeze, with a drill-down to the tests behind each cell.
• Readiness evaluates the gates you configure and opens with "Can we release?": a verdict, the pass rate per target environment, the Quality Score for the release scope, flaky tests in scope, and an "Attention required" list. A go or no-go decision is recorded as an append-only sign-off that keeps the gate results as they were at that moment.
• Workflow guard. The "Validate requirement is tested" rule can block a requirement's transition until it has passing tests, and optionally a current pass in the environments you choose (for example Production).
• Release notes are generated as Markdown or a Confluence page, and a calendar shows releases by timeline, month, week or year.
• Audit trail. Configuration changes and deletions are logged with who made them. Release and deployment records, test case change history, reviewed AI findings, the change log and the "Not testable" history are kept for seven years by default (adjustable); test case history older than a year keeps who, when and what changed but drops its copy of the steps to save space.

Release forecast and Quality Executive Summary. Alongside readiness, review the forecast of remaining testing work and an executive summary of the release evidence. These views help explain progress, risks and missing information; they do not approve a release or replace configured gates and a human sign-off.

Export the decision's evidence. On the latest Go sign-off, authorised release managers and project administrators can select Export evidence pack. The ZIP brings together the sign-off, baseline, coverage, executions, defects and audit evidence with a manifest and checksums. Keep it with your release records; it preserves an evidence snapshot rather than making later testing unnecessary.

7. Use AI safely

Nexus uses AI for requirement analysis and test generation, with review before findings or generated cases reach Jira. A person decides what reaches Jira.

• Every AI test case is a draft. It becomes a test case only when someone on your team accepts it. You can edit it first, or dismiss it.
• One requirement at a time. Each AI request works on exactly one requirement, so you can check the result before moving on. Nexus has no bulk AI.
• Only what the action needs. When someone runs an AI action, Nexus sends that requirement's summary, description, acceptance criteria and approved findings (plus any attachments the user leaves ticked) to your provider, under your provider's terms. Nothing is sent when nobody runs an AI action.

Rule-based requirement checks, such as missing acceptance criteria or unlinked requirements, run with no AI.

Your AI account, your terms. A Jira administrator connects one AI account for the whole site on Nexus Setup → AI: Anthropic, OpenAI, Google, Moonshot Kimi or xAI Grok. The key is stored as a Forge secret and never sent to the browser. Your AI provider's terms, regions, usage limits and billing apply; Nexus does not offer region-pinned AI processing.

AI output is a draft, not a sign-off. Findings and generated tests are suggestions for a person to review. They are not an authoritative or legally binding quality decision, and Nexus is built so that nothing the AI produces reaches Jira without a person's decision.

8. Report quality

Quality intelligence. Test ownership, test debt and an advisory Test health score help maintain the test library. Test health describes the tests; it is separate from the requirement Quality Score. Failure categories help triage results, while regression suggestions help choose cases for the next cycle. Review the evidence and confirm the appropriate action yourself; these suggestions do not silently change test scope or approve a release. Availability follows the site's enabled capabilities.

The Reporting center (Test Hub → Reports) groups reports in eight categories. Each card states the question it answers and opens in one click:

• Quality & Governance: the Nexus Quality Score (one number out of 100 with a published formula and what is taking points off it), and the governance rule trend.
• Traceability: summary, detail (an audit table per requirement), matrix (one grid row per requirement), defect traceability (which run found each Bug, and how many escaped testing), and coverage by Fix Version or sprint.
• Execution: cycle report, cross-execution comparison (regressions and fixes between runs or cycles), burndown for a sprint, epic or cycle, defect trend, flaky tests, workload by tester, capacity plan (the work ahead per person per week, for the weeks you choose), test case ageing, Test Runs List, run distribution, execution effort over time and run-step assignees.
• Impact: which requirements changed after analysis and how much testing that puts in question.
• Cross-project: the same headline figures side by side for up to ten projects, plus a comparison of cycles from different projects.
• Environments & releases: environment coverage, release readiness, cross-environment flaky tests, defect escape by environment, environment blockage, and deployment frequency and lead time.
• Test data: data-set usage, results by data row, unused and stale data sets, and consumable-data burn-down.
• Tools: ready-made JQL recipes and document templates for plans, cycles, requirements and test cases.

Build a custom report. Select New report to assemble up to twelve widgets. Choose each widget's data source, filters, grouping and measures, then preview it as a table, KPI card, bar, line, pie or pivot. Charts also offer Show data table. Save a report privately or share it with the project when its intended audience and scope are clear; viewers still need Jira access to the underlying work.

Most reports export to CSV or Excel, can be printed or saved as PDF from your browser, and can be saved as named views (private, or shared with the project). Reports can be published to Confluence as a page. Export file names carry the date and time.

Use evidence in your own tools. The Nexus API reference covers integration access alongside result ingestion. Nexus API v1 supports scoped access to cases, sets, plans, runs, versions, datasets and scripts, with explicit write scopes and a request log. An administrator must grant the required key permissions; API access does not bypass Nexus validation or sensitive-data protections. Choose columns… in the Export menu picks the columns, remembered for each report in your browser. The Cycle report includes step comments, and test case keys in the ageing, cycle, flaky and traceability reports open that test case in Nexus. Only Bug-type issues count as defects in reports.

Dashboards and Jira-native tools. Twelve dashboard gadgets can go on any Jira dashboard today, including Coverage Status, Test Execution Status, Requirement Quality, Burndown, Top Failures and Release Health. Fourteen JQL functions — testsOf, requirementsOf, executionsOf, failedTestsIn, testedIn, staleIn, deployedIn, testsWithoutExecution, defectsRaisedIn, testsInFolder, executedBy, runsWithStatus, testsInSet and requirementsWithoutTests — let you build your own filters and boards within Jira permissions. A scheduled digest posts coverage, pass rate, defect figures and the Quality Score as a comment on an issue you choose. Jira notifies its watchers; Nexus sends no e-mail of its own.

Find missing coverage with issue in requirementsWithoutTests("ABC"). executedBy finds execution by a person, runsWithStatus includes custom run statuses, and testsInSet finds the tests in a set.

Get the most from Nexus

Nexus works best when the team treats it as the evidence layer for delivery, rather than a separate QA filing system. Keep scope, ownership, results and defects current in the same Jira project where product work is planned.

Give each role a clear job

Use a simple operating rhythm

Every day

• Open Overview and investigate new failures, blocked runs and stale results.
• Open the active Cycle and assign anything unowned; close abandoned In Progress runs by recording the real outcome or resetting the attempt with a note.
• Triage a failed run from the execution record. Link the existing Bug when it is the same problem; raise a new Bug only for a distinct defect.

Once a week or each sprint

• Review Coverage → Uncovered only for the sprint, Fix Version or saved JQL scope.
• Review cases flagged by requirement changes, flaky tests and Test Case ageing.
• Check the CI delivery log for unmatched Automation Keys.
• Publish one digest or dashboard that the delivery team actually reads. Remove reports that do not drive a decision.

Before a release decision

1. Confirm the release scope and target environments.
2. Check that the current deployment, build and environment are attached to the runs.
3. Resolve or accept uncovered requirements, stale passes, blocked runs and open Bugs.
4. Run the release-readiness report and open every failed gate; a percentage alone is not a sign-off.
5. Record the go/no-go decision and generate release notes with the supporting evidence.

After configuration or process changes

• Run the Setup or Workflow Manager health check.
• Prove the smallest affected path before rolling the change into other projects.
• Read the Audit Log and relevant delivery log. A green screen without the expected recorded action is not proof that the workflow works.

Practices that keep the data useful

• Link at design time. A Test Case without a requirement can run, but it cannot prove requirement coverage. Add the link before Ready where possible.
• Keep one stable Automation Key. Put it in the automated test name or supported property and never reuse it for another behaviour. Treat unmatched results as a setup problem, not a result to attach manually.
• Create a new run for a re-test. Keep the failed run and its Bug intact. A new run shows whether the fix worked and preserves the sequence for audit and trend reports.
• Record environment and build. A pass without deployment context cannot show whether the current release is covered, and Nexus cannot detect when it becomes stale.
• Use sets for stable intent, cycles for a specific attempt. A smoke set can be reused for years; each sprint or build gets its own cycle and execution history.
• Prefer synthetic, versioned data. Publish the data version used by the run and reserve consumable rows instead of sharing informal test accounts in comments.
• Review AI decisions, not only AI output. Edit findings into clear requirement comments, accept only useful drafts, dismiss weak ones and use the effectiveness view to decide whether the chosen model helps your team.
• Pilot settings before copying them. Required fields, result rules and notifications can create friction at scale. Prove them in one project and copy the settings only after the team can complete the full workflow.

Your data and permissions

• Nexus app data is stored in Atlassian's platform. Nexus runs on Atlassian Forge. Test designs are stored on Jira issues; runs, history, data sets and environment records are stored in Forge storage for your site. There is no Resync-operated server. When a user runs an AI action, the required requirement content is sent to the AI provider connected by your Jira administrator, under that provider's terms.
• Jira permissions apply. Nexus checks the user's own Jira permissions for every read and write, including issue-level security: an issue you cannot see does not appear in the review queue, reports or search.
• Edit test steps through Nexus, not by hand. Test steps are kept in a Jira issue property called testSteps. Atlassian's MCP server (editJiraEntityProperty) and the Jira REST API can write that property directly, but don't: use the Nexus step editor, import, the Nexus Rovo actions or the Nexus CI API. A direct write skips the step lock (steps that already have results stay locked until the case is In Repair), the saved version Nexus keeps for compare and restore, and the step count that JQL testStepsCount searches use. If Nexus later finds a wrong step count, it corrects it and adds "Steps changed outside Nexus" to the case's history, but the lock and the version are still missed.
• Retention. App-owned working history is kept for 180 days by default, configurable per project; audit records are kept for seven years by default. That is the record of what happened, not all the detail: per-step run detail is summarised after 90 days by default (except cycles a release was signed off Go against), and requirement text is recorded for the first 500 requirements of a sign-off.
• Backup and restore. Atlassian's site backup does not include app data, so Jira admins can export everything Nexus stores and restore it later (Nexus Setup → Backup & Restore). Secrets and run commands are never included. See Back up and restore Nexus data.
• API keys. CI keys are stored only as salted hashes and shown once, and each key can be limited to what it needs.
• English only. The interface and all AI output are in English.

Back up and restore Nexus data (Jira admins)

Why Nexus has its own backup. Your Jira site backup (and Atlassian Backup and Restore) covers Jira issues only. It carries your Test Cases, Test Sets and Test Executions, their steps (stored on the issue), links and attachments. It does not carry app data. Runs and step results, run history, AI findings, test data sets, environments, releases and sign-offs, schedules, templates, the admin audit log and every Nexus setting live in Atlassian's Forge storage for your site. Atlassian keeps that data for 28 days after an uninstall, and a reinstall does not get it back by itself. Keep your own Nexus backup.

Take a backup. You need the Administer Jira permission.

1. Open Nexus Setup → Backup & Restore.
2. Under What to back up, choose The whole site or One project.
3. Leave the sensitive test data box clear unless you need real values. Sensitive data sets are masked by default. Real values are included only for sets you own or manage, and each one is recorded in that set's usage log.
4. Select Export backup and keep the page open. Large sites take a few minutes. If it stops, select Resume export.
5. Save the file, or every file with Save all files. A large backup has several numbered parts. Keep them together; a restore needs all of them.

Take a whole-site backup before you uninstall Nexus, before a site migration, and on your own regular schedule. Store the files somewhere access-controlled: they hold your test results and settings.

What a backup never contains. These are left out on purpose and must be set up again after a restore:

• CI API keys. Issue new keys and update your pipelines.
• Your AI provider keys. Enter them again in Nexus Setup.

Restore. Restore the Jira side first (your Jira site backup or import), so that issue keys exist. Then:

1. Install Nexus and run Setup on the target site.
2. Open Nexus Setup → Backup & Restore, select Choose backup files and pick all the part files. Nexus checks each file before anything is sent. It refuses files from a newer Nexus version, files from different backups, missing or duplicate parts, and files that were cut short or edited.
3. Select Preview restore. Nothing changes yet. The preview lists, per kind of record, what would be added, what is already there, and what would be skipped and why (issue or project not on this site, parent record skipped).
4. Tick the confirmation and select Restore now. If it stops, select Resume; it continues where it stopped.

A restore only adds records that are missing. It never overwrites anything already on the site, so running it twice adds nothing the second time. On another site, issues are matched by key and Jira versions by name. Records whose issue or project does not exist there are skipped and counted. Every export and restore is recorded in the admin audit log. After a restore, Nexus checks every person named in the restored records with Jira and anonymises the records of anyone whose Atlassian account has since been removed. The result shows how many.

What Nexus does not do

• It does not run tests inside Jira. Your CI, or a runner you host, runs them and Nexus receives the results.
• It does not send e-mail or chat messages. It uses Jira's own notifications, which your Jira Automation rules can forward anywhere.
• It does not generate PDFs on a server; use your browser's print to PDF.
• It does not use AI unless your site has connected its own AI account and a person runs an AI action.

Getting help

Email nexus-support@resync.co.nz, 9am to 5pm New Zealand time, Monday to Friday; we aim to reply within 24 hours. Hours, urgent contact and what to include are on the support page.