| 2 | | == Analysis of bugs == |
| 3 | | 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. |
| 4 | | * Summary: |
| 5 | | * ''May start with "Crash:", "Tweak:", "Unexpected behavior:". Crash means that the report form is evoked. Error report is needed as an attachment'' |
| 6 | | * ''"TLID:" testlink id, if the bug can be reproduced by executing a testcase'' |
| 7 | | * Short summary, custom text, what exactly happens in few words |
| 8 | | * Type: bug |
| 9 | | * Priority: determine the priority of the bug. |
| 10 | | * ''Keywords - fill in related keywords, for example "text"'' |
| 11 | | * ''Components - fill in component if you can determine the component'' |
| 12 | | * reporter: DevID, automatically added by trac |
| 13 | | * Milestone - current milestone |
| 14 | | * ''cc: a reminder to someone'' |
| 15 | | * Analysis_owners: your DevID |
| 16 | | * Description: contains more detailed description and steps to recreate in order to reproduce the bug. |
| 17 | | * ''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]'' |
| 18 | | When you create the ticket, move it's status to analysis finished. |
| 19 | | * Design |
| 20 | | * Design and implementation are done in a separate branch. |
| 21 | | * 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. |
| 22 | | * Design should have a system test that reproduces them. It should fail at design phase and pass at implementation. |
| 23 | | * Implementation: Implementation changeset should be linked. The ticket status is moved to implementation finished. |
| 24 | | * Test: Test is performed by the reporter. If the bug is not present, the ticket is closed. |
| 25 | | |
| 26 | | Reviews and resolutions: |
| 27 | | 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. |
| 28 | | * Analysis |
| 29 | | * The description describes the problem and the bug can be reproduced by following the instructions there - 3p |
| 30 | | * The ticket contains crash report +0.5p |
| 31 | | * The ticket contains attached books, screenshots, etc +0.5p (+1p) |
| 32 | | * The ticket contains linked test case +1p |
| 33 | | * The ticket contains links to related bugs, tasks, external links +0.5p |
| 34 | | Design and implementation are usually reviewed at once |
| 35 | | * Design |
| 36 | | * Explanation how it will be fixed |
| 37 | | * Methods |
| 38 | | * New classes if needed |
| 39 | | * Tests - system test that proves bug is present before the implementation and fixed after it. |
| 40 | | * What caused that issue? |
| 41 | | * Implementation |
| 42 | | * Lame implementation (bad code) and hacks are not allowed |
| 43 | | * Should follow the design |
| 44 | | * Test: Usually the reporter checks if the problem is present. If not-the bug is closed. The test is not reviewed. If testcase is related, it should be executed. |
| 45 | | |
| 46 | | Resolutions:Bugs are described and fixed in tickets |
| 109 | | * fixed - set by the tester, if the problem is not longer present and fixed in this ticket |
| 110 | | * invalid - set by anyone, if the problem is not present or something else is wrong, for example, the description is missing |
| 111 | | * wontfix - if something is designed this way or doesn't worth fixing or will be fixed post final release |
| 112 | | * later - this will be fixed later, as part of another task |
| 113 | | * worksforme - this one is clear |
| 114 | | |
| 115 | | Note: In daily report, you state the bug task as BUG_<ticketid>, for example |
| 116 | | {{{ |
| 117 | | an BUG_1685 100% 25m |
| 118 | | de BUG_1685 40% 25m |
| 119 | | im-re BUG_1685 4p 10m |
| 120 | | }}} |
