Sirius Ruminations The official blog of David Gilbert and Sirius SQA

Who We Are


David Gilbert is the President and principal consultant at Sirius SQA. He has been testing software for over 10 years. A member of the context driven school of testing, he is a strong and outspoken advocate for the value of manual software testing, exploratory testing, and testing as a thinking profession.

dgilbert@sirius-sqa.com
David on LinkedIn

RSSMy Recent Tweets

Recent Comments

 

September 2010
M T W T F S S
« Jul    
 12345
6789101112
13141516171819
20212223242526
27282930  
  • Cups Should Sit Flat?

    I recently went to a conference, my favorite, StarEast.  For many reasons, I have been laying low this year, so for the first time in many years, we did not participate in the vendor expo, and I did not submit a presentation.  I was simply an attendee.  However, since we have been so heavily involved for so many years, when I checked in I was pleasantly surprised to receive a small gift for being an alumnus, an insulated coffee mug with this years conference logo on it.

    Now, I am a caffeine addict, so I was very happy with this surprise and knew I would make good use of it over the next few days at the conference.  However, I am not part of the coffee generation.  Hot tea is my fix of choice.  So, next morning at breakfast, I dropped two tea bags into my new bright shiny cup, filled it up with almost boiling water, and walked over to my table.  As I sat down, I put the cup on the table next to my plate, and as my hand left the cup…it moved!!  It wobbled away from my hand, and the previously calm surface began to ripple in that telltale fashion that immediately precedes a cups imminent disastrous toppling.

    With my brain feverishly trying to calculate the odds of an entire cup of boiling hot water spilling onto what passes for a bistro table in hotel breakfast bar and somehow miraculously not ending up mostly in my lap, I quickly and desperately reached out and grabbed the cup again.  With the disaster averted, I caught my breath, relaxed, and let go of the cup again, careful not to hit it with my hand or anything like that this time around.

    It wobbled again.

    And so the tester in me took over, and I began to investigate this behavior.  I soon discovered that the bottom of the cup was slightly convex, not so much that it was actually likely to fall over, but enough to make it wobble somewhat.  Enough to be disconcerting.

    This made me wonder, Why had I never seen this before?  Why had I never even thought of it?  So I began looking at other cups.  Turns out, there is a fairly standard method of preventing this.  Most cups have a lip on the bottom, a raised edge around the perimeter of the cup that is ground, or shaved, or planed, or in some way mechanically adjusted to make the cup sit flat, in spite of the fact that the cups actual bottom, due to the nature of materials cups are made of (glass, ceramic, wood, plastic) is not flat at all.  But MY cup, apparently, chose to not employ such a design philosophy, instead apparently relying on its ability to actually BE flat on the bottom.

    Bad Choice.

    So this made me wonder, whose fault is this?  I am fairly certain that the folks at SQE did not say “Oh, yeah, and make sure it wobbles.”  On the other hand, I’ll also bet they did not say “Oh, yeah, and make sure it sits flat.”  They would have had no more reason to say this than they would have had to say “Oh, yeah, and make sure it can actually hold some liquid.”  These things are known, understood, taken for granted…and that is fine.  They should be.

    As software testers, we need to understand that that same reality applies in our world as well.  Some things are just understood.  Within any given context there are a collection of well defined implied requirements for an application.  There is no reason to state those requirements explicitly.  To do so only adds clutter.  This is important for testers to understand.  It is this very fact that makes the following statement patently absurd:

    “I can’t test your application;  you have not given me all of the requirements.”

    Of course they haven’t, and they shouldn’t, and it isn’t likely that they ever will.  And for any tester to make that statement is simply insulting to the rest of us.  There is tons of testing that can be done in the absence of ANY explicitly stated requirements, and certainly in the abscense of the complete set of all explicitly stated requirements.  A requirement only needs stating for testing if it in some way violates an existing implied requirement.

    Here is an example:  In any Windows application, there is a button in the upper right hand corner with an “X” on it.  Clicking this button closes the application.  However, in recent years, there is a growing trend to attaching a different behavior to this button, specifically to close the GUI, but leave the application running, and place an icon in the SysTray for user access.  Now, if I am given an application to test, and I find no documentation on what that button should do, am I powerless to test that button?  Of course not…I simply presume it will follow the implied requirement of actually closing the application.  If I test it and it does that, all is well.  If it minimizes the application to the SysTray, then I would ask the developers to state the requirement so that the ambiguity could be resolved.  If it did anything other than those two behaviors, I would call it a defect and move on with my testing.

    So as I sit here drinking my morning tea….umm, my FIRST cup of morning tea…out of my new, bright, shiny wobble cup, I am constantly reminded of this fact.  It is somehow comforting.

    Hey, you don’t suppose the folks at SQE planned it that way all along, do ya?

    Share/Save/Bookmark

    Published on May 22, 2008 · Filed under: Conferences, Ideas and Ramblings, Processes;
    No Comments

Leave a Reply

You must be logged in to post a comment.