JIRA
Software Tutorial

The word "JIRA" comes from the Japanese word Gojira (ゴジラ) meaning Godzilla — which was Atlassian's internal nickname for Bugzilla (a competing bug tracker they used before building their own).

What does JIRA do for QA engineers?

• →
  Log bugs When you find a defect during testing, you create a Bug issue in JIRA with all details — steps to reproduce, expected result, actual result, screenshots.
• →
  Track bug status See which bugs are Open, In Progress (developer fixing), or Resolved (ready for retest).
• →
  Understand sprint tasks See which User Stories are assigned for the current sprint and what needs to be tested.
• →
  Link bugs to stories Connect a bug to the User Story it belongs to, so context is never lost.
• →
  Communicate with developers Add comments, attach screenshots/logs, tag developers — all within JIRA.

• E
  Epic — Large feature / big initiative A large body of work that is broken down into multiple Stories and Tasks. Epics span multiple sprints.
  Example: "User Authentication System" — this one Epic will contain multiple Stories like "Login page", "Forgot Password", "OTP verification".
• S
  Story (User Story) — A user-facing requirement A small, self-contained feature written from the user's perspective. Format: "As a [user], I want to [do something] so that [benefit]."
  Example: "As a user, I want to reset my password so that I can recover my account." — This fits in one sprint.
• T
  Task — General work item Work that does not directly deliver a new user feature — e.g. writing documentation, setting up an environment, DB configuration, code refactoring.
  Example: "Set up Postman collection for regression testing" or "Update test documentation for login module".
• B
  Bug — A defect in the software A problem that prevents the software from working as expected. Created by QA when a defect is found during testing.
  Example: "Login button is not clickable on Safari browser" or "OTP not sent when email has a + symbol".
• ST
  Sub-task — Smaller piece of work inside a Story/Task Breaks a Story or Task into smaller steps. A sub-task cannot have its own child issues.
  Example: Inside Story "Login Page" — Sub-tasks: "Write test cases", "Perform functional testing", "Perform UI testing".

When you open JIRA, here is what each part of the interface does:

Logging a bug properly in JIRA is one of the most critical skills for a QA engineer. A poorly written bug report wastes developer time. Here's how to do it right.

1. 1
   Click "+ Create" button at the top of JIRA.
2. 2
   Select Issue Type = Bug from the dropdown.
3. 3
   Select the correct Project where this bug belongs.
4. 4
   Fill all mandatory fields — Summary, Description, Priority, Component, Assignee.
5. 5
   Add attachments — screenshot, screen recording, or log file showing the bug.
6. 6
   Click "Create" to submit. JIRA auto-generates a unique issue key (e.g. PROJ-142).

What a well-written Bug report looks like:

Standard JIRA Bug Workflow:

• 1
  Open — QA creates the bug. It is in the initial state, ready to be picked up by a developer. The bug is visible in the backlog.
• 2
  In Progress — A developer is assigned the bug and is actively working on fixing it. When the developer clicks "Start Progress", status changes to In Progress.
• 3
  Resolved — Developer has completed the fix and marks it Resolved. This means: "I think I've fixed it." Now it goes back to QA for verification (retest).
• 4
  Closed — QA retests the bug, verifies the fix is correct, and closes the issue. This means: "Yes, it is fixed." Closed is the final state.
• ↩
  Reopened — QA retests after Resolved status, but the bug is STILL present or was fixed incorrectly. QA reopens the bug. It goes back to the developer.

• P1
  Blocker — Highest priority This issue blocks all further progress. The entire system or a critical feature is unusable. Must be fixed immediately — hotfix may be required.
  Example: Payment gateway is completely down. Users cannot complete any purchase. App crashes on launch.
• P2
  Critical — Urgent attention needed A serious bug that significantly impacts functionality but a workaround may exist. Fix required in current sprint.
  Example: Login fails on Chrome but works on Firefox. Users on Chrome cannot access the app.
• P3
  Major — Significant impact Bug affects important functionality but doesn't stop the system from working. Should be fixed soon but not necessarily today.
  Example: Search results show incorrect order. Product images don't load on product detail page.
• P4
  Minor — Small impact, easy workaround Issue has minor impact on the user experience. User can still complete their goal. Can be scheduled for a future sprint.
  Example: Tooltip text is missing on the help icon. Date format shows MM/DD/YYYY instead of DD/MM/YYYY.
• P5
  Trivial — Lowest priority, cosmetic issue Extremely minor issue with no impact on functionality. Often just visual/styling issues. Can be done anytime time permits.
  Example: A comma is missing in the footer text. Button has 2px extra padding compared to design.

Key JIRA Scrum terms QA must know:

Where to use JQL: Go to Issues → Advanced Search in JIRA. Switch from "Basic" to "Advanced" mode to type JQL queries.

Essential JQL queries every QA must know:

These are habits that separate a professional QA engineer from a beginner when using JIRA.

1. 1
   Write clear, actionable bug summaries The summary should tell the developer what broke, where, and under what condition. Formula: [What broke] + [Where] + [Impact]. Bad: "Button not working." Good: "Add to Cart button throws 500 error on product page when user is not logged in."
2. 2
   Always include environment details Browser name and version, OS, device type, app version, server environment (Dev / Staging / Production). Same bug may not reproduce on a different environment.
3. 3
   Attach screenshots or screen recordings A screenshot is worth a thousand words. Always annotate screenshots (circle or arrow pointing to the issue). JIRA supports Loom links, screenshots, videos, and log files.
4. 4
   Link bugs to the related Story Use JIRA's "Link" feature to connect a bug to its parent Story. This maintains traceability and helps during sprint reviews.
5. 5
   Set the correct priority — don't mark everything Critical If everything is Critical, nothing is Critical. Use the priority scale thoughtfully. When unsure, discuss with your QA lead or dev team.
6. 6
   Use @mentions in comments to communicate In the JIRA comment section, use @DeveloperName to notify them directly. Don't rely on WhatsApp or email to communicate bug details — keep all communication in JIRA so there's a record.
7. 7
   Check for duplicate bugs before creating new ones Search JIRA first (using JQL or basic search) to see if the bug was already reported. Duplicate bugs waste everyone's time and clutter the backlog.
8. 8
   Update bug status promptly When you start retesting — update status. When you verify a fix — close the bug same day. Keep JIRA updated in real time so the board accurately reflects current state.
9. 9
   Add labels and components Use JIRA Labels (e.g. "regression", "UI", "api-issue") and Components (e.g. "Login Module", "Checkout") to categorise bugs. This makes filtering and reporting much easier later.
10. 10
    Use the Watch feature for important bugs Click "Watch" on high-priority bugs. You'll get email/notification whenever someone comments or changes the status. Great for Blocker bugs that need close monitoring.