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 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

  • A gift to company executives

    For automation for quality (a superset of/fix for what is often called “test automation”) MetaAutomation provides trustworthy detail and transparency on what the SUT is doing and how fast to all … more

  • Ruby has lost its sparkle

    Ruby is very popular as an automation tool.

    Ruby’s creator, Yukihiro Matsumoto, had what seemed like great ideas: programmer productivity and fun, and that (to quote Wikipedia, quoting Matsumoto)

    “ … more

  • Make your automation sit up and pay attention

    One of the problems with the phrase “test automation” is that it implies that what a manual tester can do can also be automated, and even that it is automated when someone automates a manual test … more

  • The limits of AI testing

    Artificial intelligence (AI, or more accurately called machine learning) is all over public discussions about software testing. It seems like the next big thing! Many imply that it will take over the … more