Unit 5: Jira and Bugzilla for Testers - Subjective Questions

A JIRA trial environment can be set up as follows:

1. Visit the Atlassian JIRA website and select the option to start a free trial.
2. Create an Atlassian account using a valid email address or an available sign-in provider.
3. Enter a unique name for the JIRA cloud site.
4. Select JIRA Software and choose a suitable template, such as Scrum, Kanban, or Bug Tracking.
5. Create a practice project and assign a meaningful project name and project key.
6. Add sample users or team members and assign appropriate roles and permissions.
7. Configure basic project settings, such as issue types, workflows, components, priorities, and versions.
8. Create a sample issue to confirm that the project is working correctly.

The trial site should contain only practice or non-confidential data. The administrator should also note the trial expiration date and verify user permissions before performing defect-management exercises.

To report a new defect, the tester selects Create, chooses the correct project, and sets the issue type to Bug or Defect. The following fields should then be completed:

• Summary: A brief and specific statement of the problem.
• Description: Detailed information about the observed failure.
• Steps to reproduce: A numbered sequence that reliably reproduces the problem.
• Expected result: The behavior required by the specification.
• Actual result: The behavior observed during testing.
• Priority or severity: The business urgency or technical impact of the defect.
• Environment: Device, operating system, application build, browser, network, and other relevant conditions.
• Component and version: The affected module and release.
• Assignee: The person or team responsible for investigation.
• Attachments: Screenshots, videos, logs, or crash reports.
• Labels: Searchable tags used to classify the issue.

Before submitting, the tester should search for duplicates, remove sensitive information from attachments, and review all details for accuracy. After creation, the tester should record the generated issue key, such as MAT-101.

A high-quality defect report allows another person to understand and reproduce the failure without asking for substantial additional information. It should contain:

• A precise summary, such as Application crashes when the user taps Pay twice on Android 14.
• Preconditions, including account state, test data, and required configuration.
• Numbered and unambiguous reproduction steps.
• Separate expected and actual results.
• Reproducibility information, such as 5 out of 5 attempts.
• Build number, device model, operating-system version, network type, and application configuration.
• Appropriate priority, severity, component, affected version, and labels.
• Evidence such as screenshots, timestamps, device logs, or videos.

A suitable description structure is:

Preconditions: User is logged in and has an item in the cart.

Steps:

1. Open the checkout page.
2. Select a payment method.
3. Tap Pay twice quickly.

Expected: Only one payment request is submitted.

Actual: The application crashes after submitting the request.

The report should be factual, concise, free from blame, and limited to one independently trackable defect.

A tester can locate a defect by using its issue key, entering keywords in the search bar, applying basic-search filters, or executing a JQL query. After opening the correct ticket, the tester can select Edit or use inline editing to update permitted fields.

Typical updates include:

• Correcting the description or reproduction steps.
• Adding environment information or attachments.
• Changing priority, component, labels, assignee, or fix version.
• Adding a comment containing new test evidence.
• Moving the issue through an allowed workflow transition.
• Recording retest results and reopening the defect when necessary.

Traceability must be preserved by avoiding the deletion of meaningful historical information. Important changes should be explained in comments, and evidence should include the tested build and date. JIRA records field modifications in the History or Activity section, including the user, time, old value, and new value. Testers should not change workflow states, resolutions, or ownership without evidence and authorization.

The Environment field records the hardware, software, network, build, and configuration under which a failure occurred. It helps developers reproduce the issue and allows testers to identify environment-specific defects.

For mobile testing, the field may include:

• Device manufacturer and model.
• Physical device or emulator status.
• Operating system and patch version.
• Application version and build number.
• Installation type, such as fresh installation or upgrade.
• Network type and quality, such as Wi-Fi, 5G, or offline mode.
• Locale, language, time zone, permissions, and orientation.
• Backend environment, such as development, staging, or production.
• Relevant account type or feature flag.

Example:

Environment: Samsung Galaxy S23 physical device; Android 14; application version 5.2.1, build 52108; upgraded from version 5.1; staging server; Wi-Fi with approximately 20 Mbps bandwidth; English locale; portrait orientation; location permission denied.

