olly - Fotolia
Why I moved from programming to a software testing role
Testers rejoice when they find flaws, even as project managers gnash their teeth. Matt Heusser explains how, in QA, he learned to stop worrying about deadlines and love the delay.
In a previous role, I remember a conversation I had with a colleague, in which I turned to him and said, "That's the problem with you programmers." He turned back to me and said, "Wait, Matt, you're a programmer too. Do you self-identify as a tester?"
That day, my slow transition to a software testing role was complete. I responded, "Yes." And I haven't looked back.
Let's dig into the appeals of QA and how a software testing role differs philosophically from programming.
Embrace the role of tester
When I worked on the testing staff at Socialtext, a producer of enterprise social software, I got to be part of a rewarding journey -- and I was good at testing. My contributions came not as CEO, not as the VP of engineering and not as a programmer -- I was a tester, and that was fine by me.
Eventually, a former QA lead returned to the team just as I applied for the position. The company offered me a programmer position instead -- and I turned it down. I told them, "I've got a programming position now. I want to be a tester."
The nature of testing work appealed to me. With programming, you can be part and parcel to a great deal of value, but only when the pieces come together at the end. Modern app dev approaches collapse this feedback cycle, but that turns the programming work into a bit of an assembly line.
A software testing role requires more ingenuity, as the work is akin to solving a series of puzzles. QA offers more opportunities to add value to software and to get the proverbial dopamine injection that comes with solving a problem.
Also, as I tell people at parties and new acquaintances, testing is a job where you get paid to tell people they are wrong and they thank you for it. Organizations pay testers to find problems, and this requires a willingness to act contrary to the developer mindset.
For example, testers work on UI issues. If I can't figure out a UI to accomplish a given task with the software, I can report that issue back up the chain to the developers. When that happens, the record scratches and the user experience experts come in to address the issue. After they figure out how to make it work, they thank me. Who else gets paid for being confused at work?
New UIs intimidate many technical staff members, who often put extra effort in to try to understand them -- and to get inside the developers' heads. Many users won't put in that much effort when they interact with the software. The tester's job is not to try as hard as possible; instead, it is to match the actions of a user. And if I can't figure it out, someone needs to address that problem.
Also, in testing, organizations reward me for contrarian or maverick opinions -- or even for being a bit of a jerk. A development manager might insist that a new feature must absolutely ship this morning. That can intimidate IT staff, but not a good tester, who might respond with more skepticism than acceptance. Testers who think in this contrarian way can more efficiently go about their work than team members who blindly accept a deadline at the expense of quality.
The deeper allure of testing
Of all the appeals of a software testing role, there is one that I have neither read nor heard from others -- and I have not even written myself. It is simply this: Testers have the least incentive to lie.
When working to a deadline, project managers typically believe they will hit that deadline, even in spite of strong evidence to the contrary. During my tenure as a project manager, I often heard remarks like, "never let reality get in the way of your project plan," or "the steering committee has added features to the scope. The deadline has not changed -- figure it out."
It's easy to lie when confronted by a deadline. When that date comes, the team must finish requirements, design or coding, which means they might rush to the finish line. Programmers can slap together a UI that has no real functionality, then call any problem -- no matter how massive -- a bug found in test. QA is where the rubber really hits the road. When a tester says, "It is not done, we can't log in," the project manager must take notice.
I remember one project that faced incredible schedule pressure during which I found defect after defect. My colleagues were clearly upset, perhaps even angry with me. I asked if I should simply stop reporting bugs, to which a coworker replied, "No, it's the truth, and we need to hear it. We might not like it, but you are being helpful. Please keep it up."
But testers aren't perfect. Another colleague tells a story in which testers were sent to the movies to lower the reported bug count so that software could ship. While those testers were complicit, testing generally has the least incentive for deception.
With the move to Agile, DevOps and continuous delivery, teams are making smaller changes, making the delivery cycle more predictable. The incentive to deceive others -- and yourself -- about a project's readiness for market still exists, but it is significantly lower than it once was, especially in testing.
Finally, the software testing role can be intellectually satisfying and put you in contact with brilliant minds. Testers are a vital part of the overall company story.
At Socialtext, I worked with many impressive industry professionals, including the creator of spreadsheets, Dan Bricklin. I had the opportunity to report bugs to him, give him feedback, and even -- yes -- use his spreadsheet. I even created a low-tech testing dashboard with it.
