No respect for QA … how to fix that!

Three years ago, I overhead this in the hallway at a STARWEST conference:

“I want to know why the QA team wasn’t represented in the go-no-go meeting this morning!”

I was disappointed, but not surprised. The QA job is hard because it is so open-ended, but it is very important for software that matters. The role needs more respect than it gets these days.

So, how can QA get respect? By earning it!

First, they can show transparency into exactly how the SUT is behaving, including performance. All they need to do is make their automation code self-documenting in a way that preserves context and delivers it in a way that all roles can access (and not be overwhelmed by data). The best way to see this work is to load, run, and modify open-source Sample 1 here http://www.metaautomation.net/metaautomation-samples#sample1

Second, they can make automation faster and more efficient, so it can be used to gate check-ins as well as code promotions for DevOps. See the two groups of patterns here http://www.metaautomation.net/the-pattern-language that are closer to the technology interface of the quality automation problem space.

Third, they can shield the team from false positives with the Smart Retry and Extension Check patterns.

Fourth, with the two patterns closest to the business here http://www.metaautomation.net/the-pattern-language, QA can make all this quality data available to the team at correct priority. Check failures get handled quickly because notifications are sent to the people who can fix it, rather than everybody on the team, and with enough data available (including reproduced failures, if that’s needed) to quickly act on the problem even if it can’t be reproduced.

QA can be the nexus of the larger software team, enabling better communication across roles and geographies through highly detailed and trustworthy data on the system, and enabling the team to ship software faster and with better quality.

That’s how QA gets respect.

No Comments

Add a Comment

Sign up here for emails with bites of wisdom on quality automation and MetaAutomation

Recent Blog Posts

  • The differences: Manual Test vs. quality automation

    In my last post I describe out the two kinds of automation that fit in the quality automation space.

    People who do quality automation (at least, the part of quality automation that drives and … more

  • The two halves of quality automation

    Quality automation is the domain (or problem space) of driving the SUT, measuring and recording data on SUT behavior and communicating that data to the business. I also use “quality automation” to … more

  • Fixing the false negative problem

    False negatives happen when these three things happen in order:

    Operations (ops) promotes the software to the next level, or ships it to end-users

    Someone (or, some automated process) discovers a … more

  • Fixing the false positive problem

    With all the quality automation that is your responsibility, a run of a check failed. It is your job to check it out.

    After 30 minutes or so of investigation, you find that the failure happened … more