Test automation is intended to increase speed and accuracy of information about the SUT partly by allowing engineers to improve the speed and usefulness of their communications.
The best possible interfaces and user experience for the person testing are required to support this otherwise the use of automation will decrease rather than increase velocity of projects.
If the speed and accuracy of test information provided to teams is lowered, with poor test reporting and inaccurate decision making, engineers and managers will become frustrated. It may even lead to disaster.
Good automation tools will help us make good decisions about the SUT and maximise the value of the limited time we have to deliver software products to market. Poor automation tools will delay decision making, increase the likelihood of errors of judgement, and they frustrate both engineers and managers.
Current practices (agile, build pipelines, devops) arise from a need to address delivery speed and accuracy as well as engineering quality. But automating the tests and then forcing people to spend time inaccurately and slowly interpreting the outcomes simply is not cost effective or helpful.
There are many examples of poor interfaces and tools contributing to, or even forcing, humans to make bad, even fatal decisions. Examples such as the London Ambulance Dispatch system (http://bit.ly/1tr2TJZ), and the EU Farm Payments online application system (http://bbc.in/1xEoUE3) show us that poor interfaces can be time wasting, expensive and dangerous.
This matters for test automation because, although automation tools are written and serviced by engineers, the people who use the automation can be non-technical for example user acceptance representative, product owners, business sponsors, managers or end users. Does the information they get from the automation and provide to engineers improve in speed, accuracy and usefulness as a result of the automation or not? What will maximise our ability to get the most from the test automation? What will maximise the accuracy and usefulness of the information provided to engineers, managers and others?
There is a need for TX for Test Automation: that is, the Test Experience for those people who will request, design, and review the results of the automated tests and monitoring. This requires information design and delivery (arguably the purpose of our industry).
Attention to detail “front of house” for the UX for customers and end users can be extended behind the scenes to TX for the engineers, benefiting all. TX can be improved, by consideration of the UX for the automation tool and the tests so that methods and lessons from User Experience Design (UXD) and User Experience Testing (UXT) may be applied to test automation.
We need to consider human factors (as the engineers are human too) as well as the support of improved decision making around quality, speed and accuracy of responses to issues.
My three key points?
– Test automation requires consideration of the UX for the tool and the tests;
– People who use automation might not always be technical but they are always human;
– UXD and UXT for test automation supports improved decision making and quality.
(This post also appears on my “Isabel Evans Writing” blog.)