Better Software - September 2008 - (Page 10) eDItor’s PICk Caught Without a Master Plan When the power window on the front passenger side of my car stopped operating, it was only three quarters of the way closed. I knew that this was destined to happen since my car is an older model, but I was hoping it wouldn’t happen during the local rainy season. First thing I did was manually test both switches. Nothing happened. Quotables “In 10+ years as a tester and test manager, I looked beyond the details of the product under test to the wider system issues and encouraged my team of testers to do the same. It led to a high degree of respect among the developers. We measured success in terms of customer use and tried to focus on objective measures that reflected customer experience. Along the way we rewarded both team performance (development and test) as well as individual performance. Delicate balance, but needed to reach top performance as an organization. ” Ed WEllEr commEnting on linda HayEs’s column, “may i takE your tEmpEraturE?” www.stickyminds.com/quotables10-7a “Sometimes I like to describe security vulnerabilities as if they were people or characters instead of abstract concepts, with a human face on them so they’re a little easier for people to understand. For example, SQL injection is kind of like James Bond: He sneaks into places he’s not supposed to have access to and then escapes with all of your secrets. A buffer overflow is like Mr. Creosote from Monty Python’s The Meaning of Life: He tries to cram way too much data into a space that’s not meant to hold it, and the results are disastrous. If Cross-Site Scripting (XSS) were a person, it would definitely be Rodney Dangerfield. XSS never gets any respect! Bryan sullivan, “sHoW somE rEspEct to cross-sitE scripting” www.stickyminds.com/quotables10-7b Francesca Matteu Editor, StickyMinds.com fmatteu@sqe.com mistakE 1: I based my following actions on the results of a single, simple test. I assumed that the electronic regulator motor was broken, so I bought a replacement and was content with the idea of installing it myself. mistakE 2: I checked the service manual for additional information after buying the replacement motor. Lo and behold, the service manual listed instructions for a series of extensive tests to help troubleshoot the cause of a non-functioning power window switch and motor. I didn’t have the proper tool (a multimeter), so… mistakE 3: I skipped the tests. Not such a smart idea! mistakE 4: I asked for help after I had wasted time, gas, and money believing the motor was damaged. My cousin and my father, both of whom have electrical engineering knowledge, offered to help troubleshoot the window motor. They lent me a multimeter and taught me how to use it. We tested every single connection, the ground, and the relays. We even jumped the existing motor to see if it would work—it did! Then we backtracked through the wiring to the fuse box … where we found a burnt fuse. Once we installed a new one, the window automatically rolled up. Talk about an unexpected result! That led us to test other components that could have blown the fuse. We finally determined that the master switch in the driver’s door was broken. (For those of you who are curious to know the exact cause, the master switch for the front passenger window shorted while the signal relay to roll up the window was engaged.) Besides my biggest mistake—jumping to a false conclusion, I am also guilty of not having planned for extensive testing in order to find the source of the problem. Looking back at this spate of errors, I realized I let the afternoon thunderstorms scare me into relying on a quick fix. In this state of panic, I rushed into action without having a master plan. Rick Craig’s article “Test Strategies and Plans” details how master test plans directly affect the success of all software testing. Yet because we’re always strapped for time, we omit drafting a plan and opt to dive right into testing, usually late in the project when time is even more scarce. Master test plans force us to analyze what should be tested and when. According to Rick, “Discussing issues of what and how to test early in the project lifecycle can save a lot of time, money, and disagreement later.” To read Rick Craig’s “Test Strategies and Plans,” visit www.stickyMinds.com/editorspick10-7. 10 BETTER SOFTWARE SEPTEMBER 2008 Nobody wants to be a drone—well, unless you have an unhealthy fascination for bagpipes or worker bees. as programmers, we are not merely engineering drones, mechanically pushing out reams of boring, ugly code. We are also artisans. the act of programming involves as much artistry as it www.StickyMinds.com does technicality. http://StickyMinds.com http://StickyMinds.com http://www.stickyminds.com/quotables10-7a http://www.stickyminds.com/quotables10-7b http://www.StickyMinds.com/editorspick10-7 http://www.StickyMinds.com
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.