QA

From KompoZer

Jump to: navigation, search

Contents

QA Tools

How to efficiently report a bug

Efficient bug reports are the most likely to be fixed. These guidelines explain how to write such reports.

  • Be precise
  • Be clear - explain it so others can reproduce the bug
  • One bug per report

Preliminaries

  1. Reproduce your bug using a recent build of the software, to see whether it has already been fixed.
  2. Search in the Tracker to see whether your bug has already been reported.

Reporting a New Bug

If you have reproduced the bug in a recent build and no-one else appears to have reported it, then:

  1. Choose "Enter a new bug" (that form incorporates parts of these guidelines)
  2. Select the product in which you've found the bug
  3. Fill out the form. Here is some help understanding it:
Component
In which sub-part of the software does it exist?
This field is required. Click the word "Component" to see a description of each component. If none seems appropriate, look for a "General" component.
OS
On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.)
If you know the bug happens on more than one type of operating system, choose "All". If your OS isn't listed, choose Other.
Summary
How would you describe the bug, in approximately 60 or fewer characters?
A good summary should quickly and uniquely identify a bug report. It should explain the problem, not your suggested solution.
  • Good: "Cancelling a File Copy dialog crashes File Manager"
  • Bad: "Software crashes"
  • Bad: "Browser should work with my web site"
Description
The details of your problem report, including:
  • Overview: More detailed restatement of summary.
  • Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the bug. Include any special setup steps.
  • Actual Results: What the application did after performing the above steps.
  • Expected Results: What the application should have done, were the bug not present.
  • Build Date & Platform: Date and platform of the build in which you first encountered the bug.
  • Additional Builds and Platforms: Whether or not the bug takes place on other platforms (or browsers, if applicable).
  • Additional Information: Any other useful information.
Add an attachment
You can attach relevant files to a bug report. Debugging information more than 20 lines long should be supplied this way. Also, if you have an HTML file that demonstrates the bug, you should attach that. You can only attach one file during initial submission so if your demonstration needs more, revisit the newly filed bug to do this part. Attach any subsidiary files (such as images) first and then edit the HTML file to point to the new URLs of the attached files before uploading, so the demo is self-contained. Ask before attaching more than five files.

Double-check your report for errors and omissions, then press "Commit". Your bug report will now be in the Bugzilla database. Original document information


Categories Migration

Comparison between kompozer tracker and composer bugzilla categories
Kompozer Categories Composer Categories
Accessibility
BuildBuild Config
Colorpicker
CSS EditorCSS Editor
CSS Styles
Editor
ExtensionsExtensions and Themes
General
HelpDocumentation
HTML Editor
Installer
Localization
OS Integration
Preferences
Sidebars
Site ManagerSite Manager
Software Update
Source View
Startup
Tabbed Editor
Tabs
Templates
Text Editor
Tip of the Day
Toolbars
User Interface
Websites
Personal tools