More productivity for everybody on the software team, not just the QA role

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.

Automation delivering quality automation to people of the software business

Deprecating “test automation” in favor of the much more appropriate “quality automation” has many advantages. This post talks about other problems with “test automation.”

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