I Go Back: Valuable Lessons in Quality Engineering

In the song "I Go Back," singer-songwriter Kenny Chesney describes how certain songs take him instantly back to various moments in his life, and when he hears them, he can’t help but sing along.

Lately, I’ve been noticing how in certain conversations with clients and team members, a single phrase can take me back to some “aha” moments when I grokked fundamental quality concepts.

In the early days of my software quality engineering career at a commercial software product company, I was sitting next to my mentor, a development manager, in an all-hands team meeting when a rather disheveled developer burst in. He proclaimed that he had worked all night to track down “that bug” and had fixed it, so the feature was now working.

The room broke into applause, with some people even standing up. Given that this was a crucial bug that was holding up an important release of our flagship product, it sounded like good news to me. I was surprised that my mentor showed no emotion and didn’t share in the celebration. I looked at her, puzzled, and she shrugged and said to me, “He put it there in the first place.”

Over time, I learned about defect density, defect removal rates, and the cost of quality. I also learned that quality assurance is about preventing problems in the first place, as opposed to testing to find defects and then testing the fixes.

Now, when people talk about testing as a phase and collecting metrics such as the number of tests passed or failed or the number of defects detected as measures of quality, I go back to that day and hear my mentor saying, “Let’s talk about how they got there in the first place.”

Here’s another “aha” moment I go back to: I remember the year I moved from being in the IT department at a retail company to being a trainer and technical writer at a commercial software producer. I was thrilled! This company invested in professional development, and I got to go to my first week-long software conference.

I attended a session by Gloria Gery, author of Electronic Performance Support Systems, and when she asked the audience, “Who here is in training and documentation?” I proudly raised my hand high. She admonished us to “get another job.” What? She then followed up that splash of cold water with words I have never forgotten: “Documentation and training are compensation for poor UI design.”

She went on to explain that we ought to understand what the user is attempting to do and help them do it, rather than distracting them with gray buttons they cannot use or enabling them to make mistakes they must figure out how to recover from. As I got into business analysis, I learned more about user task analysis, and as I got more into QA, I learned about UI design standards and usability.

Now, when I see a list of cryptic error messages that don’t help the user recover or grayed-out buttons on a UI, I can’t help but sing along with Gloria Gery: “Documentation and training are compensation for poor UI design.”

When I hear the phrase “policies and procedures,” as though those two things are interchangeable or approximately equivalent, I go back to an article in Crosstalk: The Journal of Defense Software Engineering. I’d been a subscriber of Crosstalk for years, and while some articles were more specific to the military than I could use, one in particular caught my attention: “A Beginner’s Look at Process Improvement Documentation” by Ronald A. Starbuck. Published in 2004, I still use the structure Ron proposes for an operational framework consisting of policies, standards, processes, procedures, tools, and training.

Kenny Chesney sings about going back to driving his first love out to the levy in a two-toned, short-bed Chevy and the smell of Sunday chicken after church. There are many quality moments that make me go back; what are yours?