Lifes a Riot Resources



Links to the “Lifes a riot with Stubs, Fakes, Spies & Mocks” Repos


Useful LInks
Use JSON generator to create some example data.

Useful resources on POSTMAN


Life’s a Riot with Stubs, Fakes, Spies, and Mocks

I’m delighted to say I’ll be delivering a workshop with Ash Winter on Stubs, Fakes, Spies and Mocks. Our first workshop will be hosted by the Ministry of Testing at Testbash Brighton on the 15th March 2018.

You’ll find the abstract below and can view event information on the Ministry of Testing website:

Life’s a Riot with Stubs, Fakes, Spies, and Mocks

Ever wished you had more control over third party API responses? Have you been unable to test specific API responses? Perhaps you’re trying to improve the stability of your automation suites? Have you just started writing unit and integration tests? Maybe you’re building a client for an API that hasn’t been built yet, and you want to get testing earlier? Facing these challenges, mocks, stubs, fakes and spies are essential to testability and can be used both in your automation and as a tool to aid you in your exploratory testing.

In this workshop, the group will explore mocks, stubs, fakes and spies. You’ll come away with ideas on when these techniques are appropriate, how to gradually build up features in the tools you create to mimic services and you will know just how quick it is to go from idea to working tool. Some programming experience is preferred, but anyone who has an interest in testability will find the workshop rewarding.

Key takeaways are:

  • Recognise the common terminology used in the stubs, fakes, spies and mocks domain
  • Understand the difference between stubs, fakes, spies and mocks through their characteristics and use cases
  • Apply this foundational knowledge to build a gradually more featured tool to illustrate the journey from stub to fully fledged mock

The systems we test are massively integrated with many different data sources, and this is only going to increase. With the ability to mimic key services, your dependencies won’t be the bottleneck that stops you from delivering information of value, early and often.

Leeds Testing Atelier October 2017

It gives me great pleasure to sponsor the Leeds Testing atelier for the second time this year. I lived and worked in Leeds for a year at a time when the testing community was just starting to take off, and it’s fantastic to see it thrive over the last few years. I believe in the people behind the Leeds Testing Atelier and love their Punk / DIY approach to conferences.

The Atelier will be on the 17th October @ the Wharf Chambers in Leeds. It’s free to attend and includes food and drink (including craft beer!). Details, including the fantastic lineup, can be found here.

Register today and come along and say hi.

Testing Requirements – Mentoring at the Software Testing Clinic

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.

It came as a surprise to the mentees I worked with; that I consider a person’s influences and biases. I do this as I firmly believe it is important to keep in mind that each and every one of us has a different model of the world and to consider this when trying to seek clarifications and to establish a common understanding.