Unit 5: Jira and Bugzilla for Testers

I. Orientation: Defect Tracking in Mobile Testing

Defect-tracking systems provide a controlled workflow for recording, assigning, investigating, correcting, and verifying software defects. Jira, developed by Atlassian, and Bugzilla, created for the Mozilla project, maintain a searchable history of each defect from discovery to closure.

• Defect record: A structured ticket containing a summary, description, environment, severity or priority, attachments, ownership, and workflow status.
• Traceability: A unique identifier, such as MOB-125 or Bugzilla bug 1024, connects test evidence, development work, comments, and resolution.
• Reproducibility: Mobile reports identify the device, operating-system version, application build, network, permissions, and exact steps needed to reproduce the failure.
• Workflow: Statuses represent stages such as Open, In Progress, Resolved, Closed, or Reopened; exact names depend on project configuration.
• Collaboration: Reporters, assignees, watchers, developers, and testers communicate through comments, mentions, notifications, and linked issues.
• Classification: Components, labels, versions, priority, and resolution values make defects easier to route, search, and analyze.
• Evidence: Screenshots, screen recordings, logs, crash traces, and timestamps support the observed result without replacing written reproduction steps.

II. Jira Defect Reporting — Creating Complete and Actionable Issues

A. Setup JIRA Trial for Practice

A Jira Cloud trial provides a temporary workspace in which testers can practise issue reporting, workflows, and searches.

• Registration: Open Atlassian’s Jira product page, choose the free or trial option, and create an Atlassian account using a verified email address.
• Site creation: Select a unique cloud site address, such as mobile-lab.atlassian.net, and create a software project for the testing team.
• Project choice: A team-managed project is simpler for individual practice, while a company-managed project offers centrally administered workflows, fields, and permissions.
• Configuration: Confirm that the project includes a defect-oriented issue type, commonly named Bug; an administrator can add or rename issue types when necessary.
• Practice data: Create sample components, labels, versions, and users before exercising search and lifecycle operations.
• Security: Use fictional defect data because trial sites may send real email notifications and should not contain production credentials or personal information.

B. Report a new defect in JIRA

A new Jira defect should explain one observable failure precisely enough for another person to reproduce it.

• Creation: Select Create, choose the correct project and Bug issue type, and enter a concise summary such as “Checkout button remains disabled after valid card entry.”
• Description: Record preconditions, numbered reproduction steps, actual result, and expected result.
  • Precondition: User is signed in and has one item in the cart.
  • Step: Open checkout, enter valid card data, and tap Pay.
  • Result: The button remains disabled instead of submitting payment.
• Classification: Set priority, affected version, component, labels, and assignee according to project rules.
• Evidence: Attach a screenshot, recording, or sanitized log and identify its timestamp.
• Submission: Review the report, select Create, and retain the generated key, for example MOB-125.

C. Search and Update Defect Information

Searching and updating maintain a single authoritative defect record as investigation produces new evidence.

• Location: Use Jira’s issue search, project issue list, board, or direct issue key lookup to locate the ticket.
• Update fields: Edit inaccurate descriptions, priority, labels, components, versions, environment, or assignment while preserving factual history.
• Comments: Add time-stamped findings such as “Reproduced on build 5.4.2 with Android 14”; comments are preferable to repeatedly rewriting investigation history.
• Status transition: Use workflow actions such as Start progress, Resolve, Reopen, or Close rather than merely describing the status in a comment.
• Audit trail: Jira records field and status changes in issue activity, identifying the user and changed values.
• Duplicate control: Search before creating another issue; link or close a duplicate according to the team’s policy.

D. Report Defect with Environment Value

The Environment field captures the hardware and software conditions under which a mobile defect occurs.

• Device details: State manufacturer, model, form factor, RAM class, and whether the device is physical or emulated.
• Software details: Include operating system, application version, build number, browser or WebView version, and relevant SDK level.
• Runtime conditions: Record network type, orientation, locale, account state, permissions, battery mode, and backend environment.
• Example value: Pixel 7; Android 14; app 5.4.2 (build 812); Wi-Fi; portrait; en-GB; staging.
• Availability: If Environment is absent from the create screen, a Jira administrator must add it through the project’s field layout or screen configuration.
• Scope: Environment describes test conditions; reproduction steps and actual results still belong in the description.

E. Report defect and link Team members

Jira links people to defects through ownership, notifications, mentions, and collaboration fields.

