Markus Gärtner: Hi Alan, could you please introduce yourself? Who are you? What do you do for work?
Alan Richardson: Hi Markus, thanks for the interview.
I have tested software for a long time now. I started as a programmer writing testing tools for a test consultancy and given the natural evolution in an environment like that, I started testing and consulting through them. Then I went independent and have moved between independent status and permanent employment status a few times.
I have once again adopted independent status. I’ve worked as: manager, head of testing, tester, performance tester, automation specialist, test lead, etc. etc. I need to remain hands on, so I have to keep my programming skills, and my technical knowledge up to date, and most importantly, my testing skills up to date.
In a nutshell; I test stuff and I help people test stuff.
Markus Gärtner: You changed between employment and independent work quite a few times. What do you like about independent work? What do you like about an employment?
Alan Richardson: Employment usually comes with more opportunity for ownership. So I usually get the chance to build the process and the team and have more responsibility for the personal development of the people working there. Independence gives me more freedom and choices, and I gain more time to pursue the side projects on my todo list.
Markus Gärtner: How have you crossed the path of context-driven testing?
Alan Richardson: I got frustrated with the whole waterfall/structured testing approaches during my early baby tester years and started trying different ways of testing. My experiments required that I balance my demands of personal effectiveness and waste avoidance, against the company demands of following their mandated standard process. I learned early on to “game” my test approach and tailor what I did so that I bent rather than broke the rules. I view these as my first tentative steps towards contextual testing. I didn’t know of the context-driven label at this time, so I thought of myself as some sort of surreptitious efficiency engineer.
And as I went from site to site and role to role, I learned to take more responsibility for my personal test approach within the context of another person’s mandated test process. When I eventually did learn about exploratory testing and context-driven testing, they seemed like natural, well labeled ways for testers to approach their testing. Also, I had taken many of my personal testing process influences from psychotherapy, so many of the non-testing subjects I studied; cybernetics, systems theory, Virginia Satir etc. overlapped with the influences mentioned by the context-driven testing community.
As I progressed in my testing career and when I eventually had control over the test processes we used, I didn’t have to work around the test process anymore. I could tailor it for the context that I perceived around me and I tried to recruit and guide testers accordingly. As my career has moved into more Agile Software Development teams, a context-driven and exploratory test approach has become the expected norm.
Markus Gärtner: What did you learn from cybernetics and systems theory regarding testing? In a nutshell, what is the most useful (for you) concept you ran into?
Alan Richardson: Cybernetics affected me on a very wide and general level in terms of modeling systems and arming me with additional metaphors for approaching my modeling of context.
In terms of a single specific concept, I have taken a lot of value from the notion of Requisite Variety. You can find it in Ross Ashby’s Introduction to Cybernetics and extensively explored in Stafford Beer’s work.
Requisite Variety to me means that to survive in a system you have to have enough flexibility to deal with the inputs that the system you are working within will throw at you. There are pithier statements of Ashby’s Law available e.g. “only variety can absorb variety” but we can use normal language to describe this stuff as well, so I also think of it as “you have to be able to handle what life throws at you”.
As a concept it helps me in a number of ways. Is my process flexible enough? Do I have enough ways of thinking through a problem? Have I modelled the system from enough angles? How else could I respond?
When testing I use it to think; have I provided the application with enough variety of input to expose the limits of its ability to respond? And it prompts me to think through the scope of my dealing with the system in different ways.
Coupled with other notions from Cybernetics e.g. attenuation and amplification, I can expand my use of Requisite Variety and ask – has my process survived, not because of Requisite Variety, but because I attenuated the input i.e. I filtered the input, and changed it, rather than dealing with it raw? So did my process survive, not because it deserved to, but because it cheated and ignored input.
I also apply Requisite Variety to the context, as well as my dealings with the context. To remind myself that the context can exhibit Requisite Variety in the face of my madness. e.g. I could put together a very rigid process, that doesn’t handle the inputs of the real world, and doesn’t deal with the level of change in the environment but the context changes to allow my bad process to survive.
I think I see this a lot in human systems e.g. if a test process says “we can’t test under these circumstances, we need stable requirements”, and then the software process slows down, creates full requirements specifications that can only change every 6 months and only with agreed change requests. Then we are seeing a context (software development process) exhibit greater Requisite Variety than a sub system (testing). When really the testing sub system should have been declared non-viable until it exhibits the Requisite Variety required to survive in the context.
Requisite Variety shows up in Systems Thinking texts as well, but I like to get all retro and old fashioned.
Fundamentally, Requisite Variety reminds me to continually up my game so that I don’t have just enough variety to survive but have more than enough to allow me to succeed.
Markus Gärtner: How do you apply context-driven testing at your workplace?
Alan Richardson: I don’t think I know how not to. I have to take context into account now. I’ve studied too much systems theory and cybernetics, so I tend to model everything as a System. Every role that I do requires me to gain an understanding of the people involved, the tools used, the technology in place, the goals sought, the skill sets and budgets available, the timescales etc. etc.
I assume that if I didn’t take context into account then when I come on to a new site I would whip out the templates I used before, and lay down all the rules that I had built up before or taken from an official standard or book. And despite blogging under the URL of eviltester.com, I’m not Evil enough to do that.
I try and start from nothing, and build up what we need. Clearly I bring in my beliefs and principles, but I make every effort to contextualise every decision that I take.
As an example, in my current role at the time of this interview, I recommended an automation tool that I have used in the past, and didn’t like. But contextually it seemed like a good fit for my current client given their goals and situation. Since it seems to fit the current context, I find I currently enjoy working with it (mostly). A side benefit, I think, of making a contextual decision.
Markus Gärtner: You say, that with more and more agile projects, a context-driven testing approach has become the norm. Does that mean that I should test context-driven especially on an agile project? Where does the world of agile development and the world of context-driven testing meet?
Alan Richardson: An Agile software process presents a context, like every other process. And I think we should approach software development processes contextually.
Agile provides the healthy challenge of a process under continual adaptation with the participants taking responsibility for the process, continually learning, improving and changing.
If I try to ignore those aspects of the context then I will fail very very quickly. Bringing me back to Requisite Variety, testing has to exhibit contextually appropriate variety.
Yes, I think you should approach an Agile project with a context-driven frame of mind.
Where do they meet? Well, I think of the Agile development world that I visit, as a contextually driven world. And if I imagine the context-driven testing world as a separate celestial body, then I imagine that they engage in friendly and copious intergalactic trade with each other and that the civilisations probably interbreed by now.
Markus Gärtner: Your blog is called “EvilTester”. Do you think, testers need to be evil? How evil do you consider you personally yourself? Why?
Alan Richardson: Ah ha! I think we should make sure we stick a capital E on the E word. It appears much more impressive that way.
Evil Tester is the cartoon character that I created as a release vent for my project and process frustrations early in my career. I used to scribble little cartoons – some of which I tidied up and put on the blog.
I found it entertaining to embrace the notion that if “system testing is a necessary Evil” then “Evil testing is a necessary system”, and I enjoyed creating a few catchy marketing slogans that empowered me to explore thinking differently.
For myself I think I’m using the E word in the sense of something that could earn the label ‘Evil’ from ‘others’ because of Heretical views, something that questions Dogma, and takes responsibility for its own actions and system of beliefs. But the H word doesn’t have the same impact as the E word.
I also consider it vital that I apply a sense of humour when I review and produce my work. The Evil Tester acts as a convenient Jester and Trickster figure to help me with that.
I don’t think too many testers wear badges on “Be Nice To Systems” day, it certainly isn’t a day that I celebrate. And I do think more testers need to expand their test approaches into areas that they might currently consider unthinkable. I will do what I can to tempt them into doing that.
Markus Gärtner: As you scribbled a few cartoons on your own, did you publish any testing related cartoons? Maybe there is some competition for Andy Glover, the cartoon tester coming up from your side?
Alan Richardson: I’ve gone down the self published route, so currently my blog is my cartoon publishing medium.
For anyone in the test community that wants to communicate visually through cartoons, Andy fills the position of the exemplar. I love the way his work continues to improve. I don’t think I provide competition to Andy. Andy has actually made it easy for me to slack off on the cartoons because I know that someone else is actively serving the test community in that way.
Most of my talks are heavily illustrated with cartoons, but I haven’t published them separately.
Ideally I’d like to try a collaboration with Andy but we haven’t found the time.
Markus Gärtner: Consider Let’s Test is over. It has been the most awesome conference you have been to – ever. What happened that made it the most awesome conference?
Alan Richardson: It was a whole bunch of things. The quality of the delegates, drawn to the notion of context, they all approached testing uniquely and talked and debated from experience rather than dogma and theory. Talking to people between sessions was an enlightening pleasure, we had to reluctantly stop talking when it came time to participate in a session. The speakers talked from the heart, and didn’t trot out the usual nonsense. And what a great line up, I was really excited to attend before the conference, and looking back I can see I wasn’t excited enough. My only regret was that I couldn’t hear everyone. But the social activities and evening events really helped bring us together so I managed to catch up with people in the evening that I couldn’t hear during the day. And then of course there was that thing, with that guy, where he had all that stuff, I still don’t know how he did that thing with the other thing, amazing, that was so funny.
Markus Gärtner: Imagine time travelling is possible now. How would you test your first time machine? Would you use it yourself? Would you travel to the future or the past?
Alan Richardson: First I’d set it to ‘now’ and see what happens.
If it still worked after doing that, then I’d set it to the past. I learned archery and fencing, grew my beard and hair, for this very ‘time-travelling will be invented in my lifetime’ contingency. Set it to 1784 and see if I could help make Cagliostro’s attempted scam, to part Marie Antionette from her diamond necklace, a success. At the very least I’d come back with a dashing new wardrobe, ready for my
next conference talk.
Markus Gärtner: Thanks for your time. Looking forward to meet you at Let’s Test in May.