Breakpoint 2020 is a 4-day virtual summit on everything testing. We're bringing speakers from the best dev and QA teams to talk about building QA processes, automating at scale and best practices for success with tools and frameworks.
Alan Richardson is a Software Testing Consultant who goes by the name of 'Evil Tester'. He consults, coaches and mentors teams to help them test better, automate and deliver software with improved quality.
Alan advocates 'evil testing,' a special blend of skill, attitude and pragmatism to help software development teams test and develop better. He has authored multiple books, conducted training sessions, and spoken at several conferences.
What does it mean to be an ‘Evil Tester’?
I try to tempt people into pushing the boundaries of what is acceptable and doing things to the system that no one else would do. Things that no one would even imagine doing, i.e. push features to their limits to see how much they can cope with.
But it also means you need to think the things that no one else is thinking. Projects tend to have a lot of people working on them, and this can lead to groupthink. We need to have a balance that causes people to stop, revisit their assumptions, and challenge the norm.
There are plenty of experts that will tell you that you "must" do certain things, and that you "can't" do some other things. Think differently. Do whatever it takes to make a difference in your environment .
That's what I mean by "Evil Tester."
Can you give us a sneak-peek into your session for Breakpoint 2020?
My talk is going to be on thinking differently about automated testing, learning from some real world examples.
I see a lot of people telling us not to automate when the system is unstable, so I'm presenting a case study of why this seems like the most appropriate time to automate.
We'll also cover some examples of automating to support the tester, rather than to automate the acceptance criteria, and some of reusing abstraction layers to support different types of automation (not just the linear paths).
Staying within the theme of 'evil testing', we'll go over what we 'can' and 'could' and how it 'might' help us, rather than what we 'must' and 'should' do.
Can you tell us about the books you’ve authored?
There are three current books: 'Java For Testers', 'Automating and Testing a REST API' and 'Dear Evil Tester'.
They're all based on my experience and try to fill the gaps in the market. I wrote 'Java For Testers' because testers tend to use Java differently. We don't create apps, we tend to create tests, and use a lot of libraries. So 'Java For Testers' teaches the basic Java needed with everything written test-first, covering libraries separate from core Java.
Once we know the basics of Java, everything else is just about adding in libraries. Too often, people learn libraries rather than coding. I've also noticed many people using 'main' methods to drive their automated execution because none of the YouTube videos they watched used test frameworks.
'Automating and Testing a REST API' was designed to provide an introduction to the subject of REST APIs, built around a case study—so it quickly covers the theory of APIs and HTTP, driving APIs interactively from the command line, GUI tools and proxies. It also covers automation with REST and HTTP libraries, with various abstraction layers.
'Dear Evil Tester' encourages the reader to think differently about testing, to challenge their assumptions, to think for themselves, and to develop the attitude and mindset of a Tester.
Have you worked on any side-projects recently?
I'm currently working on a model-based REST API generator, called "The Thingifier," which can spin up a full API from a simple model of entities and relationships, complete with a GUI and Documentation. I will expand that to do more in the future. At its simplest level, it is a way to create 'practice APIs' for learning how to test and automate APIs.
What are you reading/learning right now?
I'm studying direct marketing, advertising and copy writing. This includes work from people such as: Drayton Bird, Bob Stone, David Ogilvy, Rosser Reeves, John Caples, and more.
This is because I have to do all the marketing for my own books and courses, and effective sales and communication is one of the keys to success.
What advice would you give to people who’re new to testing?
Get hands-on as fast as possible. Test as many applications and types of applications as you can.
Make notes of everything you do, as you do it, in enough detail that you can come back to it months later and still understand what you were doing and thinking.
Keep a list of all the things you don't understand.
Work through that list of 'stuff you don't understand'; search for it online, watch videos, and read blog posts, until you understand it enough to use it as part of your testing.
Never assume that an application is so simple that you can't learn anything from it. I keep going back to old practice applications I've written, to see how I can view them differently now, and how differently I can test them, based on all the things I've learned since I last used it.
If you want to go beyond 'test apps' to practice on, then sign up for Bug Bounty programmes like 'Hacker One'. You might not find any security issues, but these are sites and environments that are giving you permission to test them.
Keep learning. Keep practicing. Take notes.
Develop your own models of testing so you can explain your approach, and the risks you identify, in your own words.
