Another year, another series of three posts highlighting my threads and takeaways from this year’s TestBash Manchester. A big thanks to the speakers, attendees and of course to the Ministry of Testing for laying on such a great conference!
Who wants to fail? In life, we strive to succeed, to do well, and to avoid the pitfalls and dangers we are beset by. As testers however, we need to take a different attitude to failure. Failure pays our bills! Without failure, without the human predisposition to make mistakes, short-sighted or narrow decisions, we are out of a job. So – how do we foster a more accepting attitude towards failure, and learn to not only enjoy it, but encourage it?
Encouraging failure may sound extreme, but that’s precisely the attitude outlined in the excellent talk “The Wheels on the Bus Go Fail, Fail, Fail“, by Yong Yuen He and Dan Smart. The talk brilliant used snippets of kid’s TV show The Magic Schoolbus Rides Again S02E06 “Ready, Set, Fail!” (on Netflix) to illustrate how a more positive attitude to failure can help make better decisions, open us up to new information about product quality (and shortcomings), identify risk before our customers realise it, and generally improve the work we do in our teams. They also made the point that – failing to prepare for failure, reduces our capacity to handle, respond to, and learn from failure.
One of the most important points of this talk was that failure is not only desirable for many reasons (how do we learn what doesn’t work without seeing it first hand?), it is inevitable! We cannot realistically expect to make such complex changes as most software requires without introducing failures from time to time. It happens! And it happens because even the best systems in the world can’t handle the enormous, chaotic complexity of the real world. We will miss something. We will fail to consider someone. We will make a mistake somewhere! Thinking logically we must accept this conclusion, yet so often we come up against the “failure is not an option” myth. If it’s not an option, get ready to fail again! Failure is ALWAYS an option. Refusing to accept it, and therefore refusing to plan for it, just make the situation worse – as the talk suggested, it can create a toxic culture.
I really liked the attitude of “no pain, no gain” the two speakers spoke about here. Whilst I don’t always subscribe to those kinds of philosophies, it does make sense here, and on top of that as testers we always need new perspectives and angles with which to sell our info to stakeholders. It’s our job to find failure! Yes, we want to recognise and embrace failure as early as possible – shifting left and moving test upstream are all about this. But we must always acknowledge that isn’t and will never be the whole picture – and we need to take stakeholders along with us on that journey to the right.
So, we need to fail, but what does this look like – and how can it be safe? Pierre Vincent‘s awesome opening talk “Observability and Testing” also touched on the theme of failure, specifically how and where to look for failure, and strategies for handling failure when it does happen. Pierre suggested that once our software reaches production, for a lot of teams, that’s the “endpoint” – but it shouldn’t be. Once we release software into the wild, it actually starts doing the things we designed it to do – or not! Without good observability of how the software performs in the hands of real users, we’re barely seeing half the picture, and we’re unlikely to learn what we have missed in our testing. We need this failure intel to do better in the future.
There’s an important distinction to be made between monitoring and observability – just being able to monitor if there is failure is not enough, we need to be able to dig into the failure and get the good information from it. Pierre shared a quote from Baron Schwartz:
“Monitoring tells you whether the system works.
Observability lets you ask why it’s not working”
– Baron Schwartz
We got some great pointers for tackling this in-production failure from Pierre’s exploration of metircs, logging and tracing, and I was reminded of last year’s topic of testing in production throughout the talk. A fundamental truth Pierre laid bare was that… systems fail! By accepting this we better enable ourselves to strategise for this failure, and to recover quickly and painlessly. By getting comfortable with failure, strategising and preparing for it, we’re in a position to not only respond to it – we’re in a position to learn from it.
Areti Panou’s talk on the bystander effect in quality conversations, “Turning the Quality of Your Deployment Pipeline into a Team Task“, approached failure from a different angle. What if everyone in your team is bought into the idea failure is inevitable, and that quality is important, but none of them take ownership when failures happen? Comparing this to our own development teams, I bet most can imagine a scenario when no-one seems to want to take charge of a job everyone agrees is important. So imagine a build failure – but everyone just keeps working, assuming someone else will fix it. That’s a big failure to ignore! And what of the mindset of the team who ignores it?
I really enjoyed the personal, anecdotal style of Areti’s talk and it felt very relatable to a number of situations in my own career as a tester. The big takeaways for me were considering how acknowledged psychological tendencies like the bystander effect (I remember studying the case of Kitty Genovese in my Psychology A-Level) need active, workable solutions in our industry – it sounds obvious, doesn’t it? We are dealing with people, after all! But like many conference talks this just wasn’t an angle I’d considered taking into my work before. Eyes and mind opened, yet again!
Testers should not only embrace failure, we should encourage it in order to foster an environment where we can respond quickly and effectively to failure, without having to fear it. As Yong and Dan demonstrated – we need a “safe to fail” environment which is not about blame, and is instead all about growth. How do we grow if we aren’t allowed to fail? If failure is terminal, why would we experiment? Risk is a fact of life, not a horror story. Does your organisation do enough to acknowledge that?
It’s something I’m going to have to ponder for some time – what can we do to take the risk out of the inevitable failure our teams will experience? How do we make failure “OK” for our stakeholders? How do we “sell” failure as something to be embraced, rather than feared?
Feel free to share your thoughts, tips and ideas in the comments!
Parts 2 and 3 of this round-up coming soon…