That’s twice! Twice this week my assumptions caused a bit of trouble. Last Saturday, I placed an order for parts. They are not expensive but I’m careful about my selections and want to verify multiple times that I have the right parts. On Saturday, I was confident in my selections and I placed the order.
On Sunday, I performed a test with a voltage regulator. By design, voltage goes in and exactly 3.3 volts comes out. I connected my 3.7 volt battery to the input and found 2.9 volts at the output. My assumption was the battery voltage was greater than the output (that is, 3.7 > 3.3) so the regulator should work. I didn’t have the right parts. Fortunately, I was able to remedy this assumption by amending my order.
Today, I was updating a Java program. I needed a string representation of date and time so I used the SimpleDateFormat object to create the representation. I handed the format() method a Calendar object and started the program. I was not getting the expected result. Ignoring sarcastic little voices, I reviewed my changes and added some logging. The voices were correct; it was the format() method. My assumption was I needed only to provide the method a Calendar object. It needed a DateTime object. Fortunately, I was able to remedy this assumption.
Assumptions are sneaky. Sometimes we know about them and discuss them, other times they drift in like a slow forming fog. You don’t know its there but you discern some challenge. It’s too subtle to change a direction but you’re cognizant of it.
I have many example of this experience through my recent Earl Stanley Gardner binge reading. Gardner brought us Perry Mason. If you are aware of Perry Mason only as a TV series, I strongly recommend the books. They are engaging, humorous, and full of clues. There are strong analogs to story cards. When a story card goes awry, check assumptions and check the story. One or two facts get misaligned and a defect is created. Gardner weaves multiple facts and multiple explanations for facts. It the end, Perry Mason, in the role of tester, fights through the fog of assumption, illuminates small details, and finds the one true story to exonerate his client.
As a tester, you will benefit greatly by having your assumptions dashed, and attention to detail challenged. This week, two assumptions caused some delay in executing my hobby. What assumptions might we be making that could cause a delay in our projects?