Skip to main content
blog title image

17 minute read - Published Articles Interviews

Testing Circus Magazine Interview with Alan Richardson

May 11, 2014

Testing Circus interviewed me for their May 2014 issue.

Testing Circus interviewed me for their May 2014 issue. Read the Interview online. Read the full issue online.

Tell us about your journey to becoming a software tester. How did it start and how this has been so far? Was it planned or by accident?

Planning can only go so far. My plan, at University, was to single-handedly save the world from bad software.

At University we were brainwashed/taught about the ‘Software Crisis’ – where most software was late and over budget, and the presented solution was more design methods and automated code generation. So we learned JSP, ER diagrams, etc. My final year project was a JSP diagrammer with an integrated COBOL interpreter, because I thought that if we could visualize the software design, as well as step through it for debugging, then we could solve the software crisis.

When I finished University, I went out into the world as a programmer to build this tool. After the company doing this went bankrupt, I joined a Software Consultancy that wanted to build testing tools to help people work with SSADM (a massively paper based monstrosity of a design method). The consultancy went bankrupt but the project moved into the hands of a Test Consultancy. We tried to build this tool but it was horrible, so we switched to programming a ’test management’ tool. Over time it became apparent that the Test Consultancy could make more money from me if I was out on site as a consultant. And since I’d been working with test consultants, and reading all the testing books while building the tool, I ‘knew’ testing pretty well.

And lo, I was unleashed upon the world as a tester. Still saving the world from bad software, but with a different approach.

When did you realize your passion was software testing?

When I started working on site in a testing role. I saw enormous amounts of inefficiency that I couldn’t really understand. But since I was ‘junior’, and everyone else viewed this as normal, I went along with it. But the more I worked hands on, the more I could see that parts of the testing dogma were nonsense and my ‘passion’ was for ‘good testing’ not the rubbish that we were forced to do.

I still don’t see how anyone can have a passion for the massively bureaucratic, inefficient and wasteful approaches in use at the time. I focused my energy on finding an essence for Software Testing that made sense to me, and figuring out how I could test as effectively as possible. And that often meant working around ‘rules’, and finding ways to automate mandated ‘processes’ that added no value.

‘Testing’ itself: the modeling of systems from multiple perspectives, finding risks in the overlaps and flows, identifying data that spans ambiguities, learning technology to find risks where the tech overlaps the business models, etc. All the thinking, learning and modeling associated with software testing, I find enormously interesting and I still find the application of that on projects, a very compelling activity.

Do you regret being associated with software testing today? Given a chance would you move from testing to any other field in IT?

I do not regret being associated with Software Testing. I don’t think many parts of IT have such a constant application of Systems Theory, Cybernetics, Linguistics, Mathematics, and Philosophy.

I think testing offers lots of opportunities to apply learning from different fields. And there are lots of fields I’m interested in, not just in IT, but outside IT as well; all of which I find I can apply to my day to day work as a tester – and I’m not sure I could apply them as easily in other parts of IT. But – since I don’t engage in those other parts of IT as a professional – I might be completely wrong in that.

I think of testing as one of the most general specialisms in IT. And I consider that a benefit. As a tester I design systems, I program tools, I analyze databases and data structures, I identify performance bottlenecks, I get involved in project management, etc.

I also try to learn as much as I can about all the ‘specialisms’ in IT because I need the ability to understand them, communicate with their practitioners and identify risks and issues associated with them or the overlap of the output of the specialisms.

I think of myself as a ‘Systems Professional’ and my primary lens for looking at systems is ‘software testing’, so I try to learn as much as possible about ‘Software’ as I can.

Your Twitter handle is “EvilTester”. Why is it evil? Aren’t testers a good thing for applications/organizations?

“Evil Tester” was a cartoon character that I created to act as an outlet for frustration with various projects. I thought it better to vent my emotions and frustration through a cathartic cartoon, and then engage with the project on a more professional level.

