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 describe code that does this.

The bounds of quality automation are the technology-facing side and the business-facing side. The technology-facing side is automation driving and measuring the SUT. The business-facing side is delivering information to the business: anybody on the larger software team, and automated processes like the DevOps automation that promotes a build of the SUT.

The MetaAutomation pattern map shows the patterns, some of their relationships, and the technology-facing and business-facing contexts. The pattern map fills the quality automation problem space with patterns that are an early iteration of the best solution to quality automation, emphasizing shipping software faster at higher quality with better communication and happier teams. Long-running tests, other security tests, and many things that are often done with automation are important as well; they’re not represented here currently but are potential future additions to the map.

The traditional “test automation” corresponds roughly to the technology-facing half of quality automation. This isn’t at all like industrial automation or cockpit automation for pilots (discussed in this future post <link>) because the value is in behavior and quality measurements, not any direct result of driving the SUT to do stuff.

The business-facing half of quality automation is more like cockpit automation; the value is in automated handling of quality information to help the business make efficient decisions and have efficient controls related to SUT quality.

The two halves of quality automation are linked because the cockpit-automation-like automation that presents quality information to the business depends on detailed and trustworthy information on how the SUT behaves; something that “test automation” (or even BDD/Gherkin) can’t do (described here for example).

Quality automation is about understanding what the QA role is really about and how to deliver. This understanding is key to shipping higher-quality software faster; even given the coming rise of artificial intelligence and machine learning (AI/ML), AI can never match MetaAutomation for speed and reliability, and it still needs all the SUT data that MetaAutomation shows how to record.

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