I Go Back: Valuable Lessons in Quality Engineering


Terry Wiegmann noticed that in certain conversations with clients and team members, a single phrase can take her back to some “aha” moments when she grasped fundamental quality concepts. She shares some of these major learning moments throughout her career and how they can apply to 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?

User Comments

1 comment
Tim Thompson's picture

My go back moment is when we did get the rare chance to discuss a new feature before programming started. One would think this is a given, but with agile meaning nothing more than deliver as fast as possible coding starts before any reasonable business analysis completed. In this case we had a chance to discuss first and I was able to poke quite a few holes into what several on the team thought was the best implementation. My boss still talks about how great it is that I can poke holes into things. Maybe this is why I was removed from the project, my objections sent things back to the drawing board to get them right the first time. Now the project releases with more features, but gets about a dozen immediate patch updates just days after release. Also didn't help that the process that we put in place was ditched after the reassignments took place.

When my boss now tells me how great I am in poking holes into things I tell him how great it was when people listened to what I said.

August 25, 2016 - 2:39pm

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.