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

  • The end of test cases

    Test cases have served teams well as a tool to enable measures of quality over time, over many runs of those test cases, so the team knows (or should) roughly whether quality is getting better, worse, … more

  • Example: Fixing the Shopping Cart False Positive

    Last month I posted here about the false positive problem.

    Here is a specific example that I learned from a friend at Microsoft, where the false positive caused a defect escape:

    Imagine a shopping … more