Since I’ve tested for quite a long time now. My involvement in projects started when people still thought of testing as a ’necessary evil’, where people did view testers, and testing, as an obstacle to overcome, and the project did not always view testing activities as helpful. Given the processes used for testing at the time, I too sometimes shared that view – so I changed my approach.

Even though we viewed ourselves as the ‘good guy’ the rest of the project often saw us as the ‘bad buy’ and I’ve always enjoyed that contrast.

So I played on it by adopting @eviltester and eviltester.com

One of the lessons I took from Machiavelli’s “The Prince” was that an effective prince could not observe all the rules of ‘good’ conduct and that in order to preserve their Princedom, they had to act differently to other people, they could not implicitly trust their advisers and peers, and that they had to learn to follow ’evil’ courses if they must. Very often on Software projects, testers become the people who have to do the same, otherwise we may find no contrary opinions expressed, or limits pushed, or risks exposed.

Some testers may well contribute good things to applications and organizations, but their contribution might not always arise from ‘good’ actions.

And with all of that preceding nonsense I’ve skipped over the prime justification – which I think of it as an entertaining handle and it makes me laugh. Perhaps all the other explanations I provide should be treated as pretentious wibble.

You wrote the ebook “Java For Testers”. Did you get any push back from testers that say they don’t need to learn how to code?

I don’t perceive any ‘push back’ because I don’t think I ‘push’ it on people.

At conferences and meet-ups, some testers do say that they “don’t need to learn how to code” and that’s fine, that’s a decision that they have taken. They have chosen not to learn something that might be of use to them. They often don’t see it as a choice they have made, and therefore argue on the basis of ’need’ rather than ‘choice’. And there are many beliefs they put forward to justify their stance.

I have taken decisions which limit my testing. I don’t particularly like reading sociology so I don’t knowingly use it in my testing. I have not learned security testing. I don’t know statistical analysis. I know Java, but not Python. My choices. My decisions. My limits.

I believe that I gain benefits from having the ability to code. Based on my experience there are test approaches I take on projects that I couldn’t take without coding skills. You can read some of these in my blogs.

I enjoy reading Cybernetics, and from there I learned about ‘requisite variety’. Where a system needs to exhibit a range of varied responses to survive. If someone only has one way to respond, then that might seem to work fine for their existing environment. But if the environment changes then they may not have a response that allows them to survive in the new environment.

I don’t work in a single environment. I find that the more responses I have, the better I can move between environments and adapt to the environment I find myself in, especially as it changes.

Some people really don’t “need” to learn how to code, they don’t ’need’ that variety of response in the environment they currently inhabit. If they did learn to code then they would have an additional way to respond that might help them, but until their environment changes they really don’t “need” to learn. And if the environment does change then they might manage to survive by leaving, their now hostile environment, and moving to another environment where their existing responses provide enough variety to allow them to survive.

I wrote “Java For Testers” to help people who want to learn how to code, and have made the decision to learn.

I didn’t write it to change the beliefs of people who believe they don’t ’need’ to learn to code, so there is no need for people to ‘push back’.

When I started in this industry I wanted to ‘save the world’. Now I’m more focused on contributing the lessons that I’ve learned. So rather than saying “this is the way to do it”. I try to say “this is how I did it, and this is what I think I learned”. These examples may offer people other options to pursue in their own environment.

Some people do comment on what I’ve written in ways that I guess I could view as ‘push back’. But in those examples, very often people have not commented on what I wrote, they commented on what they read. For example, I may have written “I did this” and they read “Everyone should do this”, which runs counter to their belief about what they should do, and they push back on that. But since I didn’t write “Everyone should do this” I don’t perceive it as an effectual response.

You can see some examples of this if you were to trawl through the comments on my blog posts or YouTube videos.

You wrote the book “Selenium Simplified”, which is very detailed and a great learning tool for Selenium Users. Will you be writing more books like this for other tools? If so, which tools?