Exact values are preferable to vague statements such as latest Android because versions and configurations change over time.

A tester first creates the defect with complete reproduction information and then involves the appropriate people using JIRA's collaboration fields and features:

• Reporter: The person who raised the defect and can clarify the observations.
• Assignee: The individual currently responsible for investigating or resolving the issue.
• Mentions: A user can be notified in a comment by entering @ followed by the user's name. A mention should include a clear request or reason.
• Watchers: Users who want notifications about future changes can watch the issue, subject to project permissions.
• Issue links: Related defects, stories, or tasks can be connected using relationships such as blocks, is blocked by, duplicates, or relates to.

The reporter should assign the issue according to the team's ownership rules rather than tagging many unrelated users. For example, a tester may assign a payment defect to the payment-module owner, mention the product owner for requirement clarification, and add a link showing that the defect blocks a release story. This keeps responsibilities and dependencies visible.

Components are project-level categories that represent functional modules, technical subsystems, services, or ownership areas. Examples for a mobile application include Login, Payments, Notifications, Database, and User Interface.

A project administrator generally defines a component by:

1. Opening Project settings.
2. Selecting Components.
3. Creating a component with a meaningful name and description.
4. Optionally specifying a component lead and default assignee.
5. Saving the configuration and confirming its availability on issue screens.

When reporting a defect, the tester selects the affected component. An issue may have more than one component if the configuration allows it, but only genuinely affected modules should be selected.

Components provide the following benefits:

• Route issues to the appropriate owner.
• Group and search defects by subsystem.
• Support dashboards, reports, and workload analysis.
• Reveal modules with high defect concentrations.
• Improve release-risk assessment.

Unlike labels, components are normally controlled project values and may influence automatic assignment.

Labels are short, searchable tags attached to JIRA issues. They provide flexible classification beyond fixed project fields. Examples include regression, android, checkout, accessibility, and automation-candidate.

A tester can enter one or more labels while creating or editing a defect. Labels are useful for:

• Grouping issues from a test cycle or campaign.
• Identifying platform-specific failures.
• Marking regression defects or automation candidates.
• Creating filters, dashboards, and reports.
• Finding related issues across components or versions.

Good label usage requires a shared naming convention. Teams should use lowercase values, avoid spaces where possible, select existing labels rather than creating spelling variations, and avoid placing sensitive data in labels. For example, android-14 should not also appear as Android14, android_14, and android-v14 unless they intentionally represent different categories.

A label differs from a component because it is generally a flexible tag, whereas a component is a controlled project-level module that can have a lead or default assignee.

A typical valid-defect life cycle is:

1. New or Open: The tester reports the defect with evidence.
2. Triage: The team checks validity, duplicate status, severity, priority, scope, and ownership.
3. Assigned: The defect is assigned to a developer or responsible team.
4. In Progress: The developer reproduces, investigates, and implements a fix.
5. Resolved or Fixed: The developer records the resolution, fixed build, and relevant technical details.
6. Ready for Retest: A build containing the fix becomes available to testing.
7. Retest: The tester follows the original steps in the specified environment and performs relevant regression checks.
8. Closed: The issue is closed when the expected behavior is observed and no related regression is detected.
9. Reopened: If the original problem persists, recurs, or the fix is incomplete, the tester reopens the defect with fresh evidence.

The exact status names depend on the configured JIRA workflow. A valid defect should move between states only through defined transitions, and each transition should be supported by comments, build details, and test evidence.

An invalid defect begins like any other report: it is created, reviewed, and investigated. During triage or analysis, the team may determine that the issue should not be fixed as a valid product defect.

Common resolution categories include:

• Duplicate: The same root problem is already tracked in another issue.
• Not a Bug or Works as Designed: The observed behavior matches the approved requirement.
• Cannot Reproduce: The failure cannot be reproduced with the available information and environment.
• Incomplete: Essential steps, evidence, or environment data are missing.
• Configuration or Environment Issue: The problem is caused by unsupported settings, test data, network conditions, or external systems.
• Won't Fix: The issue is acknowledged but the team has decided not to implement a correction.

