In gesprek met Alan Richardson – Evil Tester

Alan Richardson is een keynote spreker tijdens de Test Automation Day 2015 die wordt georganiseerd op 18 juni in Rotterdam. Als zijnde mediapartner van dit evenement kreeg TestNieuws de kans om Alan te interviewen. Alan heeft meer dan 20 jaar ervaring als IT professional. Hij werkte als programmeur en doorliep alle rollen binnen het testvak. Hij schreef twee boeken en verschillende online trainingen over Java, Technical Web Testing en Selenium WebDriver. Hij werkt als een onafhankelijke consultant en helpt bedrijven om hun geautomatiseerde-, agile- en exploratory testen te verbeteren.


Alan Richardson is a keynote speaker during the Test Automation Day 2015 held on 18 June in Rotterdam. Being a media partner of this event TestNieuws had the opportunity to interview him. Alan has more than twenty years of professional IT experience, working as a programmer and at every level of the testing hierarchy from tester through head of testing. Author of 2 books and several online training courses to help people learn Java, Technical Web Testing and Selenium WebDriver. He works as an independent consultant, helping companies improve their use of automation, agile, and exploratory technical testing.

 1. Hi Alan, can you introduce yourself and explain how you became a tester?
Hi. Thanks. My name is Alan Richardson and I have worked in testing for over 20 years. I started out programming testing tools for a test consultancy. And over time it became easier for me to generate revenue for the consultancy if they sold me as a consultant, rather than writing tools. Fortunately I’d been reading all the testing books and material I could get my hands on, so I was able to fit into that role. And as time went on, I enjoyed the fact that testing required me to use all my programming and modelling and learning and communication skills, and so I focussed more on testing than programming.

2. Can you describe your testing career? Which roles did you had during the years?
I’ve had pretty much every role you can take as a tester. I started as a tester working on green screen mainframe applications, and because of my ability to program, also worked on automating the terminal emulator which we used, to allow us to automate some of the flows we were testing. I’ve worked as a tester on desktop apps, banking systems, database systems, web systems, mobile apps. As a tester I’ve been involved in functionally testing the application, and worked on the performance and stress testing of the application. And even though some of the scenarios I have explored have edged into ‘security testing’ territory, I’ve never badged myself as a security tester.

And as time went on, I acted as ‘lead’ tester and as ‘test manager’, and I’ve also worked as a department head in charge of multiple teams and managers.

I’ve been lucky enough that I’ve been able to work with a lot of automation, and get my hands very dirty in the innards of applications, and work very closely with the programmers on the systems – particularly on Agile projects.

I’m now very lucky that as a consultant, people call me in to help them with their tricky problems, to improve their automation, to help them drill deeper into the functionality of their applications. I get to draw on my experience and have to continually learn new technologies and approaches.

3. Why do you call yourself The Evil Tester?
The Evil Tester” was a cartoon character that I created so that I could vent my frustration with various projects over the years. And I originally setup the domain to upload cartoons, but I found that I’m not dedicated to the cartoon profession sufficiently that I could create enough cartoons and comics, so I used the blog as the location for my ‘hands on & technical’ testing material.

Because one of the intents behind “Evil” Tester was an exploration of an attitude that I think testers need to adopt. Testers need the capability to do the things that other people won’t do to software, to look at the system in ways that other people are not prepared to, and to say the things that other people won’t say. That has never been an easy approach to get on the good side of people and to make them like you, and sometimes people need to see examples of how to do that.

4. On the 18th of June you will be the keynote speaker during the Test Automation Day 2015. Can you tell us what the subject of that presentation will be and why?
The presentation will explore my experiences of using automation in my testing in terms of how it impacts the management approach to testing. Because I’ve worked as a tester, and as a tester involved in automation, and I’ve experienced how hard it can be to communicate the work we do with automation to test management, particularly managers who are not technical. So I’m going to draw on that experience and explain some of the things I did wrong when communicating, so that people learn how to ‘talk automation’ to managers. And how managers can help technical staff communicate to them, even when the manager themselves is non-technical.

And I’ll look at my experiences as a test manager and explain how to get more from the automation that your team creates, and the kind of ‘initiatives’ or ‘processes’ that a management process can introduce (with all the best intentions) that can really impact the automation.

I’ll also explore some of the mistakes I’ve made, that I still see made on automation projects, and provide guidance in how to spot the signs such that managers can help their teams avoid those mistakes quickly.

Fundamentally I want to look back through my career and pull out practical, and implementable lessons learned that can help the automation process increase its value to the test process.

