Find Bugs Once and the Joy of Bug Fixing
Every programmer struggles with testing early in their career. My feedback leaving my first internship was: Barry, you do not express an interest in testing. I was allergic to it. In my defense, I already felt it was a pretty widely reviled task. As a youngster new to professional programming I was just telling the truth.
During my seven long years in corporate IT I learned that I was not so much allergic to testing as I was allergic to manual testing. Scratch that. Early in my career I had to manual test and didn’t realize that automated testing was something to be embraced. By the end of my time in corporate IT I was the person shouting from the mountain top, “Why are we not writing more automated tests?!”
Where does this evolution come from? Experience. The bit starts flipping the first time you see a bug you fixed in the past reappear for a second time. Then you become 80% confident that bug fixes should arrive with tests. You become 90% confident when you see a bug fix someone else committed appear a second time because the fix went through with no tests. You become a rabid 100% adherent when you see a bug fix you reviewed appear a second time because no tests were written even though you insisted there should be tests. It might take years to get to the 100% state, but all good pragmatic practitioners of programming get there eventually.
My advice to a young programmer is to embrace the experience of battle-tested peers. Our craft is relatively young, but remember people have still been doing it a long time. I recently read The Pragmatic Programmer. As a professional programmer for nearly 15 years, it read a bit like Aristotle; almost entirely obvious. It’s not obvious when you first start programming, though! Read this book.
Finally we’d like to reveal the single most important concept in testing. It is an obvious one, and virtually every textbook says to do it this way. But for some reason most projects do not. If a bug slips through the net of existing tests, you need to add a new test to trap it next time.
Once a human tester finds a bug, it should be the last time a human tester finds that bug. The automated tests should be modified to check for that particular bug from then on, every time, with no exceptions, no matter how trivial, and no matter how much the developer complains and says, “Oh, that will never happen again.”
Because it will happen again. And we just don’t have the time to go chasing after bugs that the automated tests could have found for us. We have to spend our time writing new code – and new bugs.
Finding joy
Step back and consider all the possible work you do. The overtly glamorous work of new products and new features results in a shower of praise from customers and teammates alike. If you really consider the results of that work, really think about it, you understand that these new features and products heap only pain on your team. New bugs, new maintenance, new risks, new support requests. Important things happen with new things: praise, morale, customer acquisition, and the bottom line all grow. Yet even with very well designed features the net result to the team is pain.
From this perspective bug fixing is a beautiful thing. It is the only place where you can have a positive impact on the entire team. A bug fix, with tests mind you, will: reduce the noise disrupting future support programmers, please customers now and into the future, reduce the cost of maintenance to the product, and reduce load on the customer support team. While you’re fixing bugs, everyone else is adding bugs to the product. You are removing pain and thereby making the life of everyone else on the team every so slightly better. You are protecting most of the team from even having to think about all of this pain, if only for a short time.
Keep this in mind the next time you are writing a test for a trivial bug fix. Embrace the opportunity, the beauty, of the situation.