Testers who question their own technical ability have more to contribute to technical tasks than they realize because such tasks often don’t require as much technical ability as they think. Though strong technical ability can produce slick solutions; oftentimes, those solutions can be overkill, taking too much time to create and proving too complex to maintain. A sledgehammer isn’t needed to knock a nail into drywall, and testers don’t need to have developer-like technical ability in order to post big wins for the software-building team.
One of the most valuable things a tester can do is reduce the amount of time it takes to accomplish a task that doesn’t require human sapience. For instance, build installs often require multiple steps that are generally the same every time: Figure out which build is needed (which can be daunting in a busy configuration management environment), discover where the build lives on the network, learn where and how the build needs be installed, copy it to the testing environment, unzip, modify configs, install, reboot the server, etc. Automation of the material pieces of this process can save multiple hours every week. Do you have to be a code ninja to automate something like build installs? Do you have to wait until you get all your technical ducks in a row as a tester to tackle a task like this? A less-technical tester can create a less-technical solution to a problem. What matters more than design and spiffiness is that it works.
Having joined a few teams that handled build installs completely manually, repeating the same steps time after time, my guess is that many less-technical testers don’t realize how easy it is to decrease overhead and improve efficiency with some basic knowledge that anyone could acquire. We look at what the more technical-minded among us accomplish and discount our own abilities, thinking we could never do that. But the perfectionist in us fibs when it says what we’re capable of isn’t good enough and that we should stick to doing what we know until we learn to program, or until we become database wizards, or until we get some certification. Testers need to gauge their successes based on whether or not what they implement works, not what a more technical person could have designed.
Some time ago, I joined a team in which the testers had not automated any of the build install process. An experienced tester would spend about twenty-five minutes going through the whole process manually each time he needed to get a new build up and running, which could be multiple times per day. Upon working with the product, I noticed that much of the actual install was accomplished with PowerShell, a task automation framework developed by Microsoft. I knew nothing about PowerShell at the time, but some cursory research revealed the framework’s powerful scripting abilities. I tucked this information away in my brain while I focused on getting a win in fast—automating as much as I could of the build installs using simple batch files and scheduled tasks. It was crude and unsophisticated but did most of what I wanted it to do. Most importantly, the automation immediately impacted the test team’s timeline, and my boss was happy. Later, with other important tasks out of the way and with all my newly found time, I learned about PowerShell and used it to smarten up the build install process and overcome the limitations of batch scripting. If I’d waited to find enough time to learn PowerShell to begin with, automating the build process would have taken much longer.