• Reporter: Identifies who submitted the defect and normally receives update notifications.
• Assignee: Represents the person currently responsible for the next action; assignment should follow component ownership or triage rules.
• Mention: Enter @name in a comment or description to notify a relevant tester, developer, designer, or product owner.
• Watchers: Users who watch an issue receive subsequent notifications, subject to project permissions and notification settings.
• Team fields: Some Jira configurations provide a Team or custom user-picker field for associating additional participants.
• Issue links: Use relationships such as blocks, is blocked by, duplicates, or relates to for tickets; these links connect issues, not user accounts.

F. Define Components in Defect

Components classify defects by stable functional or technical areas within a Jira project.

• Examples: A mobile project may define Authentication, Payments, Push Notifications, and Android UI.
• Definition: Project administrators create components and may provide descriptions, component leads, and default assignees.
• Selection: A payment-screen crash should use Payments, while a missing notification may use Push Notifications.
• Multiple values: Select more than one component only when the defect genuinely crosses ownership boundaries.
• Routing value: Components support automatic assignment, dashboards, release analysis, and focused queries.
• Distinction: Components are managed project values; labels are flexible keywords entered by users.

G. Report Defect with Label

Labels are reusable keywords that support lightweight classification across Jira issues.

• Entry: Add normalized values such as regression, accessibility, android-only, or smoke-failure in the Labels field.
• Consistency: Prefer one agreed spelling, for example android-only, because AndroidOnly becomes a separate label.
• Search use: A tester can retrieve regressions with the JQL expression:

project = MOB AND labels = regression

• Multiple labels: One defect may carry regression, checkout, and android-only when each term adds search value.
• Limitation: Labels have no formal owner or hierarchy and can become inconsistent without naming conventions.
• Confidentiality: Labels classify issues; they do not restrict visibility or replace issue-security settings.

III. Jira Bug Life Cycle — Triage, Resolution, and Verification

A. Bug Life Cycle - Valid Defect

A valid defect follows the configured workflow from confirmation through correction and test closure.

• Reported: The tester creates an Open or To Do issue with reproducible steps and evidence.
• Triaged: The team confirms the failure, assesses priority, assigns ownership, and schedules it for a release.
• In progress: A developer investigates and implements a correction, usually referencing the issue key in development activity.
• Resolved: The developer records a resolution such as Fixed and identifies the build containing the change.
• Retested: The tester repeats the original steps and relevant regression checks in that build and environment.
• Closed or reopened: A successful result leads to closure; continued failure leads to reopening with fresh evidence rather than creating a new ticket.

B. Bug Life Cycle - Invalid Defect

An invalid defect is closed when triage shows that the report does not represent a product fault requiring correction.

• Reproduce first: Triage compares the report against requirements, supported environments, current builds, and controlled test data.
• Common resolutions: Depending on configuration, Jira may use Not a Bug, Cannot Reproduce, Duplicate, Won't Fix, or Works as Designed.
• Evidence requirement: The resolver should explain the decision, such as “Android 9 is outside the supported OS range,” rather than only changing status.
• Reporter action: The tester verifies the explanation and may supply missing logs, corrected steps, or proof from an in-scope environment.
• Duplicate handling: Link the report to the original defect so its evidence and affected users remain traceable.
• Closure rule: Invalidity concerns classification, not the quality or intent of the tester who reported the observation.

C. Bug Life Cycle - Valid Defect Rejected by Developer

A valid defect rejected by a developer requires evidence-based resolution through triage rather than repeated status changes.

1. Tester position: Reproduce on the specified build, attach current logs or video, identify the violated requirement, and state the user impact.
2. Developer position: Document technical findings, configuration assumptions, design interpretation, or inability to reproduce.

• Comparison: Both positions should refer to the same application build, device state, test data, and expected behavior.
• Escalation: A product owner, business analyst, test lead, or triage group decides ambiguous requirements and release priority.
• Workflow outcome: The issue may return to In Progress, become a documented change request, or close with an explicit resolution.
• Professional record: Comments should contain observations and references, not unsupported claims or personal disagreement.

IV. Jira Search — Finding and Organizing Tickets

A. Basic Search of JIRA Tickets

Basic search retrieves issues through visible field controls without requiring Jira Query Language.

