Bug Tracking

Bugzilla Complete Guide for QA Teams

HelpMeTest

HelpMeTest

— 5 min read
Bugzilla Complete Guide for QA Teams

Bugzilla has been around since 1998. Netscape built it to track bugs in its browser. Mozilla maintained it. And somehow, in 2026, it's still running in thousands of organizations. Not because it's flashy — it isn't. But because it works, it's free, and once configured for your team, it gets out of the way.

This guide covers what QA teams actually need to know: setup, bug lifecycle, custom fields, reporting, and how to connect Bugzilla to modern CI/CD pipelines.

What Bugzilla Is (and Isn't)

Bugzilla is a bug tracking system, not a project management tool. It tracks defects — when they were found, who owns them, what state they're in, when they were resolved.

It does not do sprints, story points, roadmaps, or Gantt charts. If you want those, use Jira. If you want a focused, no-nonsense bug database that's been battle-tested for 25+ years, Bugzilla still earns its place.

Key strengths:

  • Powerful query/search engine
  • Flexible custom fields
  • Detailed audit trail on every bug
  • Email notification system that works
  • Free and self-hosted

Key weaknesses:

  • Dated UI (there's no way around it)
  • Setup requires a server and some technical knowledge
  • No native Kanban/sprint view
  • REST API exists but isn't the most ergonomic

Installation

Bugzilla runs on Linux (and technically Windows, but don't). The quickest setup:

# Ubuntu/Debian
sudo apt-get install -y bugzilla

# Or Docker (recommended for most teams)
docker pull bugzilla/bugzilla-dev
docker run -p 8080:80 bugzilla/bugzilla-dev

For production, you want MySQL or PostgreSQL behind it. The official docs cover database setup thoroughly. Once running, hit the web interface and run the setup wizard — it walks you through:

  1. Database connection
  2. Admin account creation
  3. Email configuration (critical — Bugzilla is very email-centric)
  4. Initial product/component structure

Core Concepts

Products and Components

Every bug belongs to a Product and a Component. Structure these to match your actual software:

  • Product: Mobile App
    • Component: Authentication
    • Component: Push Notifications
    • Component: Offline Sync
  • Product: API
    • Component: REST Endpoints
    • Component: Webhooks

Think carefully about this structure upfront — reorganizing later is painful.

Bug Lifecycle

The default Bugzilla bug lifecycle:

UNCONFIRMED → NEW → ASSIGNED → RESOLVED → VERIFIED → CLOSED
                                    ↓
                              (REOPENED)
  • UNCONFIRMED: Bug reported, not yet confirmed as reproducible
  • NEW: Confirmed, not yet assigned
  • ASSIGNED: Developer is working on it
  • RESOLVED: Developer says it's fixed (with resolution: FIXED, DUPLICATE, INVALID, WONTFIX, etc.)
  • VERIFIED: QA confirmed the fix works
  • CLOSED: Done

For QA teams, the VERIFIED step is the important one — it closes the loop between development and testing.

Resolutions

When a bug is resolved, the developer sets a resolution:

Resolution Meaning
FIXED Code change made
DUPLICATE Same as another bug
INVALID Not actually a bug
WONTFIX Known issue, accepted as-is
WORKSFORME Can't reproduce
INCOMPLETE Not enough info to investigate

QA's job is to verify FIXED bugs and either confirm (VERIFIED) or reopen if the fix didn't hold.

Setting Up for QA Teams

Custom Fields

Add custom fields under Administration → Custom Fields. Fields QA teams commonly add:

  • Found in version (string) — which release surfaced this bug
  • Test case ID (string) — link to the test that caught it
  • Severity (select) — Critical / High / Medium / Low / Cosmetic
  • Test environment (string) — production, staging, browser, OS

Flags

Flags are powerful. They track approvals and sign-offs. Common QA flags:

  • qa-verified? → qa-verified+ (QA approved fix) or qa-verified- (rejected)
  • needs-regression-test? → marks bugs that need a regression test added

Set up flags under Administration → Flags.

Saved Searches

The search/query interface is Bugzilla's strongest feature. Build saved searches for your team:

Open bugs by priority:

Status: NEW, ASSIGNED
Priority: P1, P2
Product: [your product]

Bugs awaiting QA verification:

Status: RESOLVED
Resolution: FIXED
Assigned QA contact: [your team]

Bugs found in last sprint:

Creation date: [sprint start] to [sprint end]

Save these and share them. Your team will use them daily.

Bug Reporting Best Practices

A good Bugzilla report has:

  1. Summary: One sentence. "Login button unresponsive on Safari 17 after session timeout"
  2. Steps to reproduce: Numbered. Specific. No assumptions.
  3. Expected result: What should happen
  4. Actual result: What does happen
  5. Environment: Browser, OS, version, build number
  6. Severity/Priority: Set these correctly — they affect triage

Don't report hypotheticals. Don't combine multiple bugs into one report. Don't leave steps vague.

Email Notifications

Bugzilla's notification system is robust but can be noisy. Configure wisely:

  • Set "Watch" lists for critical components
  • Customize which events trigger emails (status change, new comment, etc.)
  • Use the "Ignore" feature for bugs you don't need to follow

Most teams set up a qa-team@company.com alias that watches all bugs in key products, then individual engineers watch their assigned bugs.

REST API Integration

Bugzilla has a REST API for automation:

# Get a specific bug
curl "https://bugzilla.example.com/rest/bug/12345" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Create a bug
curl -X POST "https://bugzilla.example.com/rest/bug" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "product": "Mobile App",
    "component": "Authentication",
    "summary": "Login fails on iOS 17",
    "version": "2.4.1",
    "description": "Steps to reproduce...",
    "severity": "major"
  }'

CI/CD Integration

Auto-file bugs when tests fail in CI:

import requests

def file_bug_on_failure(test_name, error_message, build_id):
    response = requests.post(
        "https://bugzilla.example.com/rest/bug",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={
            "product": "Backend API",
            "component": "REST Endpoints",
            "summary": f"CI failure: {test_name}",
            "description": f"Build: {build_id}\n\nError:\n{error_message}",
            "severity": "blocker",
            "keywords": ["ci-failure", "automated"]
        }
    )
    return response.json()["id"]

Tag these with a ci-failure keyword so they're easy to triage separately from manually-reported bugs.

Reporting and Metrics

Bugzilla's reporting features are underused by most teams.

Bug charts (Reports → Charts): Track open bug counts over time. A rising chart that never comes down is a signal your team isn't keeping up with resolution.

Tabular reports: Export bug counts by component, severity, and priority. Useful for sprint retrospectives.

Burndown by version: Track how many bugs targeted at a release are resolved. Add a custom "target release" field and query it.

Integrations

Bugzilla integrates with:

  • Git/GitHub: Link commits to bugs via commit message hooks (Bug 12345 - Fix login timeout)
  • Jenkins/GitLab CI: Post build results as bug comments
  • Slack: Via webhook scripts (not native, but scriptable)
  • Confluence: Link to Bugzilla queries in documentation

The integrations aren't plug-and-play like Jira's, but they work once configured.

When to Use Bugzilla vs. Alternatives

Use Bugzilla when:

  • You need a dedicated, focused bug tracker (not a project management suite)
  • You're self-hosting and need full data control
  • Your team's workflow is heavily email-based
  • You have complex custom field requirements
  • Cost matters (it's free)

Consider alternatives when:

  • Your team needs sprint/kanban views
  • You need deep GitHub/GitLab native integration
  • You want a modern UI without customization
  • Non-technical stakeholders need to file and track bugs

Connecting Bugzilla to HelpMeTest

If you're using HelpMeTest for automated testing, you can connect test failures directly to Bugzilla:

  1. Configure your HelpMeTest webhook to POST to your integration endpoint
  2. Parse the failure payload and call the Bugzilla REST API
  3. Tag auto-filed bugs with a helpmetest keyword for easy filtering

This creates a clean loop: HelpMeTest catches regressions → Bugzilla tracks them → developers fix them → HelpMeTest verifies the fix.

Final Thoughts

Bugzilla isn't going to win any design awards. But for teams that need a reliable, flexible, self-hosted bug tracker with serious query power and a 25-year track record, it still delivers. Set it up once, configure your custom fields and saved searches, and it becomes invisible infrastructure — exactly what good tooling should be.

The teams that struggle with Bugzilla are usually the ones who never invested in configuring it. The teams that succeed treat the initial setup as a real project, not an afternoon task.

Read more

Start now free