5. How do you see the future of Automated Testing? And do you think it will be possible to test a piece of software without any human involvement in say 10 years?
I’ve been involved in testing for over 20 years, and automation has always been a big part of my work. And I’ve used a lot of commercial and open source tools over the years. I think the future of automation in testing will look much as it has with a few exceptions. And I think the biggest exception will be that tools will work together more. Commercial tools have always had this annoying habit of trying to do everything. I think that will have to change. I think commercial tools will wrap around open source tools, and will promote that wrapping as a sellable feature.

And I expect automation to always be hard. The technology we use to build systems is constantly advancing and for some reason we never seem to take automation, and testing, into account when we build new technology. As an example, we have a lot of mobile platforms, and automation is hard on mobile, and the people making mobile platforms don’t make it any easier. Each new browser has great new features to help with our manual testing and development but rarely make automation any easier.

I do not think it will ever be possible to test a piece of software without any human involvement. We can easily build software to navigate through paths in an application, but we won’t ever trust that automation to have covered every path, to have used all the important data variations, or even to have identified and report accurately all the problems in the paths it did exercise. I think the application of people to testing tasks will always be necessary.

6. Do you have an opinion on all the testing tools that are available for supporting the automated testing process? Are the vendors on the right track or are they missing the point?
There are too many tools available or vendors available to really answer that question. And I don’t want to name specific vendors in a general answer because some tools work really well with some people on some projects. The same tool will add no value to other people on other projects.

I generally view automation as a programming exercise. So I tend to be biased towards automation libraries and tools that let me use them from ‘normal’ programming languages and normal IDEs. So if there is one thing that I think tool vendors miss the point on, it is when they create their own ‘programming’ languages and make it really hard to use their tool functionality from a normal programming workflow.

7. I read you post about “An exploratory testing example explored: Taskwarrior”. I seems like you are a very hands-on tester. Do you see a role for the test coordinators and test managers in the near future? Or are those roles disappearing?
‘Testing’ is a hands on activity. And as such, it is remains important for me, regardless of the role I adopt in an organisation, to have the capabilities and skills to test the software that we build. It also remains important for me, to have the capabilities and skills to wrap automation in and around my testing.

The test co-ordination roles and test management role are disappearing in some projects and some organisations because those environments have adopted new processes. Other organisations still see the need for those people and those roles, because their approach to building software has not changed.

I prefer to work with people that are low on ceremony, and low on bureaucracy and those organisations tend not to require test co-ordinators. They may well have a need for test managers, but the emphasis is less about the ‘reporting’ and ‘process management’, and more about an experienced tester helping teams and more junior testers improve. More about increasing the capabilities and value that the test process adds, rather than enforcing processes and metrics.

But the fact is, the way that we develop software has changed. Therefore there are fewer test co-ordinator and test management roles, therefore the people in those roles will experience more competition and need to be good at what they do, and capable of selling why they are better than other people in that role.

8. Are you planning on writing a new book or are you already busy writing one? And if so, what is it about?
I’ve just finished writing “Java for testers” and have started a few other books. I haven’t yet decided which one will be the next ‘big’ project. I suspect that I’ll write more smaller and focussed books rather than the big tutorial books that I have previously written. People can get an idea of the topics I have in draft form if they look at the range of conference talks that I did over the last few years, and indeed, this year. That’s all I’ll say on the topic to avoid given anyone else too much of a competitive advantage.

9. Do you perhaps have a hobby that nobody knows about? If so, this is your change to share it with the world ;-)
I suspect I have many hobbies that people don’t know about, but many of them have been mentioned in my conference slides over the years. Although, I don’t really think I’ve mentioned my retro gaming habit much. I’ve reduced the size of my collection recently due to the accuracy of emulators and the ability of modern machines to run older software really well. So I no longer have any original 8-bit or 16-bit gaming machines, I rely on emulation for those. But I still have, and use, a Gamecube, Playstation One and Two, Dreamcast, Original Xbox, Wii and Atari Jaguar. I remain agog that our laptops are now fast enough to emulate arcade games in a browser, where the emulator is written in JavaScript. We live in a world of technological wonder.

10. And the last question. Do you want to say or add something yourself to this interview?
I think, when it comes to the subject of automation related to testing, that many people seem to view it as something fearful.

In the same way that we have always used automation as part of our testing processes. Testing will always need people who are skilled at the art of testing, people who understand how to model systems and explore them. Testing will always need managers who understand how to create a test process that fits well into the software building process that an organisation uses, and can help testers and test teams improve.

I personally enjoy the challenge of remaining relevant in the software development world. And much of my work involves helping other people develop, and build on, the skills and knowledge they already have, so that they remain relevant, and can increase their value on projects.

We have always used our minds to explore and understand the world. We have always built tools to help us explore further.

Thank you Alan, for your time and answers.