Difference between revisions of "BUGZILLA/FAQ"

Revision as of 09:44, 7 November 2013

This page lists several FAQ how to use the AOO-BUGZILLA

Attachments and Sample Documents

What are good Sample Documents?

Providing a sample document usually helps to reproduce a problem and to test the fix. Sample documents should be minimal, e.g. if you notice a bug in the upper left corner on page 345 of a 1000 page document then it is advisable to check whether the bug can still be replicated if the other pages are removed. Removing as much content that does not impact the reproducibility of the bug helps everyone who wants to work on that bug report.

How to use attached sample documents for multiple Bug Reports

If an appropriate document to reproduce the problem or to show the problem (screenshot) already does exist in Bugzilla, please cite the document instead of attaching it again. That saves time, because other users, who might know the existing attachment, do not need to check whether the new attachment contains new information (and only looks similar) or simply is a clone.

Bug Summary

Be as concise as possible in the bug Summary. The more specific a bug summary is the more useful it is for others such as when you report a new bug you will notice that bugzilla tries to find similar bugs that might be of interest. So instead of having a summary "Bug my cousin noticed in Writer!" please be more specific and write e.g. "Writer prints green text underlines as blue on a Windows GDI printer".

Meaning of bracketed branch names in the summary

Development often happens in code branches. Development branches are usually very interesting because they contain important new features or major cleanups. But that code is often not yet ready for general consumptions and needs to be extensively tested before it can be integrated. When such branches are tested the bugs founds are not of interest to general users but are very interesting for everyone working on that branch.

So it has become customary to add the bracketed branch name to the bug summary to make it clear that a problem only happens on a development branch. Such development branches are e.g. [sidebar], [ia2], [aw080], etc.

Meaning of bracketed pseudo key words in the summary

In order to make bug summaries as concise as possible experienced bug reporters used pseudo tags directly in the summary. They are often obsolete nowadays because some bugzilla fields are better suited for marking the kind of bug.

Examples for pseudo tags that were used are:

[Regression]

Deprecated tag for AOO regression issues. The "regression" keyword should be added to the Keywords field instead.

[RFE]

Request For Enhancement: deprecated, please set Issue Type selector to ENHANCEMENT.

[WW8]

Bug related to WW8 import filter (for Word.Document.8)

Bug STATUS

CONFIRMED

Should I report new bugs with initial Status CONFIRMED?

The CONFIRMED status means that the bug report is clear enough and has sufficient details for another person to replicate the bug on another system. So the answer is generally no! Even if you are pretty sure that you found a real bug and added lots of relevant information, generally following the Two Men Rule results in better reports, what leads to faster bug fixing costing less developer resources. But of course, if you are an experienced bug tester (relevant contribution in more than 100 bugs or similar qualification), you might find good reasons to ignore the Two Men Rule and to select initial Status CONFIRMED

When should I change Status from UNCONFIRMED to CONFIRMED?

Please do not change to CONFIRMED only because you were able to reproduce reporter's observations. The right moment for CONFIRMED is when all relevant information has been gained.

1. Report is a Good Bug Report
   1. Check for duplicates has been proceeded?
   2. Summary is clear and specific enough to distinguish the reported bug from other similar ones
   3. Sample Document available? Even if it seems to be simple for QA staff to create own sample documents, it saves a lot of time if a sample is attached. and Additionally the sample document can contribute additional relevant information (Localization, Language, Formatting caused by repoerter's very special New Document Templates, ...
2. Other selectors with correct contents?
   1. Relation to Operating System checked?
   2. Most early OO Version with what the bug has been observed selected (if possible, do your own tests with older versions)
   3. Appropriate Importance?
   4. Keywords appropriate?
3. All or at least most relevant aspects of the bug are listed in the report

If these conditions are fulfilled you should select CONFIRMED. But of course, it's a matter of consideration, an important CRASH-Regression should be taken by developers as soon as possible, here it would be inappropriate to leave Status UNCONFIRMED because some minor questions are without answer.

Mixed

From where can I download latest test versions?

You can test latest bug fixes with unstable test builds from here.

How To Crash AOO

For some investigations it is necessary to provoke a crash. You can find possibilities how to crash AOO with this Bugzilla query, what shows current crash-bugs.

What is the appropriate Version in Bugzilla Version selector?

The most early AOO or OOo version with what the problem has been observed. For Regression bugs Version information will help developers to find the code change what causes the problem.

In August 2013 the syntax for AOO versions in the selector has been changed, the AOO prefix has been dropped for most AOO versions. For historical reasons (?)some Versions with AOO prefix remained. If you work on such a bug report please always think about switching to a "modern" version.

How to connect a Bug report to a Tracking Bug

If you want to add a Bug report (like Bug 122762) to a TASK Tracking Bug (like Tracking Bug 122364), the best way is

1. Add Bug number to Depends on field in TASK Tracking Bug
2. Cite complete Heading line of "Depends-On-Bug" in a Comment in the TASK Tracking Bug.

So all interested users listed in CC of TASK Tracking Bug will get a summary of the new bug with mail from bugzilla@apache.org and can see immediately what the reported problem is - no need for a detour to the tracking Bug (and several clicks).

How to attach screenshots with additional graphic contents

If you want to add some graphic contents to a screenshot to make it more comprehensible, you should copy the clipboard contents with the screenshot to a new DRAW document and add emphasis, text ideas, callouts, pointer arrows or whatever in the Draw document. If you save it with 'File -> Properties -> Security - open File Readonly' before aou attach it in the Bug, the document is protected against unintended edits, but can be edited if appropriate by other users.

What is the best file type for screenshots?

Graphic formats with lossless compression like "PNG" are much more suitable than JPG, because no compression artifacts compound recognition of details.