Thank you. “Selenium Simplified” taught Java and Selenium-RC at the same time. Which really helped people in that situation, but made it a little slow for those that knew one but not the other. So I split and expanded the Java stuff out into “Java For Testers” and I updated the Selenium-RC stuff to cover Selenium WebDriver in my online training course on WebDriver.

I do plan to write other books and create other online courses. They will probably follow from the tutorials and conference talks I do – so next up is likely to be on Page Objects and Abstractions, Proxy tools, and Browser add-ins.

But it also depends on what gaps there are in the available material online and in print. If other people have filled these gaps with resources, and I don’t think I can offer anything in addition, then I’d probably just release my material on the blogs. And I’d work on something else.

Will you be bringing the Evil Tester cartoons back to life or are they gone due to “The Cartoon Tester” by Andy Glover?

I’d love to blame Andy for my tardy approach to cartoon writing. But sadly they haven’t gone because of Andy’s work. 🙂 I’m not sure people realize that the cartoons often take more time to produce than their appearance implies. Hence, I remain in awe of Andy’s ability to keep creating them, which is why I agreed to write the foreword to his new book.

The Evil Tester cartoons may come back one day.

When people least expect it.

When the world is in need of a new hero.

Or at least an old hero, re-booted, for a new set of readers that are not familiar with the previous plots, so I can keep rehashing the same material for years and years, “Bwahahahaha!”

Do you have any advice for our readers on what to look for/out when using open source tools?

First. Consider your own openness to experimentation. The thing that seems to stop people more than any other with open source tools, is that they don’t experiment with the tools, and only use the tool as far as the documentation and tutorials take them. With open source tools, the documentation is often limited. The main cost to using the tool is your time, so spend it well and experiment.

Next. When you find a tool that looks useful. Find other similar tools, and try to learn them at the same time, then you get a feel for the pros and cons of each.

For example, if you have used Fiddler for a few days, try out Zed Attack Proxy, and BurpSuite. See how they compare, then try and replicate the obvious features from one tool in another.

The same applies to libraries, so if you are experimenting with RestAssured, also look at JSoup, both overlap in the sending of HTTP messages, so they might look like competitors, but they each have functionality that the other doesn’t, so try and use them in combination.

Explore and experiment. I frequently chain proxies to benefit from the features in each tool at the same time, and use multiple overlapping libraries at the same time.

I also caution people not to build a ‘big list of possible tools’, focus on immediate problems and expanding your abilities. Live in the ’now’ of your testing as much as you can, as well as maintain an awareness of options.

What is your next big idea?

I think I try to pursue smaller ideas that can have an impact – initially on myself, and then by communicating to others.

I still have tools that I think I might want to build, but I try and realize the benefits by chaining other tools together or using existing tools. e.g. I still want a decent modeling tool, but I can realize many of the benefits by using FreeMind an open source mindmapping tool, I can upload the maps to Mind-meister for sharing and cloud access, I can import them into MindMup for sharing with other people and different permissions. I can write scripts to automate them in FreeMind. There are things I can’t do with those tools, but I can embed tags in descriptions and write custom scripts to parse the XML.

All of the above is my way of saying that I try to ‘solve problems’, in the environment I’m working in, using available tools that are open to being used in combination or with customized scripts. Rather than concentrating on the ‘big ideas’ and the ‘one ring to rule them all’.

Of course, I might also be keeping some things secret, because the world might not be ready yet, and ’they’ might be watching.

According to you, what is lacking in today’s commercialized training industry, especially in Selenium Training?

Since I created a course, I have looked at a few Selenium Training courses to spot gaps in my own course.

The concerns I have with many of them are that they try to cover ‘what is available’ rather than ‘what is used’. So they often start with a discussion of the IDE, and pad out the course with ‘Automation Theory’, rather than focus in on what people need to learn to get their job done.

