July 23, 2018
It was a hot summer day in a windowless L.A. basement office when my career in software quality begain. Without averting his gaze from the monstrous CRT monitor he was facing, my boss sent me an AOL instant message with a web link and yelled across the cubeless room: “Hey intern, test this.”
Frankly, I was just happy to hear him say something other than “Hey intern, I'm hungry." or Hey intern, I feel like some coffee.”, so I didn’t think too much about what I was getting into at that point. Since part of my grade required writing a paper about my experience, I decided this whole testing/quality thing would make a good topic. I quickly found out that even coming up with a title would prove more difficult than I'd imagined. Apparently, no one in software quality could agree on what to call their field of expertise. Little did I know that 18 years later, our industry would still be coming up with new names to describe what we do.
Quality Assurance (QA*), Quality Control (QC), Software Quality Assurance (SQA), Testing, Debugging, Verification, Validation, and now Quality Engineering. Did I forget any?
It seems that as long as computer programs have been around, we’ve been attempting to give a universal name to the work we do, which is making sure a program does what it is supposed to do (and preferably doesn't blow up and kill someone in the process).
[Cranking Out Widgets] != [Creating Software]
Something I pointed out in a post on LinkedIn recently is that we still share so many terms with manufacturing that I've gotten halfway through a "QA" or "Testing" job description before realizing it has nothing to do with software. Even though the two fields are about as far apart as can be, they have used many of the same terms for as long as anyone I know can remember. On the surface at least, it makes some sense how we got to this point. Deming, Crosby, and Juran taught us how to crank out cars, radios, plastics, and widgets galore, all within acceptable tolerances and with minimal defects. When the time came to start formalizing how we ensure quality for software then, I think it was a natural progression to start with those same concepts.
Formal Like a Factory
By the time I aquainted myself with my first real job in the software quality world, it was still heavily influenced by ideas borrowed from manufacturing, and the field was ruled by the idea that “formal” testing was the key to quality. This meant writing detailed test cases and then executing them.
It bored the living dickens out of most of us. The lucky ones at least got to automate those "manual" test cases, so they could babysit their fragile scripts that ran against old code and found very little in the way of defects.
All About the Contexts
Sometime around the late 80’s a few academics and practitioners started forging their own path and questioning the old-guard ideas. I somehow managed to fall in with those “outlaws” who eventually called themselves the Context-Driven Testing Community. Luminaries like Cem Kaner, James Bach, Scott Barber, Michael Bolton, Karen Johnson, Mike Kelly , and many others had a profound influence on me and on the way software quality and testing is viewed today. They introduced new concepts like Exploratory Testing, Heuristic Oracles, and better ways to measure and manage testing. As James Bach is fond of saying, "if you find testing to be boring, you're doing it wrong."
YOU get to code, YOU get to code, EVERYBODY gets to code!
In the past ten years or so, I have watched our field rapidly evolve. Most recently, the move of agile to the mainstream has brought with it another paradigm for what quality means. The tester or quality professional has moved 180 degrees from “Independent Inspector” to “Embedded Team Member”. This has been a profound shift and has left many of us wondering what we need to do to stay relevant. Some companies have eliminated the tester role completely, preferring to call everyone a developer. In those organizations, some developers write code to build the application, while others (often converted testers) write code that tests the application. This is a great strategy to implement when you're building software that won't be used by humans.
On to Quality Engineering
In looking at our own practice at Moser, we wanted to acknowledge the shift to agile practices among many of our clients, while also maintaining our adherence to context-driven principles and sapient testing. We saw that the core ideas of QE fit this bill better than any other paradigm, so under the heading of our Business Services practice, we changed our discipline name from Software Testing to Quality Engineering. I think it addresses the shortcomings of the manufacturing metaphor, while also embedding quality into the entire software development lifecycle, as opposed to focusing just on the testing aspect, or relegating testers to specialize in test automation and nothing else.
Our vision for QE means understanding each part of the process of creating software and then influencing it to make it better. As Quality Engineers, we are highly skilled at testing, but also at grooming user stories and traditional requirements for testability. We can develop automated testing frameworks for different technologies, help developers write better unit tests, and integrate our solutions for quality into Continuous Integration and Continuous Deployment systems.
In short, we do true Quality Assurance by helping to engineer quality into the product from day one. I am excited about this shift and I’ve enjoyed the many conversations I’ve had about it. If you’d like to geek out some more about QE, hit me up on LinkedIn!