The Power Of Pairing

In my previous piece on exploration, I touched upon the power of pairs, but "not by those words" (to quote James Bach).  I was reminded again of the theme this weekend, due to the following interchange ...

I'm a member of my local Les Mills gym.  Without doubt one of my favourite classes is Impact, a boxing themed class where we put on our gloves, and hit various punch bags and pads.  With a few bits of skipping, squats, press-ups and burpees thrown into the mix.  It's a very fun but challenging class, with a great atmosphere.

After class this week, I stumbled upon a History In Pictures photo on Twitter, and shared it with my Impact instructor Josette.

It's a picture of some women training on a rooftop in the 1930s.  I didn't notice much except that,

• It's black and white, and the kind of grainy quality of a 1930s photo
• The cars in the background look the right period
• Clothes and hairstyles seem period
• The girls all have really rather nice legs (I know, potentially a bit sexist, but the honest truth)

Have a look again?  Notice anything?

From my own knowledge, I know that for this historical period women's professional boxing would be rather unusual.  Only relatively recently have women been taken seriously in boxing - as Josette of course knows.

Josette loved the photo, but had an observation to make ...

"I wonder if they were part of a circus. Just the accessories on the floor for juggling and something that resembles a small trampoline."

My reaction to this was "huh?  What accessories?".  Darn that I was too distracted by legs to notice, but yes indeed, there they are!  Once you see that, your understanding of what you're seeing changes.  More than likely this isn't sparring proper, but more than likely practicing some form of staged/faked fight for entertainment (and probably titillation of a male targeted audience ... so maybe the legs ARE important).

So what's it all about?

We all know that two minds are better than one.  Likewise two sets of eyes.  Indeed the very existence of testing as a profession has come from people finding that we're more likely to find issues in software if someone writes the program, and a second person tests the software.  This studies have shown time and again this gets better results than just a single developer who "programs and tests".  That's because the developer who tests his own code uses a mental model of how the software should work to build it, but then use exactly the same model to test it.  We don't check in any way we've not previously expected, and that leaves us blind.

There are lots of pieces out there about the impact of inattentional blindness in software testing, especially from context driven testers.  To put it simply, we can get hung up looking for one thing, and miss something else that's under our nose.

Although here I joke about the girl's legs, I was too busy looking for clues to the pictures period (rooftops without aerials, cars, picture style, clothes hair) that I actually missed a lot of key things in it - namely the trampoline and various juggling items.

When we were out exploring Baring Hill, I noticed some things about the site, but my son had to bring my focus down to the pipes in the ground for me to notice them and follow them and use them to tell a story.

This reminds me of something I was told years ago when we were giving a statement about a traffic incident to a police interviewer.  The police try and gather eye witness statements from as many sources to piece together a picture of what's happened in any incident - usually everyone recounts the same events based on their perception, but not everyone tells it the same way, with some adding details that others fail to mention as relevant.  One baffling example was a case she'd been a part of where several people had independently described a suspect to her, but the eighth person mentioned "and he was blind".  In actual fact, the previous seven had forgotten to mention this key detail, although later all went "oh yes - he WAS blind".  Sometimes we're so focused (which is the same as saying distracted) on the little details - hair, shoes, clothes - we miss the big stuff.

In all these stories, having an extra perspective allowed the person to question or state things, to bring them to the table for discussion, and thus expand on one persons perspective.

This is the power of pairing.

Who to pair with?

Most people when they talk about pair testing usually mean testing between two peer testers.  I've not always had the luxury of another tester, especially when I'm working on small projects.

Sometimes I've paired up with another tester outside of my project to talk about my approach and bounce ideas off - it's always been useful for me to talk and justify my approach with someone I trust, and I often get ideas regarding fine tuning my focus.

There are a mix of people on a project though who you can get access to, and doing paired sessions with these people can be a great ways to exchange knowledge and values with.  Pairing up with these people for brief testing sessions where you demonstrate the system to them can be an enriching experience.

Here are some typical people you can look to pair up with, and what they can offer you,

Admin users - they may be in-house or customers.  Especially on legacy projects where you hear the words "not everything is documented", these people are a Godsend.  They usually belong to cultures where their knowledge is passed on verbally admin-to-admin as they are mentored in the system - often they know the obscure business processes that make the current system tick.  Spending time with them allows you to understand the key processes which keep the system ticking over.  Likewise when you have new functionality, they can really help to zero your time in on the pieces around it that would impact the business if they didn't work.  This can help you to focus your testing time on high value areas.

