How many times in life, do we surrender to the habitual nature of our human psyche? Do we capitulate and allow what seems to be an established routine, repetitive task, and in our minds we've got it down to an art, so why just flip a button, and cruise on through each step of the process, without giving much time to pause between steps to evaluate where we are going?
News flash, tester or not, we all do this! In fact, I did it twice today, without even realizing it. Oh I wasn't 'testing' software at the time, but I allowed my inferred conviction of my own understanding of the early day's chores to not only lull me into a state of numbness, but introduced my own sort of performance speed bump that wasted hours of my time.
What started out today, as an early morning jaunt to accomplish to simple chore, turned into an exercise to remind me why falling into the assumption and autopilot trap are so dangerous. It started simply enough, just two chores and then I'd be home for the rest of the day, became an afternoon of back tracking, acknowledging a flaw in my own understanding, correcting it, and then executing essentially the same process, but in a slightly varied way. It started with a trip to the court house.
I was rather pleased with myself, because I thought I could complete two tasks in one visit. I might have even boasted internally, that I was a genius to take care of these two tasks at the same time. The first task, was to renew my license registration, at the Sherrif's office to bring my license plate current, and get the sticker to indicate to any law enforcement officer that might be checking my progress, that yes, I had paid my taxes and fees, and was not violating the registration laws for operating a vehicle in our state.
The second task, is one that maybe no one else will have experienced, but it required a trip to the County Clerk's office. You see, as a member of our community at larger, I stepped up back in 2006 to serve the community as a Poll worker for a number of different election cycles within our county. I do this as a service, because to be honest, the rate they pay for thirteen hours of open poll service, almost two additional hours of setup and tear down, is not a pay rate I'd accept for any of the professional work I do. However, as a concerned member of my community, an Eagle Scout, and a person of faith, I value the integrity of elections, and believe that doing so is an important part in ensuring our elections are fair. In order to participate after being selected, I have to fill out, sign, and return a form to the clerk's office. It was this task that I desired to complete today, because I had delayed sending it in earlier, due to uncertainty with my current job situation, and did not want to commit if I felt in good conscience that I would not be able to serve.
Those were the first two tasks of the day. I stepped out the door with the letter in hand, and my registration as well, and drove to the court house. I was pleased because I found a parking meter open within an easy walk, exited my car, added some time to the meter, and off I went, and that's when the first error dawned on me. I had my insurance statement, the registration, and the signed form for the Clerk, but a nagging thing in the back of mind then came into focus. 'Does the Sheriff's office take check cards, for payment?' Why I didn't ask this question before I left for the court house is unknown, but it proved to be the pivotal question, because they in fact did not take it. I asked the Sheriff's Clerks whether they accepted it as a form of payment, knowing already in my mind that the answer was probably no, and received the confirmation that, no, they only accepted, cash, check, or potentially a money order. I didn't have any of those options on my person, and truthfully I don't usually carry a check book with me unless I know I need it.
Now after reflecting I realize I could have potentially, walked over to the post office, paid the fee for a money order and then did it that way, but I'd have no record, no good one in my register to verify when it was paid. So the first task of the day, I struck out. I went ahead down to the County Clerk's office, handed the form to one of the workers, asked if it was yes, (it was), and was happy that I had at least one task done. I would have to return home, find our only check book and return to complete the initial first part of the plan.
Have you as a tester ever started working through a problem, you jumped to some assumptions, maybe you feel they are good ideas about how it in theory should work in your own mind's eye, and proceed to work through the process of massaging through the interface. Ever stop at some point to realize, you know, I wonder what would happen if I had done something differently that previous step, only to find that hitting the back button on your browser really isn't a good way to check this new test idea? It happens to the best of us. Sometimes a test that would make more sense to apply first, isn't, and has to be run again at the start of another iteration through the process. That can seem frustrating, but it is part of the learning experience we go through as testers.
Well, this did not just happen to me once, it happened twice. See I was also looking for information about a repair on my car. I traveled to the mechanic's garage I have grown to trust, and proceeded to inquire about an estimate on how they might do it, how long it would take, and at what cost. Surprisingly, they told me they couldn't do this kind of repair. They had an idea of how the repair could be done, but there was something particular about my engine that required something that they lacked, something that did not give them confidence they could complete the repair in a timely fashion.
What a bummer that was. However, I countered with a question. "Okay, if you can't perform the repair, as I understand it, then is there another shop who you might recommend to perform this fix? I know its not a critical issue on my car, but I would like to get this fixed just as soon as humanly possible." They gave me a name of another shop, and I then asked, if they thought simply calling them would be enough to get an estimate. They didn't really know, but suggested that maybe that would work, and it would save myself some money on gas driving out there unnecessarily. I liked that idea, and returned home to eat lunch with my family.
After lunch, I began looking for the phone number of the shop, first in a few paper phone books, then turned to google, and superpages, but could not find it. I found other shops, but not this one. So later this afternoon, I hopped in my car, and drove out to where the shop was (having received directions earlier). In hindsight, I wish I had pressed for a contact number before I left the first shop, but I honestly didn't believe that finding it would be that much of a hassle. That was my mistake, and yet another lesson learned.
Ever start testing a piece of software, and then at some point just stop because a question comes to the forefront, that you almost feel, man I wish I had asked that before I started? Sure, it happens, maybe more often than we like. We are creatures that learn and grow, and as Testers, we are many times going to develop ruts and habits. Try to break those habits from time to time, maybe you'll discover a new way to flex the software, to bend and contort it to find a brand new class of defects.
Ultimately, we must try our best to avoid jumping to assumptions. Never assume you already know the answer, if you've never even asked the question. Never assume that the developer obviously must have done something a particular way if you've never had a conversation about it, and never assume that you've brought and used the right tool for a type of test. Now this does not mean that we can never make assumptions, if we do, we need to realize that our testing is based on certain assumptions, maybe its a platform they are running on, or a particular style of device, that may be an educated enough of a guess to allow us to proceed, but we should remember that they are fallible assumptions, and present that as part of our test story when the time comes.
However, today's experience reminds me of something from earlier in my life. It's funny in a way, since college, my first rule of life has always been to avoid making assumptions. This was even before I considered, or even had a clue at all what it meant to test anything. Western's Rule #1: "Assume nothing, for when you assume, you are usually wrong!" At least that's how I wrote it as a freshman in college. Today I'd transform that rule to read more like this. "Make no assumption absent evidence, for assumptions are often based on illusions, that when that illusion is removed or proven false this can result in a great embarrassment to you in life." Honestly, it isn't that our assumptions are wrong, or that they might be based on inaccurate intelligence of the situation in our projects, it's the false confidence, it can breed, and the blindness it can bestow that limits our ability to test accurately and effectively that are the risk. It's the shock and awe that an illusion the team may have held as true, once removed can cloud judgment on the value in the product.
To conclude, monitor yourself as you test from day to day. Check to see if you feel yourself itching to turn on the autopilot. Recognize it, take a step back, and find another way forward. Use the pomodoro technique (Thank you Markus Gärtner), or some other focusing/de-focusing heuristic. Be skeptical of even your own best ideas relating to testing, and always strive for one more thing to learn as you flex your testing muscles. Try testing with a partner (Pair testing), so that you can keep each other from falling into a rut, or team with a developer and show him what you are doing to test the software. Whatever it is you use to affect how you keep from falling into an zombie like coma while testing, do it as often as necessary, you'll thank yourself later.
No comments:
Post a Comment