QA/Triage For Beginners

From The Document Foundation Wiki
< QA
Jump to: navigation, search

Triaging is the process of confirming and prioritizing bugs. It is a great opportunity for non-developers to help improve the application. Well prepared bug reports help developers concentrate on fixing problems in a reasonable order. This page summarizes the various aspects of bug investigation and links to further detailed information on each task.

Bug Duplication

There is a high probability that an unconfirmed bug report has already been reported previously, so it is always a good idea to search for duplicates of a bug before attempting to confirm it. Doing this will reduce additional investigation efforts and streamline all discussions of the bug in the first bug report it was identified in. If you have identified a bug report to be a duplicate, click the ‘Mark as Duplicate’ link below the Status drop down menu and then insert the bug report number in the field presented.

It isn't always easy to find duplicate bugs because bug summaries may be incomplete or the bugs was filed under a different component.

List of Most Frequently Reported Bugs

Bug Prioritizing

New active QA team members can be given additional bugzilla rights to modify the Priority and Severity fields, as regular bugzilla users don't have access to change these. To request these privileges, ask members of the QA team (e.g. buovjaga, Xisco) on IRC or email the team on the mailing list. If you want to take on this task, it would be good for you to follow other members who are doing it and see if you would have set it in a similar fashion.

Bug prioritizing flowchart

It is usually easier to determine the severity of an issue than try to think of a suitable priority.

Small aesthetic tweaks to the UI can be considered low priority and trivial severity.

Problems that make you angry, but you can tolerate or work around somehow can be set to minor severity.

Bugs that break some functionality and do not have a workaround are normal severity.

Crashes, hangs and freezes resulting from a specific file or command are major severity.

When some application of LibreOffice is completely unusable due to crashing or interface glitches, severity is critical.

Regression Testing

Testing older versions of LibreOffice to find out whether a bug is also found in earlier versions makes it easier to identify whether the bug was introduced within the lifetime LibreOffice.

Download and install LibreOffice 3.3.

  • If the bug is present in 3.3, set version to "inherited from OOo" and put the following comment:
This bug is already present in Libreoffice 3.3

Changing version to "inherited from OOo"
  • If the bug is not present in 3.3 add "regression" to the keywords field and put the following comment:
This bug is not present in Libreoffice 3.3, thus it's a regression

Adding "regression" to the keywords

More information:

Crash Reports

Having a crash report (aka backtrace) for a bug makes it easy for a developer to identify what is causing the crash. If a crash report is added to a bug report, the havebacktrace keyword should be added to the Keywords field.


Bugs that were introduced into LibreOffice after version 3.5 can be easily tracked down by bibisecting.