Business Analysts - they are quite literally living requirement oracles.  Except having been on the meetings that shaped the requirements, they understand the "whys" regarding the importance of key features. You'll learn a lot about your customer through them, "oh Karen asked for this because currently when they do X, they have to do Y first to activate it, and it takes them extra time to do so".

Marketing - an interactive session with marketeers helps them to understand how the system works, which helps them tighten down on how to promote features, as well as think about future enhancement.

Project Managers - a session with them will often help to shake out key concerns from the steering committee they report to, including potential horror stories from the past.  "Mark is worried that X might happen" or "last year they had problems when Y happened and brought down the system".  This allows you to be aware of areas where there are concerns, and make sure you're comfortable about how your testing is addressing them.

Junior Testers - paired sessions are a great way to coach junior testers.  Putting them in the driving seat gives them the opportunity to take the initiative, and to explain their approach.  It allows you the opportunity to suggest additional tests they might want to consider, or give feedback about what tests might be more important to run first.

What do they get from it?

Sharing is a two way experience.  Whilst they share these values with you, you're sharing yours with them.  Namely,

• Demonstrating what you're testing, especially new functionality
• Showing the methodology you use to test features in the system
• For admin users - helping to train them on how to use new features
• For business analysts and marketing - demonstrating how their requirements and requests Frwere realised
• For project managers - feeling engaged and involved in the testing being performed
• For junior testers - coaching

How do I know if I'm pairing or doing a demo?

This is an important distinction to be aware of.  If you're sitting with someone, and one of you is controlling all the conversation for the whole session, then you are not pairing.

Pairing is an interactive partnership.  There is a certain level of inquiry and challenge, without feeling of threat or accusation.  This is important - another party is essentially reviewing your testing as you perform it, and it's important to respond to these comments.  Some of this feedback may suggest other tests, which if feasible you should attempt to include.  [Sometimes if your session has a goal, and the suggestion would take you off topic, you might want to leave it until the end though or schedule another session]

If you're exercising your testing, or guiding your pairee and they simply don't respond, then you're not pairing - you are essentially demoing.

Here are some potential areas of challenge - notice that most of them suggest areas for extra tests, which if easy to accommodate you should include,

• "You used a keyboard shortcut - I didn't know that existed - we're told to use the icon to launch".  Extra test - show them the system launched via the icon, and teach them the shortcut.
• "The server admin machine is ancient and still has a Netscape browser, did you check this screen is usable in Netscape?"  A potential additional test, maybe using an virtual machine of an older operating system.  [Although then again likely to need some set up and investigation that you might want to return to it later]
• "You showed me a currency transaction in Yen, but 95% of our transactions come in US dollars, Great British Pounds or the Euro - did you cover them?"  Possible here to either show them, or show them results where you did.  But they're trying to make sure you covered the test conditions which are most likely to occur.
• "That looks different to our current system - I didn't think this page was changing?"  Could be worth chasing up with your BA if you don't know, otherwise fill them in on the change.

It's important to take these things in the spirit of pairing.  If you're challenged and there's something you didn't think about, don't go on the defensive, but instead realise it's valuable feedback you've got, and the whole reason why you're spending time doing this.  If you think a suggestion is genuinely (and I mean this) unhelpful, try and explain as tactfully as possible - but remember your goal here is to influence, to win them over to your side, not to make them feel stupid.

One example of this was a project a few years ago.  We had just 12 options our customer could choose to add to our product when they set up an account, and they followed the below rules,

• The customer needed to select at least 1 option
• The customer could select options in any order
• The customer could select up to all 12

My business owner wanted me to be sure that I covered ALL options.  If you've read The Elf Who Learned How To Test, you know how much I warn about ever saying the word ALL.  I spent some time explaining how permutations worked in mathematics, and showed them some of the different ways you could arrange 12 products etc.  I then worked through an Excel spreadsheet to show them how many permutations of product there were - the number was something like 100 billion.  Their mouth fell open, because they had no idea when they said "all permutations" it actually meant so many.

At this point, I talked to them about what I had done,

• Gone through the Business Intelligence for the current system.  About 80% of people had just 1 option.  Then about 18% had 2 options.  Less than 0.25% had 3 or more.  Hence I did a lot of testing with 1, 2 and 3 options.
• I had covered some scenarios where all 12 or just 11 options had been chosen.
• I had tried out different option numbers each time I did exploratory testing, and not found any issues thus far.

