Here they are:
|
1 |
2 |
|
3 |
4 |
| testing.com > Testing Craft > Techniques (Handling Bugs) > wvHtml Shading Bug Report |
Created and summarized by Brian Marick.
This is a bug that I discovered in the AbiWord project. It describes a problem in the way the wvHtml Word-to-HTML converter handles shading in Word tables. This bug report is the product of a process of failure improvement described here.
I think this is an example of a well-written bug report, but it has flaws. You can find them in the summarized discussion below.
The bug report was sent by email, so it refers to attachments. For your convenience, I've shown what the attachments look like on this page. The real attachments are available for download at the end of the report.
I've put comments about the bug report inside the original text. They're in italics.
Date: Tue, 09 Nov 1999 10:36:45 -0600
To: Caolan McNamara <Caolan.McNamara@ul.ie>
From: Brian Marick <marick@testing.com>
Subject: wv bug: Word table shading not preserved in HTML
output
Notice that I've taken some care in the Subject to suggest what area of the code is incorrect ("table shading") and what the actual failure is ("not preserved in HTML output"). The "wv bug" is there because Caolan presumably gets mail on many topics and I want the Subject to immediately label this as a wv bug report. Were I using a bug tracking system, I wouldn't need that tag.
The first attachment contains a 2x2 table with black shading applied to the whole table. The second attachment is the resulting HTML file from wvHtml.
Here they are:
1
2
3
4
I expected the background to be black, but it looks white.
Moreover, each <td> and <p> directive for the cells
of the table explicitly sets the background to White:
<td bgcolor="White" width="50.00%" rowspan="1"
colspan="1">
<p style="text-indent: 0.00mm; text-align: left; line-height:
normal; color: Black; background-color: White; ">
I've taken care to describe what the expected output is and the ways in which the actual output differs. It's important to do that even when I think the failure is obvious. Sometimes it's not.
For the moment, I'll hold off on further shading tests, unless there's something you'd like me to check.
It's my opinion that I as a tester am here to serve the developer. Offers to provide help are part of establishing a good working relationship with testers. See my paper "Working Effectively With Developers".
= Additional information:
It's courteous to separate the inessentials. By making this separation, I'm saying "If you've already formed a judgement of the importance of this bug, nothing past this point is expected to change your mind." The further information is expected to be of interest only when the developer dives into fixing the bug. It can be ignored before then.
There's more than one way to create a table with shading, so I describe which way I did it. It probably doesn't matter - what matters is what's in the Word .doc file - but it may. It may describe a class of documents that Caolan overlooked. (Unlikely, but it doesn't hurt.)
It's important to describe the configuration and environment in which the bug occurred. What if the bug doesn't occur on Linux? Caolan could waste a good deal of time with an unreproducible bug. It takes some experience with an application to know what the right amount of background detail is.
It's useful to identify related cases that don't work, or related cases that do work. Here, I'm calling attention to the fact that the Shading is incorrectly set to White even when there's no shading at all. I'm suggesting that colors are chosen when they shouldn't be, not just that the wrong color is chosen.
Here's the table:
A good way of demonstrating what I expected to see. Here's the table. Note that the text is invisible because it's black against a black background. (Word helpfully makes the black characters appear white when it displays them, but they're really black.)
1
2
3
4
Warn Caolan away from an extraneous fact that might otherwise capture his attention. Chasing after this probably has nothing to do with fixing the shading bug.
Further describe the situations in which the failure occurs. It doesn't just occur when there's no shading or when the shading corresponds to a shade (like "Black" or "White") that is predefined in both Word and HTML.
Enlarge the scope of the failure. It happens with at least two distinct types of shading: whole-table and cell. (This might better be placed above the "Additional information" line, since Caolan might assume it's only a whole-table shading bug, which would have a lower priority than an all-types-of-shading bug.)
Attachments
Be the first person to add a comment in the
Wiki Forum at page WvhtmlShadingBugReport.
(The Forum is explained in its FrontPage.)
Danny Faught writes:
"I'd suggest using a stronger and more concise term like "lost" instead of "not preserved". That also gets the attention-getting part of the summary closer to the beginning of the line and more likely to be read in a long list of bug summaries."
He's right.
Danny and Cem Kaner point out that the additional information is disorganized. They're right. I first have a bullet item that jumbles together information about the configuration of my machine, how the program was compiled, and how I invoked it. Then there's an example of a different failure that probably has the same underlying cause. Then there's an example of correct behavior. Then there's a note that an error message probably has nothing to do with this problem. Then there are two more failures that probably have the same underlying cause. It would have been better to clearly label and organize the different types of information I was presenting.
