I'm in love with the word “appears” when describing software. The word “appears” allows us to describe what we observe without making untrue statements or losing our point. And I think it leads to better communication.

For example, let’s say the AUT is supposed to add an item to my shopping cart when I click the “Add Item” button. Upon black box testing said feature, it looks like items are not added to the shopping cart. There are several possibilities here.

• The screen is not refreshing.
• The UI is not correctly displaying the items in my cart (e.g., the database indicates the added items are in my cart).
• The item is added to the wrong database location.
• The added item is actually displaying on the screen but it’s not displaying where I expect it to.
• A security problem is preventing me from seeing the contents of my cart.
• Etc.

The possibilities are endless. But so are the tests I want to execute. So like I said in my previous post, after determining how much investigation I can afford, I need to log a bug and move on. If I describe the actual result of my test as “the item was not added to my cart”, one could argue, “yes it was, I see it in the cart when I refresh...or look in the DB, etc.”. The clarification is helpful but the fact is, a bug still exists.

Here is where my handy little word becomes useful. If I instead describe the actual result as “the item does not appear to be added to my cart”, it becomes closer to an undisputable fact. Once you begin scrutinizing your observation descriptions, you may find (as I did) yourself making statements that are later proven untrue, and these may distract from the message.

Think about this a little before you decide this post appears to suck.


  1. Alex said...

    Language is wonderful. By making a slightly less accurate statement, it because much more difficult to disprove.
    There's always a tradeoff for a tester as they try to decide how much information is necessary to add to a bug.
    In your example, I'd say it was clearly worth it to try pressing the refresh button.
    I'd also argue that it would be worth it to check the database to make sure the data is actually in the cart -- assuming this was not extremely difficult or time-consuming to do.

    Should the QA person run the client using an IDE debug tool and find the actual spot in code where an error occurs? Well, again, I can argue there are times when they should -- but likely not all the time.
    Sometimes the tester's time is better spent finding bugs and not investigating them. Sometimes the developer's time is better spend coding and not investigating bugs. I don't think there's a general answer that will satisfy every situation.

Copyright 2006| Blogger Templates by GeckoandFly modified and converted to Blogger Beta by Blogcrowds.
No part of the content or the blog may be reproduced without prior written permission.