The other day, I got the latest ACM Code of Ethics by snail mail!
The online version is here: https://www.acm.org/code-of-ethics
Here are some quotes:
“A computing professional should be transparent and provide full disclosure of all pertinent system capabilities, limitations, and potential problems to the appropriate parties.” *
“Computing professionals should insist on and support high-quality work from themselves and from colleagues.” **
“High-quality professional work in computing depends on professional review at all stages. Whenever appropriate, computing professionals should seek and utilize peer and stakeholder review.” ***
ACM is calling for transparency, honesty, trustworthiness, and high-quality work. Their focus is on software developers, so primarily, they’re speaking to the devs about those values.
For measuring, communicating, and managing quality, MetaAutomation shows how QA can achieve those values too:
The MetaAutomation pattern language, starting with the Hierarchical Steps and Atomic Check patterns, shows how to record all the information of driving and measuring the product in a way that was not possible before, and in an automation-friendly robust format. (I use a grammar of XML.) This enables anybody on the team to see, in role-appropriate ways, everything that is going on with the SUT under automation, including perf (and optionally, product instrumentation). This information is relatively compact (and, highly compressible) so trends over time are clear with analysis through implementing the Queryable Quality pattern.
Team-wide quality discussions are augmented by a transparent view of the product as it is driven and measured by automation.
With MetaAutomation, the QA role never has to manually report in what is going on with their automation, because it is transparent to everybody (see above). Developers, too, have the products of their hard work made more transparent than before, and faster, too.
For functional quality and perf, a detailed record of what the SUT is up to backs up the engineers’ honesty about their work and helps communication.
Automation code is self-documenting at runtime with the hierarchy with a base in the business-facing steps of a check and leaves that are atomic steps, plus any other instrumentation data added to any place in the artifact of a check run. There are no log statements to make and no keywords to implement with code that is generally invisible outside of QA.
This information is available to anybody on the larger team that cares about quality, in role-appropriate yet client-guided ways; a product owner will be most interested in the business-facing steps near the base of the hierarchy, but developers, testers, and the QA role will want to drill down the hierarchy to the atomic steps of the check – recorded just as it happened at runtime.
The steps have stable, readable names, and they are inline with the code - as close to the code as one can get! Trustworthiness is higher than possible before.
MetaAutomation starts with challenging some historical accidents that have impeded QA’s value to the larger team. It then shows how the QA role can become the foundation for communication around the team for quality, including what exactly the SUT is doing.
MetaAutomation gives clear guidance on how to optimize automated checks, and simple patterns that describe how QA can deliver maximum benefit to the business in quality measurement, recording, and communicating.
These things empower QA, guide them, and inspire them to produce their best work.
MetaAutomation shows how the QA role can rise to attain the same respect as the developers.
*(from Section 1.3, page 5)
**(from Section 2.1, page 7)
***(from Section 2.4, page 8)