Testing is Rocket Science Not Brain Surgery

How do we go from debugging a “parameter not found” error to updating our test software by applying a patch? Well, sometimes you have to go back to the basics. Sometimes you have to ask the “stupid” questions; of which there are none in my opinion, to check your ego back in place and look at things from the ground up. If you’ve ever worked on the help desk handling day-to-day user issues and complaints the script is a familiar one. “Hello, yes, my printer won’t print”, are the drivers installed? “Yes, the drivers are installed; I used the CD that came with the printer.” Good, is Windows showing any errors? “No, the job goes to the printer status box.” As you start going through the script to resolve the problem the first question and seemingly insulting one is is the printer powered on? See this user appears to be fairly savvy, he/she has demonstrated some knowledge about how to troubleshoot. What this user has taken for granted is that the lightning strike last night blew the outlet out for the printer. What you’ve taken for granted is to start with the basics. The simplest most fundamental questions need to be asked and answered just as a best practice. It can save you a lot of head pounding and teeth gnashing over issues that end up with you saying “I should have checked that first, how (beep beep beep) of me!”

The other benefit of not taking things for granted is that you will be forced to increase your understanding of the way things work, and practice forming logical workflows in your mind. To get back to our issue it’s one that in the past wasn’t likely to occur because the typical engagement requires me to build/deploy hardware assets, define the network topology, install and configure the software, and do a dry-run and assess capacity of the PATI(performance and automation testing infrastructure). But as companies turn to outsourcing their internal IT operations and delineate infrastructure and deployment tasks between groups more cooks end up in the kitchen. Now if I’m in a kitchen full of chefs and I have to hand off a piece of the recipe for someone else to execute I fully expect that person to execute accurately. If the recipe calls for basil, I’m not going to check to see if its parsley. That attitude will serve as the root cause of my problem later. Once again, take nothing for granted as a matter of policy things should be verified even when experienced and capable people or tools are involved. So test execution fires off and of the four load injectors in place only one is throwing an error. It is only because of this single instance that I immediately move in the direction of trying to verify what is different on this machine, and after checking a lot of test specific items and not finding any differences I force myself to start examining everything about the machine from a hardware perspective. Maybe its some bad blocks on the disk, maybe file corruption, maybe network performance, maybe it’s the OS, maybe its the software mix on that box, or maybe its EUREKA! The testing software itself, maybe my fellow chef failed to install the latest updates and service packs.

What that has to do with a “parameter not found” issue? I have no idea and don’t want to know; it seems like a silly error and shakes my faith in the product so I haven’t delved into it. What I did come away from the situation with was an appreciation of starting from the bottom up with the simple questions first. Go back to the basics of troubleshooting and work your way up to the specific circumstances. Take a more methodical approach instead of so much free-form thinking, lean on the fundamentals and ask the “stupid” questions. Sometimes they reveal the best answers.