“Quality automation” is a new term I introduced that I use to replace “test automation.” I did not do this to annoy people or drive a claim into the fertile ground of semantics! I did it for some very good reasons to support doing software quality better with automation:
Here is an excerpt of my definition for “quality automation” from my book:
Quality automation is automation to support functional and performance quality as part of the software development process. The scope of quality automation includes:
- driving the SUT for quality measurements
- making those measurements
- recording the procedure and measurements
- improving business value of the quality data
- making both directed (i.e., push) and queryable (i.e., pull) communications of that data to the software business
Notice that quality automation is about the whole software team, including test, QA, dev, PM, PO, everybody up to and including the C-suite and the accountants who do SOX compliance (or should…). By contrast, “test automation” is just about what the test and/or QA role can produce, and anything for the whole business must be addressed separately.
Quality automation includes a focus on the whole business, including using automation to facilitate efficient and actionable communication on what the SUT is doing when driven by automation.
By linguistic relativity (see on Wikipedia here and please note that I favor the “weak” version), “test automation” is about automating “test,” i.e., what a manual tester can do. But the business values that come from driving the SUT (the System Under Test) with automation for quality are very different from what a human can deliver. This is important to recognize, and we must understand it so we can have our automation for quality, a subset of what I call “quality automation,” deliver what it does best rather than be limited by what the manual testers can do and the misunderstanding that this can be automated. Please see my blog post here for more information on this.
Also, even though the ancient meme “test is all about finding bugs, and if you’re not finding bugs that get fixed in the SUT, you’re wasting time and money”* is easily disproven, it’s still influential to some people’s thinking. This creates another reason to avoid the word “test” when we speak of what automation can do for the team’s quality management.
*Glenford Myers, “The Art of Software Testing,” 1979. I write about this extensively in my book.