What I Learned from "The Hitching Post"

When I was in high school, many moons ago, I worked on the school newspaper.  It was a great experience that I remember fondly to this day.  One of the funniest things that happened was when the editor (another student) had accidently applied his name to an article I had written.  I was able to “pay him back” in the April Fool's Day  edition by submitting an article where he had been arrested for it…

I learned a lot about gathering information and sticking to the facts in that class.  The instructor was passionate about hammering home a couple of important things to remember when submitting an article.  And, believe me; it did not get published if it did not pass the test.  The first thing he hammered home was "just the facts, ma'am".   As a reporter in his class you were writing articles, not editorials.  Your opinion was not to be included in the writing.

The second thing he hammered home was the 5 W's and 1 H concept.  I think he must have said them aloud to us every day in the beginning of class…

I have found that these two items that were drilled into me in that class easily pore over effectively to reporting bugs. 

Reporting the facts only prevents friction between development and testers.  It largely prevents reports that seem to be attacking developers.

The 5 W’s and 1 H, in a simplified context, could look something like this:

1.       Who? – The application/system/product in test

       2.       What? – What feature/component/link/etc.
       3.       Where? – Where is the testing taking place, what is the environment
       4.       Why? – If you think you know what might be causing the bug, add this to the report
       5.       When? – What is the state of the application/system/product when this bug is revealed
       6.       How? – What are the steps to reproduce the bug

Of course this is shown at a very simple level, but when considered during testing, these items are very useful in gathering information that will speed up the time it takes to get the bug addressed. 

Sometimes, testers get caught up in the ability to “break” the application/system product, and forget that the reporting of the bug is more important in getting it fixed.

Here is an example of a fake bug report.  In honor of the newspaper I worked on in high school, I will call the pretend product “The Hitching Post”.  One of its features is the ability to create text documents.  This is the kind of report I have seen go through the bug tracking system when the concepts above have not been considered:

Headline – The application crashes when attempting to save a text document

Steps to Reproduce:

     1.       Open a text document
     2.       Click the Save icon
     3.       The application crashes

When I have seen this type of report, I will send an inquiry for more information.  Usually I will ask questions.  In this example, I would likely ask at least the following:

1.       What OS is the product installed in?

      2.       What version of the product are you testing in?
      3.       What state was the document in?  New, previously saved, edited?
      4.       If the document was edited, what was entered in it?  Illegal characters, font change, number of characters?
      5.       Does this occur when using the Save menu item or shortcut key?
      6.       When the product crashes, is there an error message?  Is the message a product message or a system message?
      7.       Are there any error logs that can be attached to the report?

My belief in writing bug reports is to have development spend little to no time in coming to see me or talk to me – about the bug reports, that is J  I find that applying these concepts to the report have caused me to be more focused on gathering as much information as I can.