In the mid-90s I was introduced to the phrase “Compile it. Link it. Ship it. Debug it.”
Yeah, it’s sadly funny, but what’s that got to do with QA not being a speed bump?
Once we developed software, then we had waterfall, then agile, then test-driven development. Next? Who knows. Here’s a clue. We’ll still be developing software.
In a world of would be Sherlock Holmes’, we are in desperate need of more John Watson’s. And like the classic pair, the end product is much better when they are working in a tightly coupled fashion. And by that I mean both geographically and temporally. Let’s look at some common software development models of developer/tester interaction designed to fail.
Remote Test
There are some who believe that the phone/IM suffices as a mode of communication when developing complex software. Unfortunately, there is a proportional relationship between the distance between the developer and tester; and the scale of misunderstandings. “Frog protection” anyone? Nothing brings a developer back to reality from Nerdvana faster than someone standing in front of them waiting for them to explain exactly what it is that the software is supposed to be doing. Out of sight, out of mind.
Software First, Test Plan Later
This is especially interesting when QA has the responsibility of saying that the story associated with the feature is working. Let’s make it even more fun by saying that we can count story points when the developer says they’re done, but we won’t actually get QA sign-off until the next sprint. Technical debt-ville.
Unit Tests Mean We Can QA Later
Everyone who believes that they can proof read their own documents, stop reading now. The hallmark of a great tester is that the first thing that comes to mind when they look at your software is the last on yours. How can I break this. Developers struggle to get the “happy” path working. Where do most problems come up? The “sad” path. If people do get to write unit tests, and the code is structured to allow unit tests, it’s more likely than not that only the happy path will be tested. After all, it’s QA’s job to test what doesn’t work right?
Testers as Second Class Citizens
Holmes may be brilliant, but Watson is the proxy for the rest of humanity. You know, the ones who don’t keep heads in their refrigerator. The ones who we expect to, you know, pay money for the software. Not everyone reads Shakespeare in the original Klingon. Testers keep the “pizza under the door” crowd honest. Am I being a bit harsh on developers? Perhaps, just a wee bit.
Beta Test as Test
Throwing it over the wall taken to the extreme. Well, not quite the Google, “it’s not a product, it’s a beta” extreme, but GMail does pretty much set the goal post for that one. Guess what, when a potential customer gets hold of a beta, ninety percent of them will treat it as though it’s a complete product. Do you want your bank using your “beta as test” software? Would you use a beta compiler for your grandmother’s pacemaker? How about a drone? The close cousin to this is the weenie move of calling your software 0.9 for a decade and thinking that somehow insulates you from your commitment issues. Tossing your software out to the world without having the courage to “own it” is just lame. Doing so because you can’t be bothered to do the work is unprofessional. “Lost your company’s data? You can’t complain. It’s beta software afer all.”
It’s Time to Start Treating Testers Like the Partners We All Desperately Need
I’ve had the privilege to work with some very gifted individuals who time after time brought code, that I was sure was solid, to its metaphorical knees. They helped me to explain the complex in human terms. Treat them well and they will improve both the end product and the process. Remember, QA is not a speed bump, a nuisance to be endured. It is the whetstone that keeps the knife keen.
Charles Wilson's Blog 