Run your first testing cycle
Take one Jira requirement from test design to a recorded result. This guide is for a tester or QA lead in a project that has already completed Nexus setup. You do not need AI for this workflow.
Choose a small, clear scope
Pick one requirement with an outcome you can observe. Identify the environment and build you will test, the person doing the work and any accounts or data they need.
Worked example: a customer can update their contact email. A valid address is saved and shown on their profile. An invalid address is rejected without replacing the existing one. This is illustrative test content; use synthetic accounts and addresses.
Design the cases
Open Test Hub → Cases and create a Test Case. Link it to the requirement so the team can trace the test back to its purpose. Give it a precise title, preconditions, actions and expected results.
For the valid-email path:
| Step | Action | Expected result |
|---|---|---|
| 1 | Sign in with a synthetic customer account and open the profile. | The profile shows the account's current email address. |
| 2 | Change the address to alex.new@example.com and save. |
The page confirms the change and displays the new address. |
| 3 | Refresh the profile. | The saved address remains visible. |
Create a separate case for invalid input. State the expected rejection and verify that the original address is preserved. Add other cases only where the requirement or risk calls for them.
Review the cases for missing preconditions and vague expectations such as “works correctly”. Mark the agreed cases Ready when they meet your project's workflow requirements.
Organise the run
Group the cases in a Test Set and plan a cycle for this scope. Confirm that the planned cases, testers and target environment are correct before execution begins.
Record the build or version under test. Results from a different build or environment may still be useful, but they do not prove this change works in the intended target.
For the detailed controls and workflow, see Plan and execute in the product guide.
Execute and record evidence
Open the planned execution and follow each step. Record what actually happened, then select the result that matches the observation. Attach evidence where it helps another person understand or reproduce the result.
If a case fails, link an existing defect or create one with the failing step, actual result, expected result and environment. If the environment prevents testing, record the blockage rather than treating the case as a pass.
After a fix, retest the affected path on the intended build and retain the earlier result as history. Check nearby behaviour where the change could have an impact.
Review the cycle
Look at more than the pass rate. Confirm that the important requirements have tests, the planned cases were run, failures have been investigated and any untested scope is visible.
Use the release-readiness checklist when this cycle contributes to a release decision. The result should be an evidence-backed decision by the responsible people.
Completion checklist
You can tick these items while this page is open. Selections are not saved; print or save the completed page as a PDF using your browser if you need a record.