the barefoot tester

Throughout my career, I’ve had the opportunity to lead teams and to mentor testers. Mentoring is a role I particularly enjoy but until recently, I had not focused any attention on developing the skills involved. My mentoring sessions are usually with someone relatively new to testing and/or someone who has worked in a single company with limited exposure to testing outside of their company’s context. Often the mentoring happens naturally as part of everyday work and I’d like to be more intentional. I’d also like to be mentoring a wider range of students with different levels of experience and so, I recently mentored at a session on Testing Requirements at the Software Testing Clinic.

The Software Testing Clinic is a free event held regularly in London, started by Mark Winteringham and Dan Ashby, the Clinic is designed to be a platform for testers to expand their knowledge by pairing groups of students with mentors and working through tasks. They are a great opportunity for anyone new to testing or who wants to improve as well as more experienced testers who want to give something back to the community.

The lesson plan for the session can be found here.

Alan Parkinson lead the group through the following exercise to demonstrate the pitfalls:
Working in pairs, each pair should be made up of a product owner and a tester. Separate the testers from the product owners and give each product owner an abstract line drawing. The product owners have 5 minutes to write down instructions for the tester to illustrate a copy of the drawing. The tester will not have access to the original image.
Give the exercise a try and you’ll see just how hard it can be. For info checkout Alan’s blog,

The first practice session saw the whole group tests a user story, (see the lesson plan) and was largely down to the mentees to carry out the questioning with the occasional suggestion from mentors. I won’t go into detail here as I want to cover two things; my approach to mentoring a small group, and my approach to testing requirements.

The second practice session we broke off into smaller groups made up of one mentor and 2-3 mentees
I had the pleasure of working with two mentees, both had been testing for around three years and had some experience with testing requirements. I started the off by giving them a story on timesheets.

As an accountant
I want personnel to be able to record time worked on projects
So that I can keep track of time spent on projects

I wanted to see how the group approached the task so I held off giving any prompts, or suggestions to begin and let the mentees approach the story as they pleased. The group decided to take this opportunity to use Six Honest Serving Men (Who, what, where, when, why, and how) which had been introduced by Tony Bruce during the first practical exercise of the evening and to capture the Information in a mind map.
I waited until the questions slowed before asking the group how they’d usually approach a task like this. When one of the mentees said he’d usual ask more technical questions, I suggested they take a look at the mnemonic, SFDPOT . SFDPOT stands for Structure, Functions, Data, Platform, Operations, and Time (see Product Elements in the James Bach’s Heuristic Test Strategy Model). I suggested they use this to cover technical lines of questioning (Structure, Data, Platform for example) but also behaviour such as what the software can be used for and should it do (Operations and Functions)

Next, I went on to talk about what I might do on top of what had already be covered. In particular, I spoke about references, what existing products or materials can or should we reference; and influences & inspiration, where I’d consider what is the inspiration for the product, what inspires and influences the product owners. I’ll probably only have a shallow understanding if any, but this information can be valuable as it can help you understand where the product owner is coming from, and what they might be envisioning.
At this point I introduced the mnemonic FEW HICCUPS to highlight over oracles which can be considered, in particular, I highlighted the History, Image and Comparable products as these can provide additional resources which in turn can be used to generate more questions or to narrow in on a particular requirement.

The above follows my usual pattern when I begin mentoring someone new:

1. Find out where the mentee currently is and what approach they take.
2. Suggests techniques and resources to expand on what they know which complement their preferred method.
3. Recommend resources and techniques outside of what they’d usually use.

Before the session, I took a little time to think about my approach to testing requirements and captured some notes in a mind map. Here are some of the thoughts I noted before attending the session.

Depending on the type of requirement, I ask different questions or use different heuristics. For instance, it may be easier to capture desired behaviours in written form, and it can be a little easier to get to iron out assumptions when seeking clarifications. For visual & design elements of requirements it can be hard to obtain clarifications verbally or through text and unless the product owner has sufficient artistic skill, you’re relying on them to communicate their requirements to someone to bring to fruition. What one person sees when discussing a visual can be subtly or drastically different to another.

Who are you your users?
Who are the intended users and who is requesting the feature? Sometimes these are two sets of different people the more you know about both, the easier you’ll find it to deliver something that satisfies both parties.

Who is involved?
Do you know everyone who has input on the final design? Identify missing people such as specialists or subject matter experts

What information is already available?
Beyond who is involved and who the intended users are it can be important to gather as much information as possible. Identify resources that can help you such as Wikis, documentation, design & accessibility guidelines, industry standards, even other projects that are similar or overlap in some way. If you’re working with third-party APIs, be sure to take a look at the documentation

Dependencies & impact
Do the requirements rely on any particular data or state? Where does it fit in different user journeys and what impact could it have on existing behaviour and is it intentional?

Model the system to drive questions
When testing requirements, the sooner you get something down on paper, the better. Sketching UI elements and layouts, modelling interactions on and capturing examples all are great ways to generate new questions and drive out ambiguities.

How well do you understand the requirements right now?
Do you know the requirements purpose, is it similar to something you’ve worked on before? What don’t you understand? You might not get all the information you need straight away and time to digest the information can be valuable.
I ask myself this questions throughout the development lifecycle. The more I work with a requirement, the greater my understanding of the requirements purpose, it’s impact on a system which in turn, uncover things unknowns, questions I need to ask and scenarios to highlight.

Closing remarks
The Software Testing Clinic provided my first time consciously mentoring strangers so there was little time to build rapport. I’d usually spend time building a relationship over days or weeks, seeing what the mentee responses to, and how best to approach them as a coach so it was interesting to mentor someone I’d just met. Knowing so little about the mentees highlighted to me that I need to work on general explanations as I’d normally use the domain or business to tailor examples. I hope both mentees enjoyed themselves and learned something during the session and I provided links to the mnemonics we discussed and suggested further reading materials such as Exploring Requirements and User Stories Applied.