The resolver should add a factual explanation. A duplicate should link to the master issue; Works as Designed should reference the requirement; and Cannot Reproduce should list the builds and environments tested. The tester reviews the explanation and either accepts closure or reopens the ticket with new evidence. A defect should not be rejected merely because it was not reproduced once.

The disagreement should be resolved through evidence and triage rather than personal opinion. The tester should:

1. Recheck the requirement, acceptance criteria, design, and supported environment.
2. Reproduce the failure on the stated build and record its frequency.
3. Improve the ticket with exact steps, test data, timestamps, screenshots, video, logs, and environment details.
4. Ask the developer to state the rejection reason, such as Cannot Reproduce, Works as Designed, or Environment Issue.
5. Compare the developer's environment and data with those used by the tester.
6. Arrange joint reproduction when the evidence remains inconclusive.
7. Escalate the issue to triage with the test lead, developer, product owner, or business analyst if requirement interpretation is disputed.
8. Record the agreed decision and supporting references in JIRA.

If the product owner confirms that the behavior violates the requirement, the defect should return to an actionable state such as Open or Reopened. If the behavior is intended, it may be closed with a documented resolution. If the requirement itself must change, a separate change request or story may be created and linked.

The three cases begin with defect submission and review, but their later paths differ:

A valid issue closes because the correction has been verified. An invalid issue closes because investigation supports a non-fix resolution. A valid issue rejected by a developer requires clarification, joint reproduction, or stakeholder review before returning to development.

In every case, JIRA's comments, links, status history, resolution, build details, and attachments should preserve an auditable decision trail. A status such as Closed alone is insufficient unless the resolution and supporting reason are also clear.

A basic JIRA search can be performed from the global search box or from the Issues search page. If the issue key is known, entering a value such as MAT-101 is the quickest method. Otherwise, a tester can enter text from the summary or description.

On the issue-search page, results can be refined using fields such as:

• Project.
• Issue type.
• Status.
• Assignee or reporter.
• Priority.
• Component.
• Label.
• Fix version or affected version.
• Creation, update, or resolution date.
• Text contained in the issue.

Multiple criteria can be combined. For example, a tester may select project Mobile App, issue type Bug, status Open, and assignee Current User. The result columns can be customized and sorted by fields such as priority or update time.

Basic search is appropriate for common searches because it does not require JQL knowledge. If complex conditions, relative dates, or logical groups are needed, the tester should switch to advanced search.

The Issues area provides access to the issue navigator, where testers can use basic criteria or switch to advanced JIRA Query Language, commonly called JQL. Advanced search supports field-based conditions, logical operators, ordering, date functions, and text matching.

After obtaining the required result set, a tester can:

1. Select Save as and give the search a descriptive name.
2. Manage the saved search under Filters.
3. Configure sharing permissions for private use, a project, a group, or an organization, depending on permissions.
4. Mark the filter as a favorite for quick access.
5. Subscribe to the filter to receive scheduled email results, if enabled.
6. Use the filter in dashboards, reports, boards, or filter-result gadgets.

For example, a filter named Open Android Release Blockers may display unresolved Android defects with the highest priority. Sharing must follow access-control rules: a filter should not expose issue information to users who should not see it. The owner should also maintain outdated criteria when versions, projects, or team members change.

JQL searches issues by combining fields, operators, values, and keywords. Common fields include project, issuetype, status, priority, assignee, reporter, component, labels, fixVersion, created, and updated.

Important operators and keywords include:

• = and != for equality and inequality.
• IN and NOT IN for value lists.
• ~ for text matching.
• IS EMPTY and IS NOT EMPTY for missing or present values.
• >, <, >=, and <= for dates and comparable values.
• AND, OR, and NOT for logical combinations.
• ORDER BY for sorting results.

Examples are:

• project = MOB AND issuetype = Bug
• status IN (Open, Reopened) AND priority IN (Highest, High)
• labels = regression AND component = Payments
• assignee = currentUser() AND resolution IS EMPTY
• summary ~ "login failure"
• updated >= -7d ORDER BY priority DESC, updated DESC

