Software QA testing is so much more than plugging away at a UI or finding new ways to employ your suite of automated testing tools.  In a world where we work tirelessly, neglect ourselves, and go through the motions to get from point A to point B,  we trend toward two-dimensional thinking, mindless checklist completion, and risk de-valuing ourselves and the pivotal role we play in the Agile development process.  Recently, I’ve discovered it pays an ethical and motivational dividend to reflect on the positive value of software QA testing.

The following are three ways that becoming a software QA tester has changed me [for the better].

1. Visibility is more important than identifying problems

When I began testing, I believed my value centered on finding problems — and the more the better. 

In fact, I was so motivated to find problems, my confirmation bias would get me into trouble!  With time, though, I began to realize I was having a different impact than I intended.  

The real impact of my effort wasn’t in identifying or fixing bugs, but rather providing a record that enhanced visibility to the project manager and product owner.  This had the following effects:

• Low-performance areas were identified.
• Identification of low-performance areas gave rise to themes that could be compared/contrasted.
• Analysis gave way to evaluation and better decision-making.

Without realizing it, I began influencing the decision-making process at higher levels of management.  When this clicked for me it became clear that providing visibility into the inner workings of the product is far more valuable than logging an arbitrary number of bugs.  

2. Development outcomes become less important than empowering clients. 

Ostensibly, there’s nothing better than testing a simple JIRA ticket.  You know, an improvement ticket with development outcomes that resemble the following.

• Move this here.
• Re-label that there.
• Disable this feature for role X.

Oh, the simplicity!  

However, that simplicity can come at a cost if not wielded properly. 

“What happens when re-labeling a field causes it to come into conflict with a labeling scheme somewhere else in the application?”

“What if disabling this feature for role X inadvertently subverts a security hierarchy because of complex dependencies?”  

As a Padawan tester, I might have said “Eh, doesn’t matter.  I just validate tickets.”

However, a wise Jedi once said, “That leads to the Dark Side.”

Nowadays, I see situations like the above as an opportunity to ask questions.  It’s ultimately the client’s decision (and it should be) as to how to deal with said labeling schemes and security dependencies.  However, if I own the knowledge that we could be heading for a future headache, then I own that knowledge and have a responsibility to ask about it.  

Empowering clients to make seminal decisions about the product’s development is deeply satisfying and a great value-add.  

3. Improvement becomes more important than consistency

It’s been said that “If you find adventure dangerous, try routine — it’s lethal.”  While a bit hyperbolic in this context, there’s still applicability.  You see, we have to continually improve as software QA testers.  Otherwise, we’re not performing at our best.  

Every time we testers make a change to an existing automated test or dabble in a new way of writing an assertion, we introduce the possibility of failure and pain.  It’s true.  And at first, it feels pretty bad.  

However, it’s our failures and the pain they sometimes bring that teach us the most valuable and lasting lessons.  Without these moments of pause forced upon us, the proper improvement steps won’t take place, we’ll stop asking questions, and ultimately fall into a pattern of consistency.  

Consistency really is a semantically innocuous alternative for stagnant, right?

What are some ways software QA testing have changed you?