Learning from hitting a brick wall

I’m fizzing with all the stuff I learned at European Testing Conference in beautiful Valencia  last week! I gave myself the gift of taking sketch notes of all the sessions I attended, so I’m hoping I can do a few blog posts about it. I have been neglecting this blog lately because I spend so much time writing posts on mabl.com. (Which I hope you will check out – they are not about mabl!)

Anyway – I’m gonna start with the very first session, the keynote by the awesome Angie Jones. It was the perfect kick-off for two days of inspiration.

A surprising turn of events

Angie has helped us get traction on the road to successful test automation for a few years now. She has given our software community the amazing gift of Test Automation University, which is free and incredibly valuable – I’m enjoying the courses myself.

When Angie started describing her approach to a huge automation challenge she faced, I expected to learn that she came up with a creative, successful solution. In order to do the testing she felt was needed, she automated creation of test data and setting up scenarios for further testing. Lots of head nods and “aha moments” from the audience as she told her story. (I’m writing this from my notes, so I hope I’m recounting this accurately enough. I believe there will be a recording available of Angie’s talk.)

Angie recounted how she found she needed an API endpoint to retrieve data to help with testing, in an area of the app that “belonged” to another team. Unfortunately, that team responded that they did not have time to do that work, even though it wouldn’t take long. Angie sought help from her manager, who arranged for three teams to get together to discuss the request. Whole team approach to testing, right? That sounded like a great way to get the problem solved. However, the result of the meeting was that a decision that there was indeed “no time” to create the endpoint. Angie hit the proverbial brick wall. It’s happened to a lot of us – but hard to believe it could happen to Angie!

Testability is a team responsibility

Angie emphasized testability should be a requirement of the feature you’re developing. She referenced Rob Meaney‘s 10 Ps of Testability model. (I’m looking forward to Rob’s upcoming book on testability with Ash Winter. If you’re a Ministry of Testing Dojo Pro member, watch his master class on testability.)  She showed how many of the “P’s” were missing for her team in this situation. It’s hard to understand why any organization would fail to make good choices that let them build quality in. Unfortunately, some simply don’t understand the value of investing in quality.

It was surprising to hear Angie describe anything less than a success story. What is so valuable about this story were her many lessons learned. We can all learn from her story and potentially find ways to get teams engaged in creating testable software.

True leaders like Angie aren’t afraid to share failure stories as well as success stories. As I attended subsequent sessions at the conference, I’d learn about a new idea, and think about the ways it could help with the scenario Angie described. Angie had such creative ideas for testing in production, automatically generating test users, automatically updating a field in the database to facilitate the testing without affecting actual customers. If she could have gotten one more bit of help from teams outside her own, she’d have been able to easily check the functionality.

I felt that Angie’s larger message was that a whole team approach to building quality (including testability) in, with support for automation that enables the team to succeed with testing, is key. When the whole team works together to try new experiments and see what helps them progress their quality goals, the magic happens.

Valuable lessons learned

I’ve been extremely lucky in my career to mostly work on teams that were allowed to take time to learn and solve problems, including finding good ways to support testing and quality with automation.I have lots of success stories to tell. But as with Angie’s keynote, maybe the failure stories are eve more powerful.

I’ve also worked on teams where the culture worked against collaboration across all teams and roles within teams. Even when I led a successful agile project within the company, people were unable to let go of the way they were used to working. That way wasn’t working, the product was failing as a result, but I think they were so stressed out they just clung to something familiar. I used patterns from More Fearless Change that usually work for me, but I failed in that organization. I bailed for an opportunity to work on a self-organizing Scrum team, where our whole team worked step-by-step to succeed with test automation. The lessons I had learned from my “failure” helped me contribute more in my new team.

We’re always hearing how failing is good and we shouldn’t be afraid to experiment. However, in some company cultures, it isn’t safe to fail. If you’re working in that type of environment, see if you can be an agent for change. And if you can’t get any change going, see if you can find a better opportunity. Whatever happens, don’t beat yourself up for failures. Our most appreciated leaders also fail sometimes. You’ll be a better team member in the future if you can see a failure as learning from an experiment.