By: David Pilkington, Software Developer
I’ve been a software developer all my adult life and then some – back to the days when we were called “computer programmers.” In those 35 years I’ve learned a few lessons, and one has definitely been that those who write the software should definitely not be the ones charged with vigorously testing it.
It’s not that we’re incapable of rigorous testing. We can follow a process of steps as well as the next person. Heck, processes of steps are what our livelihood is all about. It’s just that, well, we write software for computers to do those processes so we don’t have to.
You see, we like to make stuff, not break stuff. We spend our time thinking about how to make software do all the cool things it can do. We have the patience to sit and think of every conceivable way software could work; we don’t have the patience to sit and think of every conceivable way it could fail.
OK, yes, we do try to think of some ways it could fail. No software developer would ever assume that it’s going to work perfectly all the time. We don’t assume that the input provided by wise and careful users would ever be bad. One of the first lessons you’re taught in little programmer’s school is “garbage in – garbage out.” I wouldn’t want to work alongside a developer who never took exception handling into account. In fact, the best developers’ code are rife with “if this fails, do that.”
Coders tend to occupy our brain cells with details specific to the particular application we’re trying to write. Our perspective is very much down in the weeds. How can we get this to work? What data structures do we need to keep track of everything? What steps are involved to move all those little bits from point A to point B?
Testers, on the other hand, tend to have a more global perspective. Their brain cells are less occupied with how it works, and more occupied with whether it does work, so they can often see the traps we miss. A tester will not only enter garbage data to see if application A will break, but will enter some garbage data way over in totally different application B to see if application A will break. Even with good data, certain unpredictable situations can arrive, and a good tester will try to think of those as well.
A tester is never done testing. An age-old axiom in software development is, “if you make it idiot proof, someone will just come along and invent a better idiot.” Testers are willing to take the time to go to that place of thinking like an idiot (and I mean that only in the most positive terms), whereas developers would rather not. If we spent as much time testing as testers do, we’d never get any new code written.
As our culture becomes more and more dependent on devices and software, think about some other industries where you definitely want testers on that wall standing watch. Would you want to get into an airplane that hadn’t been thoroughly checked out and put through every conceivable scenario? Would you ever want to eat in a restaurant that the health department had never visited? Would you want to climb into a car that had never been crash tested? Well, I wouldn’t. This coder, for one, is thankful for those who have the patience to run through 1001 tests on the off chance that 1000 tests won’t find that one bug lurking in the shadows.