How to Join LibreOffice Bug Hunting Days

LibreOffice Bug Hunting Days are community-driven testing events where Quality Assurance (QA) engineers, developers, and volunteers collaborate to test pre-release software versions, uncover regressions, and verify bug fixes before major releases. This guide outlines the exact steps QA engineers take to prepare their environments, identify focus areas, test the software, report findings, and coordinate with the global LibreOffice community.

1. Preparing the Test Environment

Before the event begins, QA engineers prepare an isolated environment to test the upcoming release without risking their daily productivity setup.

• Download Pre-Release Builds: Participants download the specific Alpha, Beta, or Release Candidate (RC) builds provided by The Document Foundation for the event.
• Parallel Installation: QA engineers often install LibreOffice in parallel with their stable versions or run it inside virtual machines or containers (like Flatpak or Docker) to test cleanly without overwriting system settings.
• Separate User Profiles: Engineers configure the pre-release build to use a separate user profile to avoid configuration conflicts.

2. Identifying Focus Areas and Test Plans

Each Bug Hunting Day typically has designated priorities announced on the official LibreOffice QA blog and mailing lists.

• Targeted Feature Testing: Testers focus on newly implemented features or major architectural changes detailed in the release notes.
• Regression Hunting: QA engineers verify that existing functionalities from previous versions still work as expected.
• Specialized Testing Sessions: Certain days focus on specific modules, such as Calc spreadsheet performance, Writer rendering, or interoperability with Microsoft Office file formats (DOCX, XLSX, PPTX).

3. Executing Tests and Verifying Issues

Engineers execute structured manual tests and exploratory testing to detect anomalies.

• Executing Test Cases: Testers use existing automated and manual test scripts to systematically check core functionality.
• Duplicate Checking: When an unexpected behavior is found, engineers search the Document Foundation’s Bugzilla database to ensure the issue has not already been reported.
• Regression Bisection: Experienced QA engineers often use bibisect repositories to pinpoint the exact commit that introduced a defect.

4. Reporting and Triaging on Bugzilla

Effective reporting ensures that developers can quickly reproduce and fix reported defects.

• Filing Bugs: Engineers submit detailed reports on the LibreOffice Bugzilla instance. A standard report includes clear steps to reproduce, actual vs. expected results, sample files (if applicable), and system details (OS, CPU architecture, desktop environment).
• Triaging Existing Reports: Participants help confirm unconfirmed bugs filed by other users by testing them across different platforms and setting appropriate severity levels.

5. Real-Time Collaboration

QA engineers actively communicate during the event to resolve questions and speed up verification.

• IRC and Matrix Channels: Testers and developers gather in the #libreoffice-qa channel (available on Matrix and Libera.Chat) to coordinate testing efforts in real time.
• Mentorship and Feedback: Experienced QA contributors assist newcomers with setting up environments, validating edge cases, and properly categorizing Bugzilla tickets.