Better Software - May 2008 - (Page 8)

Editor’s Pick A mechanic’s tool box is not complete without a socket wrench set. I couldn’t imagine getting anything done on my car without it. My grip strength and knowledge of car mechanics alone isn’t going to loosen a lug nut. The first time I tuned up a car, I brought out the socket wrench set. With relative ease, I removed the air filter housing, the spark plug wires, distributor cap, and rotor button. But when it came to removing the spark plugs, I found out I was missing the right tool for the job: a spark plug socket wrench. Not wanting to double the work because of this mistake (reassemble everything, go to the store, disassemble everything, and then reassemble the new components), I opted to walk to the local automotive parts store. During that walk I vowed to make sure I always had the right tools in hand prior to tearing apart a car. I’ve stuck to that vow ever since. It’s been a while since I’ve had to work on my car, but I still have that tool set complete with a spark plug socket. There are people out there who’ve laughed at my story and said, “Why didn’t you just use a large socket to loosen the spark plugs?” Yes, I could’ve used a socket wrench large enough to do just that job, but removing the plug would have required additional tools and would have added more steps to a simple process. Why go through all the extra hassle when there’s a tool specifically designed for the job? I think David Gilbert would have argued in defense of the spark plug socket in my scenario. In his article, “A Hammer and a Nail,” David opens with the old axiom “If the only tool you have is a hammer, you tend to approach every problem as if it were a nail.” While there’s nothing wrong with the hammer, it’s not always the right tool for every job. David reminds us that we have to consider the level of efficiency and accuracy we’re trying to achieve to decide what tool would work best for a given scenario. In software development terms, we spend a lot of money buying tools that automate specific tasks. Many times we’re so invested in these tools that we try to use them for a variety of tasks. David reminds us that there are other tools in our tool box—basic ones that we sometimes forget, like manual testing. Before you use a hammer to pound out your problems, stop and think of what you’re trying to accomplish. Always keep in mind that there’s a right tool for every situation; sometimes it’s the one buried beneath all the new tools—one you probably forgot you had all along. Read this month’s Editor’s Pick, “A Hammer and a Nail,” at www.stickyMinds.com/editorspick10-4 Francesca Matteu Editor, StickyMinds.com fmatteu@sqe.com Quotables “’No good test—except one performed by an automaton—is entirely scripted, either.’ Excellent quote to walk away with! As far as when to stop testing? I almost always respond with ‘When I’m done.’ Which then (hopefully) leads to ‘And how do you know when you’re done?’ One item we track and share is the bug discovery rates while testing. How often are we finding new issues or, when we’re validating fixes on past issues, do we discover side issues that arose from the fix? If the discovery rate keeps climbing—or even remains flat—it’s still time to keep testing. Only when we see the discovery rate decline do we start getting comfortable; and this is usually a time when others’ eyes are needed on the project. ” StickyMindS.coM MeMber bo roop coMMenting on Michael bolton’S article “how Much iS enough?” www.stickyminds.com/quotables10-4a “As tempting as it is to dismiss the need for testing COTS applications, it’s just not that simple. Take the time to analyze the application so you can balance the cost of testing against the potential risk and cost of failure. And then, after you test, all there’s left to do is hope that it works. ” linda hayeS, “teSting cotS: when, how, and how Much?” www.stickyminds.com/quotables10-4b “A tester on an agile team may test a screen that’s half finished, missing some validation, or missing some fields. It’s incomplete—only one part of the software—but testing it in this incomplete stage helps reduce the risk of failures downstream. It’s not about certifying that the software is done, complete, or fit to ship. To do that, we’d need to drive the ‘whole car,’ which we’ll do when the whole car is complete. ” Jeff patton, “an uncoMfortable truth about agile teSting” www.stickyminds.com/quotables10-4c “I was once told by a manager that you don’t learn from good projects, and although that is not strictly true, you do learn more from the bad ones. ” StickyMindS.coM MeMber Meredyth Mackay coMMenting on fiona charleS’ “pack up your troubleS” www.stickyminds.com/quotables10-4d 8 BETTER SOFTWARE MAY 2008 www.StickyMinds.com http://www.StickyMinds.com http://StickyMinds.com http://www.stickyminds.com/quotables10-4a http://www.stickyminds.com/quotables10-4b http://www.stickyminds.com/quotables10-4c http://www.StickyMinds.com/editorspick10-4 http://www.stickyminds.com/quotables10-4d http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - May 2008

Better Software - May 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Cover Story: It's A Bug! The Chivalrous Team Member Let's Talk Agile Product Announcements 10 Things You Might Not Know About... The Last Word Ad Index

Better Software - May 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.