Recommended resources
The freely available resources this lesson will direct you to.
Hello! In the previous lesson, you used issue types to distinguish Epics, Stories, Tasks, and Bugs. Now we will look inside an issue. Fields such as assignee, reporter, priority, labels, due date, and fix version turn a work item into something you can sort, discuss, and review—but each field answers a different question. Allow about 35–40 minutes, including the readings and a short read-only observation.
Read the fields, not just the summary
A summary such as “Card form rejects valid cards” tells you what someone noticed. The surrounding fields tell you who is currently assigned, how the work has been prioritized, and whether it is associated with a deadline or release. Those details are useful to SQA only if you interpret them accurately.
The image shows an Epic selected in a Jira Server Issue Navigator search. Notice that Priority appears in Details, Assignee and Reporter appear under People, and Created and Updated appear under Dates. Its Fix Version(s) field says None; no due date is displayed.
For the field definitions, use Atlassian’s Issue fields and statuses. Although this reference is labeled Data Center 11.3, the meanings of these common fields are useful for understanding Jira Server/Data Center 8.x–9.x. Your installation may display fields in different places or use different priority names.
Read Atlassian’s field reference to establish what each field records, then its priority guidance to see why priority values require local interpretation.
In the opening “Field | Description” table, read from the Priority row through the Due row: field definitions. Focus on Priority, Labels, Assignee, Reporter, Due, and Fix Version(s); notice the separate Affects Version(s) row. Then go to the Issue priorities subsection, after Issue types, and read its introductory paragraph and default-priorities table through Lowest: priority guidance. You can stop before Issue resolutions.
The central reading habit is to distinguish what a field records from what you might infer from it. A value can help direct an investigation without proving that the underlying process was followed.
People, importance, and classification
Assignee identifies the person currently assigned to an issue. For a defect awaiting investigation, that is a useful starting point for asking who is expected to take the next action. It is not necessarily the person who introduced the defect, will test the fix, or is accountable for the entire release. An unassigned issue may be in a legitimate triage queue—or it may lack an owner when one is required. You need the team’s working agreement to tell the difference.
Reporter identifies the person recorded as having entered the issue. The reporter may have useful context about the original report, but do not assume they performed every test or are responsible for resolution. Assignee and reporter can therefore be different without anything being wrong.
Priority expresses an issue’s importance relative to other issues. A “High” priority Bug merits attention in a review, but the label alone does not tell you its technical severity, customer impact, or required response time. Priority values and their meanings can be customized. If an SQA review depends on what “High” is supposed to trigger, check the local definition rather than treating a default label as a universal rule.
Labels are tags used to group related issues—for example, checkout, regression, or accessibility. They can make an informal review set easier to find. Their usefulness depends on consistent application: a search for regression may omit relevant work recorded without that label. A missing label is evidence of a classification gap only if there is an agreed convention requiring it.
Consider a fictional Bug reported during checkout testing. Its reporter is a test analyst, its assignee is a developer, its priority is High, and it carries the labels checkout and regression. You can say who is currently assigned and how the issue is tagged. You cannot yet say that the fix has been tested, that High means a particular response deadline, or that every regression defect has been labeled the same way.
Dates and release targets answer different questions
A due date is the date by which an individual issue is scheduled to be completed. It is not the date the issue was created, last updated, or necessarily the date a release is planned. In the screenshot, Created and Updated are visible, but a due date is not. You should not call that Epic overdue based on those timestamps alone.
A fix version associates an issue with the project version in which it was, or is intended to be, fixed. Jira may show this as Fix Version(s) or Fix For Version. For a Bug, keep it separate from Affects Version(s): the affected version records where the problem manifests; the fix version records where its correction is targeted or recorded.
Read the opening of Atlassian’s Managing versions for the release context. This is an administrator-oriented page, but you only need its explanation of what versions represent—not its instructions for managing them.
Managing versions | Administering Jira applications Data Center 11.3 | Atlassian Documentation
Read Atlassian’s introductory explanation of project versions to understand why a fix version helps organize release scope.
Read the opening paragraph before Managing a project's versions, beginning “Versions are points-in-time for a project” and ending with the sentence about the “Fix For Version” field on each issue: release context. Focus on the relationship between versions, assigned issues, and release reporting. Stop before the administrative procedures.
Suppose the checkout Bug is due on 18 September and has Fix Version(s): 3.2. The due date expresses a scheduled completion date for that issue; the fix version associates it with release 3.2. Neither field, by itself, proves that the fix was delivered or verified. Likewise, a blank fix version does not prove an issue will never be fixed—it tells you that no fix version is recorded there.
Put the fields together for an SQA review
Read an issue as a set of related, but limited, signals. For the fictional checkout Bug, you might note:
| Field | Recorded value | Useful review interpretation |
|---|---|---|
| Reporter | Test analyst | A starting contact for the original report |
| Assignee | Developer | Current assignment, not proof of progress |
| Priority | High | Relative importance under the local priority scheme |
| Labels | checkout, regression |
Tags that may help find similar work |
| Due date | 18 September | Scheduled completion date for this issue |
| Fix Version(s) | 3.2 | Recorded release association for the fix |
Together, these fields give you a focused follow-up: if 18 September passes and the Bug is still open, ask whether the date or plan has changed; if release 3.2 is approaching, check the issue’s actual progress and testing evidence. Do not substitute field values for those checks. Also avoid treating an empty optional field as a process failure unless the field is required for that kind of work.
If you have Jira access, spend 5–8 minutes observing one Bug and one Story or Task without editing them. Locate the six fields from this lesson, noting which are absent or hidden. Compare the two issues’ assignments and any due dates or fix versions. If you cannot access Jira, use the screenshot instead: identify the values it does display, and keep “not displayed” distinct from “no value is recorded.” Your on-premise screen may look different; the questions the fields answer are more durable than their placement.
Key takeaways
Assignee is the current assignment; reporter is the recorded originator. Priority ranks relative importance according to local definitions, while labels provide tags whose reliability depends on consistent use. A due date concerns scheduled completion of an issue; a fix version associates it with a project release. For SQA, these fields guide where to look next, but none is proof that work was completed, tested, or released.
Next, we will distinguish an issue’s status from its resolution—a particularly important check when Jira appears to show that work is “done.”