Milestones are how you tie your testing activity to a release, sprint, or version.

Attach them to test cases, test runs, and defects, and you get a thread that runs through your entire QA cycle for that release.

When someone asks "what did we test in v2.3, and what broke?" the answer is a filter away.

The setup is minimal: a name, a due date, a status (Active or Completed), and an optional description. Keep naming consistent with how your team refers to releases elsewhere, if engineering calls it "Q2 release" in Jira, use the same here.

Once a milestone exists, you can attach it to your test run, defects, and relevant test cases as the release cycle unfolds.

Start by tagging the test run, then any defects that surface during execution.

If you've written cases specifically for new features in that release, attach the milestone there too. For tagging a large group of cases at once, the bulk edit option in the repository saves time.

One thing to plan around before you get too far in: each test case, run, and defect can only hold one milestone at a time.

If a bug isn't going to be fixed in the current release, think about whether to assign it to the current milestone where it was discovered, or the future one where it will be addressed.

What if a test case is reused across multiple releases - how do I track it?

Since a test case can only hold one milestone at a time, the milestone property will reflect whichever release it was last assigned to. For regression cases that run every cycle, most teams skip assigning a milestone to the case itself entirely and rely on the test run's milestone to carry the release context instead.

Does completing a milestone do anything to the attached cases, runs or defects?

No, it's a status marker for your own tracking. Marking a milestone Completed doesn't change the status of anything attached to it.