I have to thank James Bach's Rapid Software Testing course for this kind of engagement with non-testers, but it helped a lot to make what I was spending time on more understandable.  I was very open to suggestions of distinct scenario, usually phrased "what about when ...", but I never tried to deceive them that ALL options were going to be tested or even achievable.

When this level of engagement is done well, it helps others to understand the challenge and skill of testing because it makes testing visible.  When it's not then typically organisations often find themselves believing that "they have a testing problem - that's why our products are late / have bugs".  Don't be that organisation.

Onwards ... to 2014 ...

Every company that I've ever worked for has operated a closedown period over Christmas to New Year, and my current company is no exception.  It's always nice to have a good solid break.

Coming over to New Zealand, this break now coincides with summer here - which usually is a lot of fun.  I usually make a list of things I want to do with the family - walks in the Rimutuka forest park, bodyboarding off the Kapiti coast, cycling, beach trips, fishing.  This year alas the weather has been foul, and I'm not seeing a single tick on my list of things to do.

As always the day before going back is an odd and reflective day.  Slightly melancholy as you realise your break is winding down (although resolve to take a long weekend if the weather improves), together with some excitement about what the year ahead will bring to work.

If this break has been a failure as an activity holiday, it's been a huge success as a reading one.  This is hardly a surprise - even as a teenager my parents would take us on holiday to Spain, and I'd often be found with my head in a science fiction book of some description.  Often I would be too fixated on the Isaac Asimov robot tale I was reading to even notice I was on a beach full of topless women sunning themselves.  I guess you could say I was a late developer in that regard.