Parentheses should be used when mixing AND and OR so that the intended evaluation order is explicit.

A suitable query is:

project = MOB AND issuetype = Bug AND component = Payments AND labels = android AND priority IN (Highest, High) AND resolution IS EMPTY AND updated >= -7d AND assignee = currentUser() ORDER BY priority DESC, updated DESC

The clauses have the following purposes:

• project = MOB limits results to the mobile project.
• issuetype = Bug excludes stories, tasks, and other issue types.
• component = Payments selects the payment module.
• labels = android selects defects tagged for Android.
• priority IN (Highest, High) includes the two required priority levels.
• resolution IS EMPTY identifies unresolved issues more reliably than checking only one open status, because a workflow may have several unresolved statuses.
• updated >= -7d selects issues updated within the previous seven days.
• assignee = currentUser() makes the query reusable by different logged-in users.
• ORDER BY priority DESC, updated DESC places higher-priority and more recently updated defects first.

The exact project key, component, labels, priority names, and field availability must match the site's JIRA configuration.

Bugzilla is a web-based, open-source defect-tracking system originally developed for the Mozilla project. Testers use it to record, classify, assign, search, update, and monitor software defects.

Important Bugzilla concepts include:

• Product: The application or major system being tracked.
• Component: A functional or technical area within a product.
• Bug ID: A unique number assigned to each report.
• Summary and description: The concise title and detailed defect information.
• Status and resolution: Values that represent the current workflow state and final outcome.
• Severity and priority: Measures of technical impact and scheduling importance.
• Assignee: The person responsible for the bug.
• CC list: Users who receive updates without being the assignee.
• Attachments: Screenshots, logs, patches, and other evidence.
• Dependencies: Relationships showing that one bug blocks or depends on another.

Bugzilla also supports comments, duplicate detection, advanced searches, saved searches, email notifications, and audit history. Its exact fields and workflow can vary according to server configuration.

A Bugzilla test server is a practice or non-production installation used to learn defect-management operations without affecting a live project. A tester should:

1. Obtain the approved test-server URL and create or activate a user account.
2. Review available products, components, versions, and workflow values.
3. Search for existing practice bugs before filing a new one.
4. Create bugs only in the designated training product or component.
5. Use fictional or sanitized data rather than customer credentials or confidential information.
6. Practice editing fields, adding comments and attachments, changing assignees, adding CC users, and moving bugs through permitted statuses.
7. Use links and dependencies carefully to avoid modifying other learners' records.
8. Record the bug ID and verify the change history after each exercise.
9. Log out after use, particularly on a shared computer.

A test server may send real notification emails even though its bugs are not real. Therefore, testers should avoid unnecessary CC entries, misleading security reports, executable attachments, and large files. They should also follow any cleanup or naming conventions provided by the instructor or administrator.

The procedure for filing a bug in Bugzilla is:

1. Sign in and select File a Bug or New.
2. Choose the correct product and component.
3. Search suggested or existing bugs to avoid creating a duplicate.
4. Enter the version, platform, operating system, severity, priority, and target milestone if the fields are available.
5. Write a concise, searchable summary.
6. Enter preconditions, numbered reproduction steps, expected behavior, actual behavior, frequency, and environment details in the description.
7. Set the assignee only when the ownership rule is known; otherwise, use the component default.
8. Add relevant users to the CC list when their participation is necessary.
9. Attach sanitized screenshots, logs, videos, or crash reports.
10. Submit the report and note the generated bug ID.
11. Review the saved bug for formatting and add corrections through comments or field updates.

A strong Bugzilla report is reproducible, objective, and limited to one problem. It should not contain passwords, personal data, authentication tokens, or irrelevant diagnostic files.

JIRA and Bugzilla both support defect creation, assignment, comments, attachments, searching, notifications, history, and workflow-based status changes. Their emphasis and terminology differ.

For testers, JIRA is useful when defects must integrate closely with stories, sprints, releases, and dashboards. Bugzilla is effective for structured defect tracking with strong search, notification, and dependency features. The better choice depends on project process, hosting requirements, integrations, customization needs, permissions, cost, and team familiarity.