A Case Study of Failure Improvement (page 3)

testing.com > Testing Craft > Techniques (Handling Bugs) > Failure Improvement > Case Study

A Case Study of Failure Improvement (Part 3)

Created and summarized by Brian Marick.

In the previous installment, I looked at a bug where the Word document had a border, but the wvHtml output did not. The original failure also had the opposite situation: instances where the Word document didn't have a border, but the wvHTML output did. Is that an artifact of the complex table, or a simpler bug? Can I demonstrate the simpler bug?

I began with this Word document. Because the bugs have been pretty easy to isolate, I decide to add a nested list, just in case I could find some list bugs along the way. (I suspect the list handling is more mature than the table handling.) This probably costs me no extra time, because I use the list to explain how I created the table. It's likely I'd have to write that text anyway, so I might as well do it in the Word document.

I've added the outside border to make it easier to distinguish the Word text from this surrounding text.

In retrospect, my explanatory text is bad in at least two ways:

The description begins after the table already exists. For some bugs (but probably not this one), it would be important to specify how the table was created - else the programmer would try to reproduce the bug, create the table in some other way, and never see the failure.
The sentence "The text was added after the table was created" is ambiguous. After the table was created but before the borders were changed? Or does "table was created" mean the whole process up through fiddling with the borders? I write this eight days after creating the file, and I no longer remember! This is sloppy testing practice. (But it, again, almost certainly won't make a difference.)

The wvHtml output looks like the following. (I've added the tinted background and border to more clearly separate the output from this surrounding text.)

This is a 2 x 1 table with no border on the left cell. It was created by

turning off all the borders on the left cell by:

putting the cursor in the cell
Entering the Borders and Shading dialog
Selecting the None setting
Applying the setting to the cell (rather than to the table) and hitting OK.

Turning the right cell's leftmost border back on by doing the same thing, except selecting the Box setting.

The text was added after the table was created.

This is text in the table cell

The lists look correct, but the table is wrong. It has a border around the originally-borderless cell. It also has the border-within-border effect that, although default behavior for HTML tables, does not look much like the original Word table. (It looks closer under IE 5.0 than Netscape 4.5.)

With Internet Explorer 5.0 and perhaps recent Netscape browsers, you'll see that the the text has white spaces around it. In Netscape 4.5, everything's light blue. That's because IE is honoring HTTP paragraph styles - a more recent innovation. As I gain more experience, I'll be better able to tell whether this is an incompatibility that wvHtml should be working around. It may be that wvHtml should be generating different HTML for those paragraphs. (I suspect that this is a bug related to the white shading in part 1.)

How does Word's own HTML export do?

This is a 2 x 1 table with no border on the left cell. It was created by

turning off all the borders on the left cell by:

putting the cursor in the cell
Entering the Borders and Shading dialog
Selecting the None setting
Applying the setting to the cell (rather than to the table) and hitting OK.

Turning the right cell’s leftmost border back on by doing the same thing, except selecting the Box setting.

The text was added after the table was created.

This is text in the table cell

The table also has the extra border, though the border-within-border effect is so muted that the border actually looks right. Note, though, that Word doesn't get the list right: there are two list elements labeled "1".

Note that the two HTML exporters produce tables that behave differently when set against a colored background. I discovered this only when preparing this writeup. Still, it's worth noting this in a design note I'd written back in Part 1.

This example in itself does not seem to be enough to file a bug report. I need to explore more. Are there cases in which omitted borders are correctly converted? Is it even possible to create HTML tables like my original one? (I'm pretty sure it is, but I've never done it. Maybe both wvHtml and Word are doing the best they can, in which case it would be pointless to file a bug report.)

At this point, I face a decision. I'd started out intending to test Word import not HTML export. HTML export was only to be the means by which I discovered Word import bugs. So it didn't bother me that I was fairly ignorant about HTML. Moveover, I was under deadline pressure. These are the original Testing Craft case study pages, and I needed to get something up and viewable not long after the announcement in Software Testing and Quality Engineering Magazine hit the streets. And I was, after all, really just fiddling around with a first exploratory example, preparatory to doing serious test planning and design. Why spend time reading the HTML spec?

However, judging wvHtml's output by its visual appearance seems to be causing me problems. It seems I could be more efficient by "looking under the hood", by thinking about the HTML wvHtml is trying to produce, rather than ignoring that intermediate step.

This has its risks. As we'll see, wvHtml has a particular approach that uses HTML styles. By focusing on that approach, I may become blinded to its shortcomings. I could conceivably choose tables that exercise the things wvHtml does, rather than tables that reveal the shortcomings of its whole approach. That's a common problem when programmers test their own code, and testers can also become "infected" by an implementation point of view.

But I've been using Word tables for years. Even though I'm hardly an expert user (I've never read any user documentation, of course), it seems unlikely that a cursory understanding of HTML will dominate my knowledge of Word.

So let's look under the hood!

Here's the HTML for wvHtml's table, with annotations and improved indentation. To learn what to write in the annotations, I browsed (lightly!) the relevant parts of the HTML 4.0 specification.

<table width="100.00%" border="1">	A full screen table with a one-pixel border. That 'border="1"' is the reason the cell whose border I turned off in Word is displayed with a border.
<tr>	This marks the beginning of the single row in the table.
<td bgcolor="White"	This is a cell. Its background color is white. Recall the shading bug? The background color should perhaps be clear.
width="50.00%" rowspan="1" colspan="1">	More of the <td> command. This cell is half the table. It spans one row and one column.
<div align="left" style=" border: thin none Black; padding: 0.00mm 0.00mm 0.00mm 0.00mm; ">	The div element is a way to describe the presentation style of the various elements up until the closing </div>. This one says that everything should be left aligned. The border around this table cell should be thin (if drawn), but without a border, and a black color. Query: if there's no border around this cell, why is there the border-within-a-border effect? Answer: that's an effect of the table border, as you can see by changing the border to "0" in the <table> directive. In that case, the table will be without any borders anywhere. There is no padding in any direction.
<p style="text-indent: 0.00mm; text-align: left; line-height: normal; color: Black; background-color: White; "> This is text in the table cell </p>	A bunch of text formatting, then the actual text in the cell. There's nothing here that affects the border. Should the background color be White? wvHtml's habit of making all background colors explicitly White accounts for the funny white blocks around text you saw above (if you use IE 5.0).
</div> </td>	These directives end this cell.
<td bgcolor="White" width="50.00%" rowspan="1" colspan="1">	The start of another cell.
<div align="left" style=" border: thin none Black; padding: 0.00mm 0.00mm 0.00mm 0.00mm; ">	This cell (the one that has a border in the Word document) has the same <div> tag as the cell without a border.
<p style="text-indent: 0.00mm; text-align: left; line-height: normal; color: Black; background-color: White; "> This is text in the table cell </p>	Same as previous HTML cell, even though the source Word cell is different.
</div> </td>	End of cell
</tr> </table>	End of row, and of table.

If you look at Word's export of the same table, you'll find that it's rather different. The two programs take a very different approach - that's one reason to worry that I may be putting on blinders by looking closely at wvHtml's output. After all, end users don't care about HTML - they care about what they see in their browser window.

So. Know that I know more about the HTML output, how should I proceed?

There are borders around the whole table and borders around cells. Fiddling with either one might generate useful bugs inspired by the original failure. (That failure now seems an episode from my distant past.)

I'll first focuson the table's border attribute, since it's the first border-like thing in the above HTML. That attribute lets you control the whole table's border. Word's Border and Shading dialog also lets you control the whole table's border. How do they interact? Let's see!

I created a Word document with two single-cell tables with no table border:

What does wvHtml do? It gets both the tables wrong:

This is a 1x1 table with no border. It was created with a border, then the text was added, then the cursor was placed in the text, then the Borders and Shading dialog was entered, then the None setting was selected and applied to the whole table.

Here is the text

This is a 1x1 table created in the same way, except that the None setting was applied only to the cell.

Here is the text

What does Word do? It gets the first example right, but the second one is wrong.

Here is the text

This is a 1x1 table created in the same way, except that the None setting was applied only to the cell.

Here is the text

This seems a straightforward bug. wvHtml doesn't seem to succeed at a simple one-to-one translation: no table border in word => no table border in HTML.

But before reporting a bug, I should consider whether this is "as designed". HTML, especially in its older versions, wasn't intended to be as powerful as Word. Even though wvHtml uses the more recent style sheets, maybe it's trying to strike a balance. Maybe with complicated tables, a really faithful translation that will look perfect in more modern browsers will look truly awful in old browsers. So maybe it's trying to produce tables that look equally - but not truly - awful in all browsers. The design tradeoffs appropriate for more typical tables might be misleadingly wrong for such an unrealistically simple table.

For example, if you change the <table> attribute's border in our first example to 0 (no border), you get a table that has no cell borders, instead of one that incorrectly has two. Which is worse? Probably the border-less table, because it's less obvious that it's a table at all. There are ways to create a table that has the right borders even in old browsers. For example, here's one that uses nested tables. But it seems to me - no expert - that the old-style browsers simply understand a dialect of HTML too impoverished to do a good job in general, and that attempts to cater to such browsers would conflict with the HTML needed for more recent browsers.

I'm guessing that backward compatibility is not the intent in wvHtml. But, before filing a bug report, it makes sense to ask the developer. While awaiting a reply - he lives six time zones away and doesn't do this as his full-time job - I'll move on. (not done)

Related Testing Craft Pages

There's more about handling bugs in the index of techniques.
The approach I'm taking in these pages is kind of dumb. For an explanation of why, and for a better approach, see this case study of adding test support code.

Be the first person to add a comment in the Wiki Forum at page FailureImprovementCaseStudy.
(The Forum is explained in its FrontPage.)

Summarized Discussion

In this spot, the author of this page will occasionally summarize the discussion in the Forum.