First in a series of posts summing up my thoughts on the Ministry of Testing’s latest success.
Note: The summaries below are based on my takeaways from the discussions, and are not necessarily representative of either the original intent or meaning of their authors! I only offer my perspective on what I heard, so my apologies if anyone feels misquoted. With that said…
3. James Bach – The Two Villas of Software Development
James was clearly a big draw at TestBash Manchester, and given the quality of his material and presentation it’s not hard to see why. His talk through the positives and negatives of Social Distance and Critical Distance was referred to throughout the conference, so fundamental were its key points. One of the illustrations of this was the idea of the testing and dev villas.
James suggests that developers operate from a “building mindset” which is not the same one testers generally use. It’s common knowledge that testers are valuable specifically because we approach software differently – James describes our mindset as “defocusing” – and therefore discover things devs wouldn’t necessarily look for or notice. We have distinct “primary roles”, based around our specific strengths; however, that doesn’t mean we should work siloed from devs; far from it, and indeed the best testing is often done in collaboration with a developer.
But how to approach this? By learning code and tech, becoming a “mini dev” and thereby losing some of the mindset which makes our testing so valuable? Or by insisting the dev become a “mini tester”, adopt our way of seeing the world and thereby lose some of their advantage? James suggests that roles like these are a “semi-private space” for which one role is most “accountable”, but which others can “alternate into”.
A particularly powerful analogy was that of the “testing villa and development villa”. James suggests that as testers, we can invite devs to the party at our place. In doing so, we do things “the test way”, with a dev in tow, understanding what we’re seeing, investigating alongside us. Once the party is over, the tester clears up – it’s their place, after all – by writing bug reports, devising new tests and otherwise doing the testerly thing.
At the same time, the devs can also hold a party at the dev villa, and testers can come along. In doing so, the tester gets to explore how devs work, see under the hood of the software and understand key decisions and behaviours whilst they are being written (or fixed). Similarly, after this has happened, the dev clears up their place – fixing code, writing new feature elements they’ve overlooked, etc.
By alternating their mindset, the tester is able to provide more value, to see from both sides of the fence and collaborate in both the traditional “test space”, and also while the code is still being written.
2. Stephen Mounsey – Reductive Vs Expansive Listening
I found Stephen to be the most quotable speaker at the conference, dropping such gems as “Testers make other people’s thinking better”, and suggesting that a key role of testers is “creating thinking spaces”, enabling other team members to better work towards their goals.
One idea which stood out for me was that of Reductive vs Expansive Listening. To add a little colour to those:
Reductive Listening is listening for “the bottom line”. Someone is listening reductively if they are only listening in order to find a solution – they want to respond, to give some insight back which the speaker doesn’t have yet.
Expansive listening is listening “for listening’s sake”. It is understanding sometimes people just need to let off steam, and need someone to listen without judgement, or an expectation of finding a solution.
Stephen suggested whilst we’re used to being highly performant members of our teams, and therefore trying to play a part in finding solutions to all the team’s problems, it’s often the case that we’re not being approached for a solution
This reminded me of the notion of rubber ducking. As a tester I’ve often played rubber duck to devs who only needed a sounding board, a non-technical one at that, before they could unlock the solution themselves. By talking things through, whilst I listen expansively – that is without the intent of providing a solution – the dev would solve the problem themselves, uncover a new avenue of investigation, or simply let off enough steam to get on with the onerous or ugly task they felt like talking about in the first place.
It’s a valuable thing to remember that sometimes, you’re not expected to take the team’s problems on your own back. Sometimes you’re more valuable by choosing the right style of listening, and letting the team solve it’s own problems.
1. Kim Knup – The Relevance of Positivity
Kim’s talk was a real goldmine of excellent ideas, and a very fresh way of viewing our approach as testers. Rather than suggesting a technology, a new way of writing test cases (more on that in a future post!) or reporting bug metrics, “recovering pessimist and misanthrope” Kim spoke to us about the relevance and power of positivity in the role of Testers.
Whilst testing can seem like an inherently negative, critical exercise – searching for the faults in other people’s work – we can still approach what we do in a positive manner. And whilst there is undeniable pleasure to be had in finding bugs (“Us testers get to raise bugs and make the devs cry!”), there may be greater rewards in working together. That can mean a greater focus on positive testing, to confirm the features actually do work as expected rather than simply seeking failures; it can also mean doing what we do with a smile on our faces, in an attitude of collaboration rather than negativity. To quote James Bach earlier in the day: “Why don’t you love me when I criticise you?!”
With statistics and CBT-based research to back this up, Kim suggests there is a key link between creativity and positivity – that by remaining positive in what we do, we do our jobs better (including designing negative tests). We move from a “fight or flight” mindset which is the antithesis of collaboration and is often highly confrontational, towards a “broaden and build” mindset, where both dev and test are producing something creatively with the goal of reaching the same end goal: quality software.
As Kim put it: “90% of long term happiness comes from the way our brain processes the world.” By choosing to adopt a more positive attitude, we not only make ourselves happier, but encourage those around us to do the same.
Kim emphasised the importance of quality information above quantity of bug tickets, and suggested we can form more positive working relationships with devs by simply pointing out bugs, rather than being caught up in documentation and metrics. I couldn’t agree more! Being a slave to documentation (beyond what’s necessary) is a surefire way to sour relationship between dev and test, and we should not see our output as “bug tickets and test cases”, but rather “collaborative approaches to software development”.
An oblique angle on what we do, and a really relevant and useful one. Today has been day one of positivity in the role for me – whilst I think some of the devs are expecting a punchline, all told I’m already finding a shift in mindset useful.
James Bach – Don’t Think So Close To Me: Managing Critical and Social Distance in Testing
Stephen Mounsey – Listening: An Essential Skill For Software Testers
Kim Knup – On Positivity – Turning That Frown Upside Down