Tips from a Gold uTester - Travis Howell
Author: Travis Howell [August 2010]
How fitting to the time of year. It’s summer, it’s hot – for some of us it’s very hot – and a pool looks so inviting. Tell me this: Would you jump into a pool if you didn’t first know how to swim? My guess is that your answer is NO. This world presents a lot of open invitations – invitations that appeal to our wants and desires and make it easy for us to just jump right in. I have to admit, sometimes it’s nice to be first. After all, we live in a generation that rewards the person that comes in first.
Testing Is NOT About Being First
It’s not about the first person to find bugs or the first person to complete their work. To test is: to be informed, to understand, to question, to investigate, to identify, and to communicate. In the end, it’s about providing the customer with the ability to deliver a superior product. And once they bring that product to market, who is ultimately the winner? You, the consumer.
What’s This — A New Test Cycle In My Inbox?
A new test cycle is an open invitation for everyone to jump in the pool. I know how inviting that test cycle invitation is, and I can guess what’s going through your mind. “What do I have here, a new test cycle. Looks like I’m the first participant, the world is my oyster. I’ll get in, look around, get a jump on everyone, score a few bugs, rack up some dollars, and out I go.” Easy money right? Maybe, maybe not.
Let me take you back to my first question, would you jump into a pool if you didn’t first know how to swim? Now, let me re-phrase it as it relates to testing. Would you enter a new test cycle without first knowing what the expectation of the customer is and what is expected of you to test? The correct answer is NO, but the lure of ‘easy money’ is there and provides the temptation to push a few in the pool. As an example, I have seen a large number of bugs logged to a test cycle where it is clearly identified within the objectives that testing is not to begin until a future date. We’re all guilty of moving too quickly sometimes. But don’t forget one thing, what you don’t know could come back to bite you.
Preparation Is Key – Understand The Details!
Read the objectives of the test cycles, understand what the requirements are. It hurts when you enter a bug on a browser that was not listed as a requirement. Documentation attached to the test cycle is not just there to look pretty. These are valuable resources provided to eliminate questions and eliminate entering bad bugs. Take advantage of the open invitation to ask questions of the project manager. If anything within the objective is unclear, ask the question. A question is learning experience, and if you have a question I guarantee that there are others who are in need of the same answer. Embrace the discussion thread, it’s there for a purpose and serves that purpose nicely.
Know Your Limitations
Before you commit to a test cycle, understand what is expected of you. There are all kinds test cycles, some large, some small, some public, some private. If you happen upon a test cycle where there are a limited number of participants, before you commit be sure you are able to meet the expectations. Do you have the time, can you meet the deadline, do you have the experience, and do you have the right technology? If you second guess any of these questions, the right approach may be to let this one go. Also, ensure that you can handle the workload. Never bite off more than you can chew. We are the devoted few and that’s what makes us special.
The Database Is Your Friend
Defects are logged to provide a comprehensive picture of issues that have already been identified. We are a community of testers working together, sharing information. As such, we should understand what other testers have already uncovered and embrace the discussion threads as a viable resource to communicate with each other and assist each other in overcoming hurdles. Before you enter that defect, ensure that it hasn’t already been discovered by another. If, within the objectives it is stated that tester feedback should be logged, take advantage of the opportunity.
Speaking from experience, a tester is not just someone who tests. They are someone who has become an expert on the product. If something doesn’t fit the product and there’s an alternative which may add value, voice yourself. The design phase can sometimes run down a ‘one-way street’. On a one-way street there is no option other than going in the direction you are forced to drive. Being familiar with the product, we have the ability to see a two way street. You know the saying there’s more than one way to skin a cat. Sometimes it takes another set of eyes to see that their may be a better direction to take than the one that was chosen.
But wait, That’s A Lot Of Bugs!
Sometimes the number of bugs found deters us from working on a test cycle. Nothing is more disheartening than entering a test cycle and seeing that 95 bugs have already been entered. And what do we say to ourselves, obviously there can’t possibly be any more bugs left to find. Let me tell you, where there’s one bug, he’s usually got a friend and where there’s a 100 bugs well, that’s a party. The goal of a test cycle is not to reach a particular number of bugs (xx) and call it a day. The goal is to ensure that we have done all we can, that we’ve tested each area of the application enough to feel good about the end product. If there’s been 100 bugs found, great, make it a challenge to find those next five
Once You’re In The Pool….
We are the lucky few. We have the ability to see the future, to touch it, test it, learn it. We are ahead of the curve. We have all been given a great opportunity to explore technology that has yet to come to market. Embrace the future!