These days of course, Google is my friend, and the internet fascinates me as I can follow whatever interests me.  I've been watching a couple of documentaries with my son, and often am to be found entering key names into my Kindle, and searching out back histories on various events and characters.  It's a very learning rich environment, although of course anything you read on the internet can be fallible  Thankfully though there are a host of resources on the internet, and you develop a sense for those pages which are just a cut-and-paste job from a Wikipedia article.  (Navigating bias in online sources of information is always a challenge, but then in this age, where isn't?)

I also got to introduce my son to the Marx Brothers.  When I was a kid growing up in the 70s and 80s, the Marx Brothers movies were never off the screen - they were a comedy act who moved from the stage to produce a number of "talkie" films in the 30s and 40s.  Sadly their movies have fallen out of favour simply for being in black and white, and many TV stations just don't show their films any more - least not in New Zealand.

This is one of their most famous comedy sketches - the mirror scene in Duck Soup.  I still remember watching it for the first time with my dad after he was recovering from a bout of hepatitis C.  We almost had to take him to hospital, he was laughing (and consequently not breathing) so much.  Every time he'd regain his composure, something else would happen to set him off again ...

For back story, several characters have dressed up as Groucho Marx to steal some vital war plans.  How can you hide in plain sight?

After watching, I did indeed read up about the lives of relative members of the Marx brothers on Wikipedia. It  fascinated me though, and I ended up buying the book Harpo Speaks on my Kindle about the silent Marx brother, and it's really had me musing on the upcoming year ever since.

The Marx Brothers didn't start as a comedy act.  They were a singing act - mainly a vehicle to help one of the brothers, Groucho, get into vaudeville.  They were semi-successful, being just about able to pay the bills.  They were all young teens, and found doing the same routine day-in, day-out got a bit of a bore.  So they started horsing around on stage - and people loved it.  Bit by bit the act evolved and changed, with more and more comedy, and less singing.

The problem for Harpo was this - his brothers were both very strong characters on stage.  Chico was the "charming but dim-witted" Italian con-man, whilst Groucho was the fast talking king of the put-down.  Against this, Harpo struggled to make an impact, or even be heard.  His solution?  To go silent.

Harpo played on stage and on screen as the silent pantomime, only communicating through expression and the liberal use of whistling and honks on the horn he always kept in his belt.  But he stole the show with his physical comedy and clowning around.  Whenever he found something out, there would be a running gag of a ridiculous charades game to communicate it all.

What fascinates me most about reading Harpo's book isn't how successful he became, but all the things he tried and was unsuccessful at.  But the thing is, like with all the Marx brothers, he gave himself room to experiment.  If something worked, they kept with it, and kept it in the act.

An inspirational quote I found from the book came after Harpo reflected on his first time on stage, where dressed in a white suit, he was so struck by stage fright that he wet himself on stage ...

"Every turning point in my life seems to have been a low point, a time of terrible disappointment or disaster.  I never planned any changes in the course of my career.  The changes just happened.  The only ambitions I ever nourished were to be a left fielder for the New York Giants, a full-time tin-can swinger for an umbrella mender, or a piano-player on an excursion boat.  I never achieved any of these ambitions.  What I actually became was what I was driven to be in a time of disaster."

In the end the Marx Brothers became known for ad-libbing on stage.  Rather than play the same routine, copy-and-paste, for 2 years straight as they toured, they admit that they got bored.  And so they would enjoy mixing it up a bit, and would try out new pieces and routines.  If the audience laughed, it stayed in - such as the night Harpo disrupted one of Groucho's scenes by chasing a chorus girl across stage, honking his horn.  Not to be out-done, Groucho ad-libbed the retort "First time I ever saw a taxi hail a passenger".

I found this all reiterating itself as 2014 came around.  I'm signed up to receive Johanna Rothman's  Pragmatic Manager Newsletter, which offered some thoughts for the upcoming year.  She sums her advice for the year in three stages - experiment, observe, invite.

• Experiment and try out new things in what you're doing, over repeating last year's script.
• Observe whether or not it works.
• Invite others to get involved with the changes, and contribute.  Try not to mandate and force (because people always kick back when they don't feel involved).

It's superb advice - and really echoes my thoughts on the Marx Brothers.  We look back on the Marx Brothers as being a great success story.  But that depends.  If you mean "were the Marx Brothers, the vaudeville singers a success?", the answer is no, and that's the act they started at.  They experimented within their singing - they had music lessons, they tried different songs which played to their strength.  But ultimately it was the freedom to experiment and try comedy which led to their success, not as singers, but as comedians.

Success is always a matter of experimentation and context.  If you keep copying the past, hoping for a breakthrough for success, you'll always find yourself dissatisfied with what you achieve.  Give yourself the freedom to experiment and to try, and where possible to redefine your role.

Harpo's son keeps a website dedicated to his father's memory, which you can view here.

An awfully big adventure - reads in 2013 ...

With moving to Datacom and taking on the title "test manager" instead of "senior tester with some test leadership", so began a new chapter in my career in 2013.  One that when I started in the industry in the 90s, I could not have expected.

Like many people I got into the I.T. industry because I had a fascination with "technical stuff".  Despite having worked as a teacher, so called "soft" or people skills were not my strengths.  But over the almost 18 years I've been involved in I.T. it's become clear that making software is not a lone wolf's role, but a team endeavour.  Developing those soft skills and an understanding of people is key to developing yourself.

There follows a list of books I've read and really enjoyed in 2013, and a brief explanation of why I found them so influential.

Behind Closed Doors - Johanna Rothman and Esther Derby

I actually bought this book on a whim at the beginning of the year, and didn't really expect to find much from it.  But I really enjoyed - in fact it's become my Bible in many ways, and I find myself referring to it a lot on a day-to-day basis.

The book uses a fictional narrative, talking through the arrival of a new manager and the various problems he encounters, together with how he addressed them.  And then goes on to explain the reasons for those actions.  It's a great way to learn - almost learning done as gripping soap opera - and a device used both in my own The Elf Who Learned How To Test and another recommendation on this list (The Five Dysfunctions of a Team).

It's a great method to use for books - it's very easy to do the theory, but create a fictional setting and it gives the theory context.  It also can make for uncomfortable reading, because we all of course recognise a similar situation we've been in ourselves.  Even one where we've been the more unreasonable individual.

This book really sold me on the importance of  private one-on-one meetings as a method of reporting to your manager, and ways to keep in touch with those who report to you.  Before this I would "get this", and spend time at their desk to direct reports to find out how they were doing.  But you need to take people away from where they work, somewhere they can be more open to speak.  The one-on-ones are a method of really getting people to open up, and sometimes challenge/mentor them.  Doing them in private means no-one has to lose face in what you cover.

It also helped me refine my technique - I tend to be a big talker, and I've learned that I need to stop feeding people in meetings with what I say, but listen more, and give them more room to talk.  This echoes a book I'm reading at the moment about Harpo Marx, "Harpo Speaks".  In it he says about the many people he's spent time with, both the great and the small.  Unlike his brother Groucho who was the one with the quips who was the life and soul of any party, Harpo attributes his success socially to the fact he listened, and because of that people were comfortable in his company.

This book taught me to be more like Harpo and less of a Groucho when having my private meetings.  It also taught me a valuable lesson about organising my tasks.  I might be a Test Manager, with a bit of management and a bit of testing - and yes I can still (and do) test.  However when push comes to shove and things get tense, my group has only one manager, and the management role has to take priority.  Because of this, any testing I do needs to be the "less critical pieces", because when things get tight and I need to focus, I need to do so on management role.  If I have critical work assigned to me, then both I and the team will fail - because either the critical work won't get done, or the team will be without a manager and have to fend for themselves (and despite them being quite self-organising, this would be another distraction for them).

The Five Dysfunctions of a Team - Patrick Lencioni

How I came to read this book is a tale in itself!  I shared a one of my posts on how Les Mills instructors are mentored with the manager of Hutt City gym, Mid Thomas.  It seems that she was behind the introduction of the model they use, and is a bit of a guru on mentoring and feedback.

Even though we're in very different fields - I.T. versus the fitness industry - at the end of the day we're managing people, and the people factor means there is a lot more commonality than you'd at first expect.  But then, people are people.  Shakespeare's plays are still popular today because although the world and language has moved on considerably since Elisabethan times, the motivations of the characters still apply.  People still fall in love across cultural divides (Romeo and Juliet), are still manipulated through their jealousy (Othello), and those swayed by flattery often follow it with tragic consequences (King Lear).

Much like Behind Closed Doors, this book follows a similar pattern, telling a tale first, and then analysing the behaviours within.  It's not a long book, but I just couldn't put it down.  Though I felt Behind Closed Doors is more comprehensive and detailed in the overall office relationships, The Five Dysfunctions really focuses down on a smaller aspect.  But this works because by focusing, it really creates a cracking read.

I found overall by the end that I probably followed about 80% of what this book suggests.  However I pretty much dealt with it on a case by case manner, whereas this offers a continuous model of values to hang and fit your behaviour and the culture you're trying to build within your team with together.  That is a culture of trust and challenge.  You need the trust and relationship to be able to challenge others in your team, without it becoming a threatening experience.  This it turns out would be something I spoke at WeTest about in Managing Management Relationships.

Hiring Geeks That Fit - Johanna Rothman

In the past I've recruited contractors when we needed them at Kiwibank.  The great thing about contractors, especially when provided through an agency like Qual IT is that if they don't really fit or work out, you can talk to the agency about replacing them.  I've only had a couple of instances of people who didn't fit, and even with contractors you try and work with them to help them fit into your group or organisations.

When you hire someone as a permanent member of staff, you're making a much bigger commitment.  You want to do everything you can to promote your vacancy in the right circles, and when it comes to hiring, although (and as someone who was interviewed myself it felt it) it seems unfair, you don't want to hire someone who "seems okay".  If you hire someone and they don't fit or work out, it's unfair to both yourself and the person you hired.

But at the same time, you need to be realistic.  We've all scoffed at the jobs which "talk about an entry level position ... ideal for someone with five years experience in the industry".  Erm.  The book talks a lot about how you need to hire for someone whose personality will fit into your team - this is something people tend to be unchangeable on.  However, don't be too hung up on skills - you can send people on training and add a skill if they're a general fit.  How do you get along with the person in the interview?  If you find you or them are having to explain themselves a lot to be understood, how will that translate into the office?  Will they fit in with the personalities you already have?

I've been involved more in recruitment at Datacom - you can find out more about our job opportunities here (please, though I love people getting in contact, don't send me your CV).  And once again, this book has helped to guide me through these initial steps into this area.

Other books ...

Those books obviously involved more "management" areas, but other books I've dabbled reading during the year,

Exploratory It - Elisabeth Hendrickson. I enjoyed this book on exploratory testing, and indeed it taught me a few new tricks, which I've incorporated.  It's a nice easy-read size, and much like Five Dysfunctions, I found I couldn't put it down as I went through.  One area I found lacking was about "how do you record and debrief from your sessions", but really this is something you need to find yourself having a dialogue with your customers and working out "what you need" over being hung up on recording too much.

The People's Scrum - Tobias Mayer.  Another addictive read, looking at the way people are using Scrum, and re-evaluating the spirit of scrum, and the principles behind it.

Perfect Software And Other Illusions About Testing - Jerry Weinberg.  Looking at common misconceptions non-testers have about the things we do.  This book has helped to prepare me for some of those difficult conversations.

Pirates In An Adventure With ... - Gideon Dafoe.  Oh, you didn't expect I only read text books do you?  Even these books with their blundering overconfident Pirate Captain have a lot to ponder on.  The pirate crew bump into a whole series of historical characters, and turn historical events on their head.  They're books for adults, but written in a readable and fun style.  Arrrrgh!