Personally, I never use the Selenium IDE, and I don’t recommend it for production work, so I don’t cover it on my courses. As for ‘Automation Theory’: in terms of ‘cost of automation’ and ‘how to justify return on investment for automation’ etc. You can read all that stuff online, when you need to, but I view it as padding in the course and try to keep my course as practical and value-add as possible.

I also get the feeling that many of the courses are presented by people who exclusively learned the tool to teach it commercially, rather than because they gained experience with it on production environments.

Selenium Training has the benefit that it isn’t constrained into a certification based format, so at least the approach to training, and the coverage, differs between trainers.

There exist some excellent material out there, but there is also a lot of weak material. I won’t name names, here because those are my opinions, people need to do the research to make up their own mind. When the trainer provides samples of their work, or approach, then you can choose the most appropriate trainer for you. Do lots of web searches before committing to a single trainer (and that includes me).

With the commercialized training industry I see very few courses that I would want to send someone on to help with their career growth. I see far too many that are constrained by the certification process all seem to offer the same thing, in the same way, so people have fewer options.

I encourage people to train with practitioners that share their knowledge with practical exercises and an aim to improve the person taking the course, rather than to gain a certificate. This is why in the UK I have joined forces with a few testers to start up blackopstesting.com because we want to focus on practical testing skills. It is also why my own training and books focus, as much as possible, on practical aspects.

What qualities will you look for in a candidate when you want to recruit someone for software testing job?

When I’ve recruited for permanent work. I’ve looked for people who have taken the initiative to learn new approaches and tools, even if they can’t use them on their day job. People who have read widely in the material and have their own opinions on the topics.

When I recruit for temporary work. I look for people that I think can fit into the environment, and can exhibit the skills and experience necessary to do the work.

Primarily, I look for people who can test. So I sit them down in front of an application and have them test it. Explaining their thought processes so I can build a model of their strengths and weaknesses and can identify how much support they need if they join the organization.

I don’t tend to recruit at the ‘junior’ or ‘graduate’ level. So I haven’t really had to evaluate people with no practical experience.

What will you suggest to people who want to join IT industry as software testers?

Read as much as you can about Software Testing. But view everything you read with suspicion, until you have demonstrated to yourself that it works in practice in the real world.

Gain as much experience as possible. And build a portfolio of your work.

Even if you are a graduate with no experience of working for a company. You can still create a blog. You can still test open source projects and raise defects against them, and blog about what you learned, and how you found the defect and your thoughts about its risks etc.

Yes, that is extra work on top of your day job or studies. Start that way, because you will not learn everything you need to know about Software Testing in your day job, you need to expand your studies into your own time.

Please don’t view Software Testing as an ’easy’ part of IT to join because you don’t need ’technical skills’. View it as the part of IT that lets you learn ‘all’ the ’technical skills’ associated with IT. Pursue it as an unending quest for more skills, more ability, more knowledge, and more ways of viewing systems; and then you’ll be fine.

Name few people you would like to thank, people who helped you directly or indirectly in your career as a software testing professional.

Too many people to thank. Far too many people. I was particularly fortunate that I started working at a small test consultancy in the UK “Software Testing Science” and had the chance to learn from a whole bunch of experienced testers. I’ve also been massively encouraged through my career by many of the public UK test community speakers, and they are all very nice, even when they disagree with you.

I would also need to thank all the managers I worked for who enforced bureaucratic and structured processes that helped foster my attitude of rebellion and approach of subterfuge.

Some testing names, to look up on line, that I remain indebted to – and I have missed out a massive amount of people from this list otherwise it would be far too long: James Lyndsay, Steve Green, Paul Gerrard, Theo Taylor, Graham Thomas, Rob Sabourin, James Bach, Michael Bolton, Simon Stewart etc. etc.

For non-traditional and non-testing names: Stafford Beer, Sun Tzu, Gregory Bateson, Milton Erickson, Richard Bandler, Alfred Korzybski, Albert Ellis, Fritz Perls, Robert Anton Wilson, etc. etc.