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!
It seems strange to those outside our industry that success of our software often lies in the way those of us who build it speak to one another. Surely an application lives and dies on the ability of great coders to write great code… right? Whilst that’s definitely true to some extent, this opens up when we begin to consider what “great” really means. What’s good, valuable, valid is contextual – and our software has to fit the needs of so many different people, each with their own context! This is one reason teams make better software than individuals, a topic which is close to my heart and certainly not new, but just as valid as ever. This TestBash we saw a number of great speakers take on the topic of how working as a team, interpersonal reactions and human-led processes enable us to build better software.
I’ll start with Kwesi Peterson‘s excellent talk “How I Learned to Be a Better Tester Through Practising “Humble Inquiry”” – the most “soft skill*”-focused talk of the day. Kwesi made some amazing points throughout his talk and gave a lot of practical, actionable advice in how vulnerability can enable us to do better work with our teams. Kwesi repeatedly asked us to consider things from a fresh perspective, by asking:
“How can we solve our biggest challenges, not by telling, but by asking the right questions?”
Kwesi suggests questions like “And What Else?”, and “What’s The Real Challenge Here For You?” are some of the most powerful tools in the tester’s arsenal. These simple words can unlock a new way of looking at our “people problems”, and I was struck by Kwesi’s suggestion we need to ask questions to which we don’t actually already know the answer. Often we use questions to draw someone to a conclusion we have already reached, but this isn’t the point of the humble enquiry as he practices it. Instead he suggests we get the most out of conversations where we allow ourselves to be vulnerable, curious and empathetic. In doing so, we get not just the message people plan to give us – we get what we need and understand what others need from us (or our software), whilst fostering stronger relationships along the way.
I think back to my own testing practice here and reflect that often the most powerful thing I can do is admitting I don’t know the answer. I am a non-technical tester and I can use this ability to be the “layman” in the room – I can ask people to explain how or why something is being designed or implemented the way it is. Often this draws out powerful insights, mismatches between logic of those who thought they knew what was going on in the room. By allowing ourselves the option of admitting we don’t know something, we begin to build a trusting relationship with those around us, not just in our immediate teams but external stakeholders too. The central message of allowing oneself to be vulnerable really resonated with me, and I was very pleased to have seen Kwesi’s talk.
On a similar “soft skills*” note, we had the great talk “Continuous Testing” by Gary Fleming. Gary started with a statement about the role of testing in Agile, and suggested that testers have never quite “had their moment” – something which definitely got the room interested! Gary advocated Three Amigos, Example Mapping and Feature Toggles as key ways to enable a continuous testing approach, but what struck me most about his talk was the clarity and ease with which Gary demonstrated that the ability to have strong, meaningful conversations underpins great software development.
Example Mapping is a kind of structured conversation around product requirements, where three team members (typically dev, tester, PO) sit down and assess the readiness of requirements to be planned into a team’s sprint. They do this by writing quick index cards of various colours, in order to get a quick visual indication of the amount of doubt still in the requirements:
Story – yellow – a high level summary of the requirement
Rule – blue – basically an acceptance criteria
Example – green – Given, When, Then description of behaviour
Question – red – Anything unknown, we don’t dwell on – write a question and move on
Through running this process a number of things become evident: Too many questions, too many rules, too many/few examples, etc etc… by running this structured conversation we give it visual form and this can give us a new way of analysing our requirements. Gary credited Example Mapping to this post by Matt Wynne.
The final point Gary made was that testing needs more coaches, and for testers to foster “a coaching mindset”. That is, testers teaching their peers, teams, stakeholders and organisations about quality, and the value testing can add. In order to have the biggest impact, testers need to be more than testers – they need to be quality advocates. Great to hear this message, and inspiring to see a room respond to it!
The last talk I’ll mention today was the personal and impassioned “My Story of Kanban and Its Positive Impact on Testing” by Conor Fitzgerald. Conor’s talk was ostensibly about process and delivery, but a lot of the stuff which spoke to me the most as around the quality of interactions and conversations on the successful outcome of Conor’s team. Conor prized collaboration most highly, alongside quality over quantity, and a belief people can change. Collaboration makes the whole system work!
A key example of this for me was Conor’s discussion of quality gatekeeping, specifically the idea that testers should own quality and if there’s a quality problem, it’s for the tester to solve. Quality is and must be a shared team responsibility, and quality problems no-one’s “fault” but everyone’s job to fix. This speaks to high quality conversations and the exact kind of coaching mindset Gary was talking about – we need to have better conversations to enable this shift in teams where this happens. One specific tip from Conor was to consider that smaller changes are much less scary to test, and therefore more inviting to non-testers. By getting our teammates to do some of the work we ordinarily keep to ourselves as testers, we expose them to the challenges and considerations we’d like to handle earlier on in the process.
I’m fortunate to work in an environment where every developer tests at least some of the time. This was a strange concept to me, coming in from a waterfall background – but it works surprisingly well and fosters respect for the job we do. If devs test, and hate it, they learn to value their testers! But if they don’t hate it, and instead find a new way of looking at the software problems we all solve, better still. In short, getting the same people to see things from one another’s perspective is incredibly valuable, and what better tool do we have for this than great conversations (except perhaps great questions)?
Feel free to share your thoughts, tips and ideas in the comments!
Part 1 of this round-up published yesterday, read it here
Part 3 of this round-up coming soon…