1. Test automation requires consideration of the User eXperience (UX) for the tool and the tests;
2. People who use automation might not always be technical but they are always human;
3. UX-Design and UX-Testing for test automation supports improved decision making and quality.

Independent quality and testing consultant Isabel Evans has more than thirty years of IT experience in quality management and testing in the financial, communications, and software sectors. Her quality management work focuses on encouraging IT teams and customers to work together via flexible processes designed and tailored by the teams that use them. Isabel authored Achieving Software Quality Through Teamwork and chapters in Agile Testing: How to Succeed in an eXtreme Testing Environment; The Testing Practitioner; and Foundations of Software Testing. A popular speaker at software conferences worldwide, Isabel is a Chartered IT Professional and Fellow of the British Computer Society, and has been a member of software industry improvement working groups.

This talk is paired with What does technical enough mean? as part of a conversation track on Automation and People

 

Is it me, or is it the tools?

 

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

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.

 

I believe there is a need for a better User Experience (UX) for Test Automation: that is, the TX (Testers’ Experience) for those people who will request, design, and review the results of the automated tests and monitoring. I’d like to have a conversation about what TX is needed to support our work.

The conversation: “Automation and people”

Are we technical enough? Are the problems that people report with tool adoption a problem of testers not being technical enough or of tools not being easy to use? Are we over emphasising the technical and ignoring the personal?

Join the conversation with Alan and Isabel where we’ll talk about stuff like:

– What levels of technical skills, knowledge and ability are required for systems development, and specifically for testing activities?

– What do we mean by “Technical”? – just Technical (IT) or also Technical (Domain)?

– What types of technical knowledge support our testing (for example technical architecture, hardware as well as software, code, etc).

– How do we keep up to date with the technology we test? If not, why not?

– If the ‘technical people’ on the team don’t understand the system, how do we identify technical risks?

– As the toolset we use matures, can we rely on it to support people better, or are the people driven by the technology they use?

– How do we improve the Tester’s Experience of automating and working with more technical systems.