Key Takeaways
- Developers are too close to their own work to self-test effectively: Just as artists struggle to objectively evaluate their own creations, software developers lack the detachment needed to spot how users will misuse or misunderstand the interfaces they build.
- A dedicated QC tester catches what developers cannot: Bringing in someone unfamiliar with the code and business logic surfaces bugs, broken sequences, and missing validations before they reach the client, protecting both the product and the relationship.
- Quality control is not optional in professional software development: Every production process has a quality checkpoint, and custom software is no different. Building a testing role into the team structure reduces bugs in deployment and gives clients and users greater confidence in the finished product.
My first semester of art school was an eye-opener. Not only did I have a lot to learn, but it turned out professional-level art was a lot of work. Harder yet was the process known as Critique, which lay at the heart of every project and assignment. We students would line up our completed works, often the product of hours of laborious brushwork, painful false starts and do-overs, and finally, if all went well and we were able to make our vision real, the true elation that comes from making something unique and beautiful with one’s own hands.
Nervously, I would await my chance to hear what my peers and teachers liked and didn’t like about my work. I learned how I had or had not communicated my ideas. I marveled at the assumptions people made in their own minds that were sometimes far from what I had meant to get across. And I learned to suck it up, turn disappointment to resolve, and welcome the gift of honesty I had been given.
Any software developer might read the above and find parallels. Who hasn’t experienced the elation of solving a particularly difficult coding problem, or creating that exciting new user interface that we just know our users will relate to? And who hasn’t also experienced the frustration that goes with seeing our users trip over minor bugs as if they were giant potholes, rendering all of our hard work, in the client’s eyes, useless.
I hate bugs. Bugs make good software look bad. Bugs make confident users timid and reticent. They can slow down the deployment of systems, and erode the relationship between the developer and the client. Despite all attempts at expectation-setting, convincing a client that bugs are just part of custom software development, and that they can and will be dealt with as they crop up, the expectation is that a good developer does not have bugs in their code. Not reasonable, but there it is.
Many developers like myself, who have been able to expand the size of their team, go for more developers as their first hire, or perhaps a project manager. Me, I went with a QC tester. I have never regretted that decision, and I have always had one on staff from that time. Every process with a finished product has quality control somewhere in the production chain, and software should not be any different. Developers are not any better at self-critique than artists. We are too close to the work. We know how it’s supposed to be used, so we don’t see how it can be misused. We fail to imagine the creativity of the user in breaking our product, just as the artist fails to imagine how others might see his work.
By having someone else test what I build, I get a glimpse into how an uninformed person with different expectations might mess up everything. I make sure my tester doesn’t know much – or anything at all – about coding, and I explain the business rules superficially when showing them what to focus on. Then I cut them loose, and am grateful to get the opportunity to fix bugs before they reach the user.
The system isn’t perfect. Over time, a QC tester will learn too much, and start to get too familiar with my work. A good one figures out how to make the most common mistakes – like changing the sequence in which steps are followed, or not filling in fields. They also learn what my most common mistakes are, and how to recognize them, which is also extremely valuable.
The upshot of having someone like this in place is that bugs are less likely to raise their ugly heads at the worst possible moment. I’m not saying it won’t still happen, it does. But there are fewer of them, and everyone – developer, client, user – can rest a little easier knowing someone is there critiquing the work and keeping its creator honest. This is a gift that cannot be underestimated.
