Still Life

A Series of Mental Snapshots

Posts Tagged ‘Bugs in the wild’

Bugs in the Wild: The Paradoxical Error Message Edition

Posted by Steve on April 23, 2009

A friend recently sent out a screenshot of a quite humourous error message. He was attempting to free up some space on a network drive, by deleting some files, when he received this less than helpful error message:

Error message that appeared when deleting a file

Error message that appeared when deleting a file

The text in the error message is:

Cannot delete week4: There is not enough free disk space.
Delete one or more files to free disk space, and then try again.

It can be seen that this is a faulty error message, and something else is really afoot; one cannot delete files if one cannot delete files.

An interesting question here is why this error message came up? Is this the actual reason the file cannot be deleted, if so a different error message should be displayed so as not to confuse people. If this is not the cause of the issue, then why did this message get displayed?

–Steve


Posted in Bugs in the wild | Tagged: , , , , , , , , , , , | 1 Comment »

Bugs In the Wild: WYSIWYG in WordPress Edition

Posted by Steve on April 22, 2009

I ran into this issue when creating my post for importing/exporting individual tables in MySQL. The issue resolves around the principal of WYSIWYG (What you see is what you get).

For one of the MySQL commands it was necessary to have two dashes (or minuses) next to each other, as can be seen in my the post mentioned above.  In the WordPress text editor displayed the two dashes properly in both the visual and HTML views, but after I had published the post, the two dashes where displayed (and when copied acted) as a single dash! For example the character in the quotation is seen as two dashes in the editor “–” but as can be clearly seen it is displayed as a single dash.

I tried for a while to resolve the issue, but I ended up just spacing out the dashes, like so “- -“, so that it could be seen that there were actually two dashes.

I feel this falls under a WYSIWYG type issue as in the text editor I was able to see the two dashes properly, but then when the post was published the same thing was not displayed therefore what I was seeing n the editor was not what I got in the post.

–Steve

Posted in Bugs in the wild, Testing, Uncategorized | Tagged: , , , , , , , | 4 Comments »

Anatomy of a Bug Report — Presented via a MSOffice ‘Bug in the Wild’

Posted by Steve on September 13, 2008

The importance of a bug report is definitely understated; it is the difference between something getting fixed, and something getting filed away. I am going to present my version of a ‘good’ bug report through reporting a bug I found while I was MS Office 2007. First though I am going to outline the sections:

Title
The title is actually the most important part of the bug report, it is essential that it is possible to know what the whole problem is simply based on the title. If you cannot express what the bug is completely in the title, you have to think more about before reporting it.

Preconditions
Pretty straight forward, put what needs to be setup before the bug occurs, it can also include what machine configuration you used (if its meaningful)

Steps To Reproduce
Another straight forward area of the bug report. what you want to aim for here is that someone who knows nothing about the bug and possibly very little about the product can reproduce it. There preferrably should be no questions about how to hit the problem again (I do realize this is problematic with the bugs that appear to happen ‘randomly’)

Bug Details
The important things to include here are what the problem is (as you see it) and what you think should be happening. If you do not but a suggestion or desired outcome, the bug is not nearly as useful.

Frequency
This is a field that does not always apply, it generally is important with bugs that have to do with scalability and ones that seem to happen intermittently.

The Bug Report:

Title: Having the ‘Create Source’ window open results in any other open window becoming unusable

Preconditions:

  • Two instances of MS Office Open

Steps to Reproduce

  • In the first MS office window click the references tab
  • In the toolbar click ‘Insert Citation’
  • In the drop down list click ‘New Source’, the create source window will open
  • Click the mouse onto the second Office window

Bug Details

  • At this point nothing can be done in the second open window, you cannot click, or manipulate the window in any way.
  • Desired Outcome: The second MS Office window should not be affected by the Create Source window in any fashion
  • Note: A further issue is that a new Office window does cannot be opened (for example from the start window)

Frequency

  • Anytime the Create Source window is open

So there you have the bug report, if I had access to the proper software I would also have made and attached a video of the problem, video is a great bug reporting tool, one that I suggest is BB TestAssistant .

Let me know what you thought of my bug report! Does it match how you file bugs?

–Steve

Posted in Bugs in the wild, Testing | Tagged: , , , , , , , | Leave a Comment »