| Last week, I embarked upon the first paired testing session of my testing tour. As I’ve only done a couple of paired sessions in the past, I felt I needed to focus on the mechanics of this in my first session, so that I can decide how to best to structure future sessions in the tour. Therefore, I started my tour fairly close to home, in a team with a similar role and product set to my own current job. This minimised the effort spent getting my head around new context and maximised my focus on the effectiveness of the pairing. We set out to use strong-style pairing, with my pair as the navigator as he had the domain knowledge and context for the session, and me as the driver. I quickly learnt that the job is not done once you’ve agreed on a pairing style; it takes active effort throughout the session to stick to it. During the session, we hit a problem with the set-up that we needed to investigate, and it was whilst debugging this that we first slipped out of the strong-style pairing. At first, I tried to ensure we both stayed involved, but it was clearly much more efficient for the tester with familiarity of the test rig to debug. I have a general concern that during my tour I will be detrimental to my partners’ efficiency without adding sufficient value to offset this. Because of this worry, and as I couldn’t see any value in me driving the debugging, I let my pair press on with the debugging on his own. This became the first question I want to answer on my tour: how do we (or can we) add value to debugging by pairing? At another point in the session, our pairing broke down in a very different way. This time, it began with us straying into an area where I had more testing experience, and so I was able to contribute navigation ideas. We organically started switching pairing roles based on who had an idea (i.e. “I’ve got an thought, why don’t you try…”). This flexibility felt positive and we seemed to be making good headway in our testing. However, it began to lead to confusion over who was navigating and how we should progress. We found ourselves formulating test ideas together, which meant it was unclear who should drive them, and also both coming up with conflicting ideas of where to head next. I realised that I had not thought enough about how the session could work with role-switching, having assumed that I would remain the driver throughout. So, did I achieve what I wanted to with the first stop of my tour? I think so, yes. I learnt a lot about strong-style paired testing, and I’m very hopeful that the observations, lessons and ideas I gained will mean I’m better prepared to focus on other things in later sessions. I have since written an FAQ-style list to send to my future testing pairs in advance of our sessions, so that they know what to expect from me and what I am expecting from them. I plan to update it after each session, and will post ideas from it here (and perhaps the full list, when I’m completely happy with it). Overall, I’m glad I’ve had the chance to work some of these details out before I stray much further from my comfort zone! |
Stop #1: A lesson in pairing
Published
Georgia Bloyce 
Really interesting – thanks for sharing. I’ve never actually practiced strong-style pairing before so I’d imagine I will encounter similar challenges to yourself.
It could be worth sharing an early version of your FAQs with the community to contribute to them as well? Completely up to you though!
LikeLike
Thanks very much for commenting, Ali! Very encouraging to know people are reading.
I think I will share them, thanks for the encouragement. I sent them over to my next pair earlier today, including a request for feedback, so I think will wait for that and then think about posting.
LikeLike
Congratulations on having your first stop on your tour. I can really understand the questions you have. So I would like to share some thoughts.
When doing strong-style pairing I like to switch roles every e.g. 4 minutes, depending on how long it takes to actually execute a test idea. If an idea takes long to be tested, maybe have a longer interval. Changing time-based makes sure that both pairs can state their ideas. In many situations this can help to balance the powers.
Furthermore, if you have no idea what to do at all, it may feel difficult to be the navigator. Staying the driver in that case is one option. This will help you learn. The navigator has to explain what to do and why and the driver has to understand and do. This will help the driver to learn, because they is not only watching, but involved. They can set the pace. It is not about having the fastest result, but to take the pairing as a learning opportunity.
And why not also be the navigator in case you have little ideas what to do? I guess you will have some ideas and your pair will understand where you stand and, hopefully, support you in your learning.
LikeLike
Thanks for your response, Thomas!
Using a timer to switch sounds like a really interesting idea to balance the session. Currently, all the tour stops I have planned are on products that I’m not very familiar with, so I was planning on staying as the driver and, exactly as you’ve described, making the most of the tester who’s experienced in the area to guide my learning.
Your comment and my experience in my first session has made me realise that although being the navigator on a new product might seem intimidating, I will have some good test ideas and add some value in that role. I might try starting the session as the driver, but adding checks into the session (maybe after 20 or 30 minutes) to evaluate whether I’ve gained enough context to begin taking turns as the navigator.
Thanks again! I look forward to updating you on my progress in navigation.
LikeLike