Bugs are described and fixed in tickets

Analysis of bugs

Reporting an issue is the analysis of the bug. Bugs can be reported by all registered users and by anonymous users, but with limitations. If the following things are not described, the bug may be considered invalid. The text in italic is not mandatory.

• Summary:
  • May start with "Crash:", "Tweak:", "Unexpected behavior:". Crash means that the report form is evoked. Error report is needed as an attachment
  • "TLID:" testlink id, if the bug can be reproduced by executing a testcase
  • Short summary, custom text, what exactly happens in few words
• Type: bug
• Priority: determine the priority of the bug.
• Keywords - fill in related keywords, for example "text"
• Components - fill in component if you can determine the component
• reporter: DevID, automatically added by trac
• Milestone - current milestone
• cc: a reminder to someone
• Analysis_owners: your DevID
• Description: contains more detailed description and steps to recreate in order to reproduce the bug.
  • If a bug is a TLID type it must be clarified in the comment of the ticket on which step the application crashes.
• Attachments: you may add attachments to your ticket (screenshots, crash logs, books) reffering to an attachment named "filename.ext" is done by [attachment:filename.ext]
  • It is recommended that the attachments' names do not have spaces or any special symbols because you might not be able to link them properly in the ticket.

When you create the ticket, move it's status to analysis finished.

• Design
  • Design and implementation are done in a separate branch.
  • Design can be described in a comment of the ticket. If the space isn't enough (the fix is not trivial), the designer may create a wiki page named BUG_<ticket_id> to put his design section there (where <ticket_id> is the number of the ticket in trac. This page should be linked in the description field of the ticket. Bug pages are created using bug page template. When design is finished, the status should be updated and implementation may start without a design review. Same goes for the implementstion.
  • Design should have a system test that reproduces them. It should fail at design phase and pass at implementation.
  • In design and implementation the attachments must be linked properly if mentioned.
• Implementation: Implementation changeset should be linked. The ticket status is moved to implementation finished.
• Test: Test is performed by the reporter or in rare cases by an integrator. If the bug is not present, the ticket is closed.

Reviews and resolutions: When the developer understands the bug, he moves it to analysis ok phase and starts the design. Review of the design and implementation is done by the integrators.

• Analysis
  • The description describes the problem and the bug can be reproduced by following the instructions there - 3p
  • The ticket contains crash report +0.5p
  • The ticket contains attached books, screenshots, etc +0.5p (+1p)
  • The ticket contains linked test case +1p
  • The ticket contains links to related bugs, tasks, external links +0.5p

Design and implementation are usually reviewed at once

• Design
  • Explanation how it will be fixed
    • Methods
    • New classes if needed
    • Tests - system test that proves bug is present before the implementation and fixed after it.
  • What caused that issue?
• Implementation
  • Lame implementation (bad code) and hacks are not allowed
  • Should follow the design
• Test: Testing is performed by the reporter or in some needed cases by an integrator. If the problem is not present the ticket is closed. The test is not reviewed. If any testcases are related they should be executed.

Resolutions:

• fixed - set by the tester, if the problem is not longer present and fixed in this ticket
• invalid - set by anyone, if the problem is not present or something else is wrong, for example, the description is missing
• wontfix - if something is designed this way or doesn't worth fixing or will be fixed post final release
• later - this will be fixed later, as part of another task
• worksforme - this one is clear

Note: In daily report, you state the bug task as BUG_<ticketid>, for example

an BUG_1685 100% 25m
de BUG_1685 40% 25m
im-re BUG_1685 4p 10m