The QA role reports to the rest of the software team on product quality. Conventionally, “test automation” just helps them get information faster; although, whether that information is trustworthy or not depends on how it is implemented and depends on whether the rest of the team trusts the QA role. QA must still report (or, generate reports) for the rest of the team to look at.
“test automation” addresses, by its name, the test or QA role alone. It helps QA be more productive, but not the rest of the software team necessarily.
When the team is ready to consider the whole team, and how to use automation to help the whole team manage SUT quality, the team is ready for quality automation!
Quality automation addresses the whole problem space of what automation can to do measure, record, report and communicate quality, from the technical side of driving the SUT with quality to the business side of informing people on the team and the deployment processes for continuous integration and deployment (CI and CD).
Quality automation is about applying automation to make everybody on the team (everybody who cares at all about SUT quality, anyway) more productive and informed. It enables much better management of quality risk, because automation helps communicate around the team, so quality is well known to everybody.
This depends on MetaAutomation specifically, or something like it; the pattern language MetaAutomation addresses the quality automation problem space and shows how to get complete and highly trustworthy information on SUT behavior, and how to communicate it as well around the team in a way that is appropriate to all roles: dev, qa, test, leads, managers, and people doing SOX compliance to measure value and risk of software under development.
The manual testing role is happier and more productive because (other than for issues that automation can’t help) there is no longer any need for testers to run through boring “test cases;” instead, they can focus on exploratory testing and filling in behavioral gaps in their testing.
Devs can be much more productive because they can run automation themselves, it is very fast, very informative and highly trustworthy in details from the SUT. They can do gated check-ins of code, so no dev breaks any other dev with code changes.
Leads and managers can be happier and more productive because they have very high visibility, complete, detailed, and trustworthy, into what the SUT is doing and what the devs and QA role are working on.
Accountants doing SOX compliance (which includes evaluating software under development: how good is the quality? What are the quality trends?) can see the information they need in unprecedented detail and trustworthiness.
Deprecating “test automation” in favor of the much more appropriate “quality automation” has many advantages. This post talks about other problems with “test automation.”