Friday, October 9, 2015

What is MetaAutomation? A Brief Metaphorical View

What is MetaAutomation all about?

MetaAutomation opens a conceptual door, and through that door, it shows how to create powerful quality and communications value for a software team, faster and better, more complete, robust, reliable and satisfying.

That door is currently being held closed by several factors at least:

Conventional wisdom and practice maintains that “automated testing” is just like “manual testing,” in fact, according to this meme the words “automated” and “manual” can be dropped from the software quality profession. There are good intentions here… but, it comes with business risk, and it’s pulling the door closed.

There are tools vendors and open-source projects which support “automating” tests which are originally designed as manual tests, i.e., for a person to execute to observe quality information on a software product under development. There are good intentions here too, but it’s also risky, and it’s pulling the door closed.

The “Context-Driven School” view of testing discourages software quality professionals from seeing general approaches to software quality. This pulls the door closed.

Keyword-driven testing is represented by many tools and techniques, BDD, Cucumber and Gherkin for example, but requires linear runtime interpretation of an invented language (keywords or phrases) to run. This limits both the precision and the accuracy of the artifacts of a check run, which in turn limits value of the automated verifications for communication and for quality measurement. The concept is very popular these days – it does have value! – but it still looks a lot like automating manual tests, with all the risks and limitations that go along with that, and the artifacts aren’t much better. This movement, too, pulls the door closed.

Open the door! Automated verifications is in many ways a distinct discipline with unique powers, relative to other software quality patterns and practices. For repeatable regression checks, for performance data, for managing business risk and shipping software faster and with better quality, for quality communications around all team roles and across distributed teams, there’s huge value on the other side of that door.

That’s what MetaAutomation is all about.
Please see here
for a very brief technical overview.
 (edited 10.12.2015)


  1. I posted this morning, then updated it just now with more things that are "closing the door" to a new level of productivity in software quality from automated verifications.

  2. Just watched your virtual interview at Starwest....Now, OK. This does sound like an outside of the box thinking approach. An early adopter would want to try this idea out, without the huge cost of formulating accurately the concepts and then turning those into an implementation and refining itteratively until they have something useable or promising.
    I could see why keyword driven testing using an existing language and extending it to support the testing domain makes sense. Especially if you do so with the intent of not automating something that is manually testable already. But you are advocating something brand new I gather.
    I am however worried that people might think that this is system integration or continuous integration, but its orthogonal , right?

    1. I don't think it's orthogonal to system or continuous integration, I think it's a prerequisite (at least, for complex systems or software that really matters to people) to do system or continuous integration effectively while managing risk. MetaAutomation is about measuring quality and regressing correct behavior faster, more accurately and precisely, and doing effective communication about product quality across the team.

      ... but, too much to write here. See http://metaautomation on paradigm shifts.

    2. On "keyword-driven testing," MetaAutomation is not that, it's better because the check is self-documenting in both business-facing domain language and technology-facing language at the same time. MetaAutomation minimizes the need of the QA role to interpret what's going on, and maximizes transparency and trust.


Note: Only a member of this blog may post a comment.