• Filters: Common controls include project, issue type, status, assignee, reporter, priority, label, component, and date.
• Text search: Enter meaningful words from the summary or description, such as checkout disabled.
• Issue key: Searching MOB-125 directly retrieves the uniquely identified ticket.
• Combination: Selecting project MOB, type Bug, and status Open narrows results through combined conditions.
• Results: Change displayed columns, sorting, and detail view to compare priority, assignment, and update time.
• Boundary: Basic mode is convenient for common searches but may not express complex Boolean or relative-date conditions.

B. Advanced Search Options: Issues and Filters

Advanced issue search uses JQL, while saved filters preserve useful queries for repeated access.

• JQL structure: A query combines fields, operators, values, keywords, and ordering.

project = MOB AND issuetype = Bug
AND status != Closed
ORDER BY priority DESC, updated DESC

• Issues: Search results can be inspected individually, exported where permitted, or used as the source for boards and dashboards.
• Filters: Save a query with a meaningful name such as Open Mobile Defects and choose whether it remains private or is shared.
• Subscriptions: Jira may send filter results on a schedule when subscriptions and email notifications are enabled.
• Permissions: A shared filter does not override project browsing or issue-security permissions.
• Maintenance: Update filters when workflow status names, projects, or custom fields change.

C. Advanced Search Options: Use Different fields to search items

JQL supports field-specific conditions for precise defect selection and reporting.

• Ownership fields: Use assignee = currentUser() or reporter = currentUser() to find personal work.
• Classification fields: Search with component = Payments, labels in (regression, accessibility), or priority in (High, Highest).
• Time fields: Relative dates support active monitoring, for example:

project = MOB AND updated >= -7d
AND resolution = Unresolved

• Version fields: affectedVersion identifies impacted releases, while fixVersion identifies the planned corrected release; exact field names suggested by Jira should be used.
• Text fields: The ~ operator performs text matching, as in summary ~ "login crash".
• Logic: Parentheses control precedence in mixed expressions, such as project = MOB AND (status = Open OR status = Reopened).

V. Bugzilla — Open-Source Defect Management

A. Introduction to Bugzilla

Bugzilla is a web-based, open-source bug-tracking system organized primarily around products, components, bug fields, comments, and status transitions.

• Origin: Bugzilla was created for Mozilla in 1998 and is now used by projects beyond the Mozilla ecosystem.
• Hierarchy: A bug belongs to a Product and Component, which determine ownership and available versions or milestones.
• Core fields: Typical records include Summary, Description, Status, Resolution, Severity, Priority, Assignee, CC list, and attachments.
• Lifecycle: Common states include UNCONFIRMED, NEW, ASSIGNED, RESOLVED, VERIFIED, and CLOSED, although installations can customize workflows.
• Resolution values: Examples include FIXED, INVALID, DUPLICATE, WONTFIX, and WORKSFORME.
• Comparison with Jira: Bugzilla is strongly defect-centered, whereas Jira supports broader configurable work-item and agile project workflows.

B. Working on Bugzilla test Server

A Bugzilla test server allows learners to practise safely without changing a production defect database.

• Account: Register with a valid email address if the server permits self-registration, then complete email verification.
• Scope: Confirm that the site explicitly permits testing; public project trackers must never be used for practice submissions.
• Navigation: Use Search, New Bug, Reports, and the user-preferences area to learn the installation’s enabled features.
• Practice operations: Create a clearly marked sample bug in the designated test product, add a comment, change CC membership, and inspect history.
• Search: Use Simple Search for common fields or Advanced Search for product, component, status, assignee, dates, and Boolean conditions.
• Cleanup: Resolve or close practice records according to the server’s instructions and avoid uploading credentials, private logs, or real user data.

C. File a Bug in Bugzilla

Filing a Bugzilla report requires selecting the correct product and component before documenting the failure.

• Start: Select New Bug or File a Bug, choose the target Product, and then select the most accurate Component.
• Summary: Write a specific symptom and context, such as “Android 14: profile photo upload stops at 90% on Wi-Fi.”
• Description: Include preconditions, numbered steps, actual behavior, expected behavior, frequency, and environment details.
• Classification: Set severity, priority, version, platform, operating system, and target milestone only when authorized and supported by evidence.
• Participants: Assign the bug according to ownership rules and add relevant users to the CC list without notifying unnecessary recipients.
• Attachments: Upload sanitized screenshots, logs, crash reports, or recordings and describe what each attachment demonstrates.
• Submission: Review the report, submit it, and use the resulting bug number for comments, status changes, duplicate links, and later verification.