This is a brief post to describe how MetaAutomation solves
existing and well-known problems in automation for software quality. Below are
two examples.
There’s an interview of Dorothy Graham published April 10th:
In the interview, Graham talks about her extensive
experience with testing in general and automation in particular.
Example 1:
The interviewer (Josiah Renaudin) asks her about the
differences between manual and automated testing, Graham tells a story about a
hypothetical test failure:
“Oh! Something failed. Test thirty seven failed. Okay,
what was test thirty seven doing? You have no idea what's going on and you have
to build that context before you can start looking at it and seeing whether it
actually is a bug or isn't…. This is something which a lot of people don't take
into account when they're thinking about automation, is that failure analysis
can take a lot longer with automated testing than with manual testing.”
This is a very important problem, and MetaAutomation has a
very complete solution to the problem. If you follow the Atomic Check pattern,
you have atomic checks that are self-documenting with compact, structured
artifacts. So, the number “thirty seven” doesn’t matter anymore, because the
checks are atomic, and the question “what was it doing? What was the error” is
answered in great detail in the compact, detailed, presentation-free artifact
of the check run.
Example 2:
Graham says:
"You don't want to have automated tests, you want to
have automated testing, and the more things around the execution of tests that
you can automate, the better."
MetaAutomation is a language of five patterns, which serve
as a guide to show the tremendous business value that can be achieve by
implementing these patterns and accentuating the value of your Atomic Check
implementation. In effect, this is exactly what Graham is talking about:
automating not just the checks themselves, but analysis, communications, and
other action items around the automation you’re doing for software quality.
