Difference between revisions of "BugFilingRecommendations"
(Created page with "= Bug Filing Recommendations = Writing good bug reports is hard; useful reports are even harder. We should try our best to be thorough, so there's consistency and a fine exper...") |
(→Bug Filing Recommendations) |
||
| Line 1: | Line 1: | ||
= Bug Filing Recommendations = | = Bug Filing Recommendations = | ||
| − | Writing good bug reports is hard; useful reports are even harder. We should try our best to be thorough, so there's consistency and a fine experience reading bugs. | + | Writing good bug reports is hard; useful reports are even harder. We should try our best to be thorough, so there's consistency and a fine experience reading bugs. This document concerns itself with outlining some obvious suggestions while reporting/verifying bugs: |
| + | * Ensure you can reproduce the bug | ||
| + | * '''Clear''' instructions to reproduce the bug. Bonus points for a reproducer script. | ||
| + | * Version details (e.g. Havana ? Grizzly) | ||
| + | * Test environment details | ||
| + | ** e.g. some special hardware -- an exotic NAS, etc.) | ||
| + | * Verification procedure | ||
| + | ** Include test setup details, configuration details, other relevant context. | ||
| + | ** Most of "cloud" testing is dependent on test environment, clearer the details, lesser the round-trips between Development and QE | ||
| + | * If there's a fix available, and someone is verifying it, adding some verification evidence would be useful (instead of just posting a comment saying - "verified". Of course, this can be debated based on the complexity of bugs). | ||
| + | ** Relevant log fragment, stdout of a script, or a command being executed. | ||
| + | * Additional info (where appropriate): | ||
| + | ** If you've done a lot of investigation into the issue, adding a trace of that would be useful for later archival purposes. Configuration settings, caveats, reproducer scripts, etc. | ||
| + | |||
| + | You get the drift ! | ||
| + | |||
| + | == Why? == | ||
| + | * Useful for new test engineers who does not have all the context. | ||
| + | * Useful for docs folks to help them write correct errata text/release notes. | ||
| + | * Useful for non-technical folks reading the bugs/RFEs. Clear information saves a of a lot of time. | ||
| + | * Useful for downstream support organizations. | ||
| + | * If there's a regression years later, having all the info to test/reproduce in the bug, right there makes your day. | ||
| + | * Reduces round-trip of NEEDINFO between Development and QE. | ||
| + | *Useful for new users referring to these. | ||
| + | * Overall, a very ''fine'' bug reading experience. | ||
| + | |||
| + | == Resources from other communities == | ||
| + | * Bug writing guidelines -- https://landfill.bugzilla.org/bugzilla-4.2-branch/page.cgi?id=bug-writing.html | ||
Revision as of 06:10, 8 May 2013
Bug Filing Recommendations
Writing good bug reports is hard; useful reports are even harder. We should try our best to be thorough, so there's consistency and a fine experience reading bugs. This document concerns itself with outlining some obvious suggestions while reporting/verifying bugs:
- Ensure you can reproduce the bug
- Clear instructions to reproduce the bug. Bonus points for a reproducer script.
- Version details (e.g. Havana ? Grizzly)
- Test environment details
- e.g. some special hardware -- an exotic NAS, etc.)
- Verification procedure
- Include test setup details, configuration details, other relevant context.
- Most of "cloud" testing is dependent on test environment, clearer the details, lesser the round-trips between Development and QE
- If there's a fix available, and someone is verifying it, adding some verification evidence would be useful (instead of just posting a comment saying - "verified". Of course, this can be debated based on the complexity of bugs).
- Relevant log fragment, stdout of a script, or a command being executed.
- Additional info (where appropriate):
- If you've done a lot of investigation into the issue, adding a trace of that would be useful for later archival purposes. Configuration settings, caveats, reproducer scripts, etc.
You get the drift !
Why?
- Useful for new test engineers who does not have all the context.
- Useful for docs folks to help them write correct errata text/release notes.
- Useful for non-technical folks reading the bugs/RFEs. Clear information saves a of a lot of time.
- Useful for downstream support organizations.
- If there's a regression years later, having all the info to test/reproduce in the bug, right there makes your day.
- Reduces round-trip of NEEDINFO between Development and QE.
- Useful for new users referring to these.
- Overall, a very fine bug reading experience.
Resources from other communities
- Bug writing guidelines -- https://landfill.bugzilla.org/bugzilla-4.2-branch/page.cgi?id=bug-writing.html
