Writing Jira Issues for SQA Review

Hello! Last time, you looked at an issue’s activity and history as evidence of what was recorded, rather than treating its current fields as the whole story. This final lesson in the module turns that perspective around: what should you record when creating an issue so someone can understand and review it later?

You will create a clear defect record, choose fields without inventing facts, and check the saved issue from a future SQA reviewer’s point of view. Allow about 40 minutes, including a short hands-on draft.

Start with the right record

A well-formed issue does two jobs. It tells the person handling the work what needs attention, and it gives a later reviewer enough context to understand what was observed, where, and when. Jira fields help people find and group the issue; the description and supporting material make the observation assessable.

Watch Atlassian’s short demonstration for the basic act of creating an issue and entering its details. Use it for the concepts, not as a screen-by-screen guide: its interface may differ from your Jira Server or Data Center installation.

The following Jira Server-style Create Issue screen provides a useful contrast. It has Story selected, a summary, a reporter, an empty description, and High priority. Those values illustrate the form; they are not a model for every issue you create.

Before filling in a form, confirm two things:

1. Is this the right project and issue type? A reproducible product defect usually belongs in a Bug; a requested capability may be a Story, while a discrete piece of work may be a Task. Local conventions still matter.
2. Does an issue already describe the same observation? Search if you can. Adding evidence to an existing issue may be more useful than creating a duplicate with a second, diverging history.

Fields marked as required must be completed to create the issue. But “Jira accepted the form” is a much lower standard than “this record supports an SQA review.” Conversely, do not fill every optional field merely to make the screen look complete. Configure Fields may change which already-available inputs you see on a form; it does not mean you have permission to add or redesign project fields.

Write the defect so another person can verify it

For a Bug, the summary should identify the observable problem and its location, adding a condition when that condition matters. “Export broken” is hard to distinguish from other export problems. “CSV export omits the final row when a filtered list contains 51 records” gives someone a much better starting point.

The description then supplies the conditions needed to test that claim. This demonstration builds a UI bug report with prerequisites, environment, reproduction steps, and results. Watch for that structure, not for its particular product or field choices.

Here is a fictional Bug drafted for a sample application. Its specificity is what matters; do not copy its environment or observations into a real ticket unless they are true.

Summary: CSV export omits final row when filtered list contains 51 records

Prerequisites: In the test environment, a list contains 51 synthetic records matching the same filter. The account used can view and export all 51.

Environment: Staging; application build 4.2.0-rc2; browser and version recorded from the test session.

Steps to reproduce:

1. Apply the filter and confirm that the list reports 51 matching records.
2. Select the list’s CSV export action.
3. Open the downloaded file and count its data rows, excluding the header.

Expected result: The CSV contains all 51 matching data rows.
Actual result: The CSV contains 50 data rows; the final matching record is absent.

Supporting material: Attach a sanitized export and, if useful, a screenshot showing the filtered count. Record the date of the observation and identify the test run or specification if your team maintains one.

Notice what each part contributes. The prerequisites make the test repeatable; the environment distinguishes the build tested from any version eventually targeted for a fix. The steps let another person follow the same path. Expected and actual results are separate claims, not synonyms. Supporting material gives a reviewer something to inspect rather than asking them to rely solely on “it failed.”

If behavior is intermittent, say how often it occurred in the attempts you made. If you have not checked another browser or build, do not imply that you have. Remove personal data, credentials, tokens, and sensitive log contents before attaching files; use synthetic test data where possible.

A Story or Task will not necessarily need defect-style reproduction steps. It still needs a clear objective, relevant context, and a way to recognize completion—for example, agreed acceptance criteria or a specific deliverable. Choose a description suited to the work rather than imposing the Bug template on every issue type.

Set fields deliberately, then inspect the saved issue

The remaining fields make the record usable in searches and oversight. Their exact availability and allowed values depend on your project’s configuration.

You need not set status or resolution to make a new defect appear complete. Its initial status normally comes from the workflow, and a new, open Bug should not be recorded as resolved simply because someone has filed it. The project may also offer links to a related Story or other work. Add one when the relationship is known; dependency and traceability deserve closer attention later in the course.

For a 10–15 minute hands-on pass, use a training project or another space where you are authorized to create issues. If you have no suitable access, draft the same fields offline without submitting anything.

1. Choose a real observation you are permitted to record, or use the fictional CSV case as an offline draft only. Check for a likely duplicate.
2. Select the appropriate project and issue type. Write a distinctive summary and a description that separates prerequisites, environment, steps, expected result, and actual result where relevant.
3. Complete only fields you can support. Add permitted, sanitized evidence if you have it. Do not create a ticket that presents fictional observations as real findings.
4. If authorized, create the issue and open its full view. Check that the key, type, summary, description, reporter, priority, component, and any version or attachment appear as intended. Correct mistakes promptly. As the issue progresses, comments and history can then help a reviewer distinguish the initial report from later changes.

The final inspection matters: a good draft in the form is not yet proof that the saved record says what you meant. Ask whether a reviewer seeing only this issue months later could identify the observation, its test conditions, the claimed result, and which fields were decisions rather than guesses.

Module 1 quick check

Use these as brief recall checks before moving on:

• Project or issue—which is the individual record of the CSV defect? The issue; the project provides its organizational context.
• Does a Fix Version prove a defect was released? No. It records a release target, not shipment or verification.
• Where would you look to see whether the issue’s priority changed after creation? Its History or relevant Activity view, rather than only the current priority field.

Key takeaways

A reviewable Jira issue is specific without pretending to know more than was observed. Choose the right project and type, describe reproducible facts, keep expected and actual results distinct, and set classification and release fields only when justified. After creation, inspect the saved record: its fields and subsequent history are what future SQA work will have to rely on.

This completes the information-model module. Next, you will use the Issue Navigator and searches to find and review records across a project, rather than inspecting one issue at a time.