Category Archives: TUXT

Why everyone needs a better experience of software

If someone makes the wrong decision what might be the impact? It could be frustrating, or dangerous, or even fatal. We all make decisions all the time – what to eat, what to wear, what to read or watch. And frequently we make very important decisions – financial decisions, life changing decisions. We also rely on experts and professionals (nurses, doctors, pilots, financiers, politicians) to make decisions for us.

Apart from our own knowledge and brains, the tools we have to help us are technology, and software. Technology is cheap, and has become the basis for much of people’s decision making.

Software as part of that technology is now ubiquitous, but often fails to delight us. It fails to support good decision making. When the technology goes wrong, when the software is flawed, what is the impact? For example, a satnav that is out of date may give us directions that take us into a road that is no longer driveable. As humans we then need to engage our own brains and override the suggestions of the satnav. But often when automated decision making is provided, people will over-rely on it and fail to over-ride flawed decisions – the [automation bias].

This is important because of the breadth and scope of the decision making that technology supports. Many people are using a wide range of different systems to make many types of decisions:

  • The impact of our decisions may be personal (shopping, dating, entertainment, directions for travel) and important to us, an individual.
  • The impact may be organisational (financial forecasting, data analytics for marketing) where the outcome of the decisions is important to a board and shareholders.
  • It may be geographical, political and global (weather forecasting, border controls, international policing) and important to citizens of many countries.
  • One country’s politicians may use decision making systems local to one country (medical/health population trends, voting systems) and the impact will be on the politicians and the general public.
  • The people using technology may be experts / professionals (doctors, nurses, pilots, farmers) or lay people (patients, travellers, shoppers).

The reasons that technology and software may prompt poor decision making include defects in the software that mean it does not function correctly. If we are lucky, the defect will be sufficiently bad that it is obvious the output is wrong, and so people will correct the software, or ignore/override it. Sometimes, the software is wrong, but it is difficult to see that it is wrong. In that case, people are misled into trusting it, and so may make poor decisions based on flawed advice. More subtly, the software may function correctly, but in a way that does not aid people in making good decisions. The software may be slow, insecure, hard to use. The “user experience” (UX) that a person has when using technology and software should be beautiful, that is what is intended. But dealing with frustrations, defects and consequences of poor engineering is a bad experience for the people using the technology; a flawed, ugly UX.

So – why is technology flawed? Why not build it well in the first place? I will discuss  a couple of the reasons for that in my next blog.

Advertisements

UX? What about TX for Test Automation?

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.)