Are you really Coaching?


I recently read “Brilliant Coaching” by Julie Starr. The book explores practical ways you can apply Coaching in the workplace. She provides great examples how you can apply a Coaching style moving from Directive leadership to empowering others(Self Directed)

In the book Julie presents a model; the Scale of Influence. This can be used as a model to build self-awareness in your Coaching conversations.


Scale of Influence: Brilliant Coaching, Julie Starr

In a Coaching conversation we may use different levels of influence but we want a good coaching conversation to be more self-directed (left of hand side of the model). In particular Julie recommends that new coaches should try to avoid giving advice or instruction at all.

I’ve recently started using this model to reflect upon the conversations I have with people around me. It has helped to identify times where I could have taken a less directive approach.

As many of my blog readers are Testers I’ve translated what the model might look like in Testing context. For example a conversation between a Tester and a Developer on deciding how to test a particular User Story.


This is a good way to reflect upon the conversations you have with people and understand “Are you really Coaching?”

Next time you are engaging in a Coaching conversation use this model and reflect:

  • How often do you tell someone else what to do?
  • How do you feel listening to someone share an idea when you think there is a better approach? How often do you follow with an opinion rather than asking further questions?
  • When you feel you are the expert, how often do you refrain from sharing advice and ask a question instead?
  • How does silence make you feel?

5 Books about Coaching


A common question i get asked is “What Coaching books do you recommend?”

Here is a short list of some Coaching Books i’ve read and some that are on my reading backlog.

1. Coaching for Performance: Growing People, Performance and Purpose


What i liked?

  • This book explores the popular GROW Model
  • There are some great chapters about crafting good goals
  • Explains well what Coaching actually is
  • For many this is the go-to book about modern coaching techniques. A best seller thats been around for many years.

Recommended for: Anyone new to Coaching


2. The Coach’s Casebook: Mastering the Twelve Traits that Trap Us

41+I4lOgqEL._AC_UL320_SR216,320_What i liked?

  • Very practical examples of coaching conversations
  • Real Life Case Studies from high profile and famous figures
  • Easy to relate to (I often found personal examples in each of the traits)
  • Promotes Coaching Supervision which was a concept that was new to me until i read this book

Recommended for: Scrum Masters (Co-Author Geoff Watts also Authored Scrum Mastery)


3. Time to Think: Listening to ignite the human mind

1020273 (1)

What i liked?

  • This book has had a dramatic impact of my coaching approach
  • It will fundamentally challenge you
  • Excellent examples and well written
  • Case Studies towards the end of the book of how to apply the Thinking Environment are very interesting.

Recommended for: People involved in organisational change



4. Coaching Habit: Say less, Ask more & Change the way you lead

Coaching-HabitWhat i liked?

  • Simple and accessible introduction to Coaching
  • Suggests some power Coaching questions such as the AWE question
  • Techniques can be applied straight away
  • Does not promote a rigid process but looks at how coaching can be built as a habit in everything you do

Recommended for: Managers



5. Art of Coaching


What i liked?

  • Visual!
  • Covers many core coaching concepts but using visual aids
  • Provides great inspiration of how to apply visual techniques to coaching.
  • Techqniues for both individuals and the team

Recommended for: Experienced Coaches looking for new ways to engage clients



Some more books on the backlog:

XP2016 – Does the Test Automation Pyramid matter and who really cares? – Panel Discussion


At XP2016 there was a panel discussion focused around the “Test Automation Pyramid”


The discussion was facilitated using the “Fish Bowl” technique. The starting panel was:

Left to Right: Elisabeth Hendrickson, John Fergusson Smart, David Evans, Simon Brown, Steve Freeman

The discussion kicked off with the following are questions:

So what did we talk about?

The 90 minute discussion covered the following:

  • All models are wrong, some are useful
  • Does it matter? Maybe
  • Who cares? Not sure
  • It sucks because it ignores other types of automation that support testing. Automation can extend beyond Units, Integration and UI. I thought of Richard Bradshaws comments about “Automation in Testing”
  • The Exploratory Testing bubble that is sometimes placed on the top is stupid
  • What is the definition of a unit? No real clarification here
  • What is the the definition of an Integration Test? Tumble weeds……
  • People treat items higher up the pyramid as second class citizens. Tests at the top still add value although the feedback is traditionally slower
  • Pyramid can sometimes be used to assign responsibility. Testers focus on the top(E2E), developers do the bottom(Unit), someone somewhere does tests at the middle (Assuming they know what an Integration Test is)
  • The pyramid is based upon an old “3 tier architecture” model where the Front End was difficult to test and could only be done using “In Browser” tools such as WebDriver. In todays world, this is not the case. With front end frameworks such as AngularJS the front end can be broken down into Unit Tests.
  • What is Testing? Talked about the difference about Testing v Checking. Most of the discussion was about Checking but we should also think about Testing which is not currently part of the Test Automation Pyramid. The Pyramid is not about testing.

  • Uncle Bob Martin talked about how the Test Pyramid is commonly inverted, with most of the business rule tests implemented through the Front End.
  • There was talk about “Plumbing” and the Test Automation. I forget what we discussed exactly.
  • Did the Test Automation pyramid come from the “Food Pyramid“?


  • The focus of the discussion towards the end of the panel discussion moved into documentation
  • Uncle Bob Martin compared a well written code based to an “Encyclopedia”; It contains a robust collection of state transitions but its hard to search.
  • The Test Automation Pyramid exists because we like to talk in Metaphors.
  • Final comment;
    • Horizontal axis = Amount of Tests
    • Vertical axis = Amount of Pain

Thats me ^

So….what do you think? Leave a comment below.


How to do Example Mapping


A few months ago i came across Matt Wynne’s post about Example Mapping on the cucumber blog. During XP2016  I attended Matt’s Example Mapping workshop. I’ve been using the technique with teams for a few months now. This post will share what Example Mapping is and some of the experiences i’ve had using it.


What is Example Mapping?

Here is the process taken from the Cucumber blog:

Example Mapping uses a pack of 4-coloured index cards and some pens to capture these different types of information as the conversation unfolds. As we talk, we capture them on index cards, and arrange them in a map:

We start by writing the story under discussion on a yellow card and placing it at the top of the table.

Next we write each of the acceptance criteria, or rules that we already know, on a blue card and placing those across the table beneath the yellow story card.

For each rule, we may need one or more examples to illustrate it. We write those on a green card and place them under the relevant rule.

As we discuss these examples, we may uncover questions that nobody in the room can answer. We capture those on a red card and move on with the conversation.

We keep going until the group is satisfied that the scope of the story is clear, or we run out of time.

And that’s it. I told you it was simple!

How I’ve used it?

Teams I work with follow a simple principle called “Three Amigos”


We apply this to our story conversations ensuring that in each conversation we have:

  1. Someone who knows the problem domain (Usually a Product Owner)
  2. Someone who can technically implement (Usually a Developer)
  3. Someone who can critique the product/solution and think laterally (Usually a Tester)

Usually that results in 3 people but it could be more. We want enough people to have a good conversation.

Our Three Amigo conversations happen in two ways:

  1. Formal – A scheduled session run three times a week. In the calendar at a set time. Voluntary session where the team self-organise and decide who should attend. These sessions last maximum of 30mins.
  2. Informal – Conversations at someone’s desk where a small group gather to discuss a particular feature/story.

It is during these Three Amigo Comversations  that we use Example Mapping.

Benefits I’ve seen with Example Mapping

Benefit #1 – Getting past the first Question

Often during Three Amigo conversations i’ve found that teams struggle to get past the first question. When a difficult question arises the team get stuck on that one question. To overcome this we use the Diverge/Merge/Converge technique with Example Mapping. This allows us to get all our current understanding on the table first. We structure the conversation as follows:

  • 0 – 5 Minutes – PO/BA presents the story and potentially a handful of rules. Just enough information to start a conversation.
  • 5 – 10 Minutes – Individual Brainstorming of Rules(Acceptance Criteria), Questions and Examples.
  • 10 – 30 Minutes –  Discuss

Benefit #2 – Colour Heuristics

As the different elements are colour coded it is very easy to use this as a heuristic for the readiness of the story. For example:

  • Lots of Blue (Rules) story is too big
  • Lots of Green (Examples) might mean our rules are not specific
  • Lots of Red (Questions) might mean we don’t have clarity or there are too many unknowns

Benefit #3 – Knowledge Capture

Often in less structured Three Amigo sessions you can have really good conversations but there is a risk that the knowledge is not captured. In this process you have those great questions and examples captured.

Benefit #4 – Rules not Specifications

I’ve often seen teams write their acceptance criteria as designs or technical specifications. Example Mapping reinforces Acceptance Criteria as Rules. This leads to better examples and ultimately better stories. I’ve seen this be a particular challenge for some teams. If the Acceptance Criteria is written as Specifications its much harder to find good examples which aren’t tied to the technical implementation. Ultimately this process helps you get much better Acceptance Criteria.

Benefit #5 – It’s fast!

Prior to implementing Example Mapping for our Three Amigo conversations our sessions used to be an Hour long. We have now reduced the sessions to 30minutes but run them more frequently. The team finds short, frequent sessions better than longer less frequent discussions.

Benefit #6 – It supports remote teams

We have run the example mapping session digitally. Sometimes we have team members who are out of the office so we use a virtual post it note board.

Benefit #7 – Example format

Sometimes people get lost in the syntax of Examples. Given/When/Then can force people into a certain thought process. This approach allows people to declare their examples in a simple way.

Share and Visualise

It is also important to socialise your conversations. As Three Amigos is a subset of the team it’s important to share any key findings with the rest of the group. A good way to do this is to post your example Mapping sessions on the wall next to the Scrum Board. This way the team can keep track of the conversations. If you have a remote time simply sharing the link to the virtual whiteboard is a good way.

What happens next?

Typically we want to make the decision – Is this story ready? The main driver we’ve found is Questions. Do we have outstanding questions that mean we cannot proceed. It’s fine to have  some questions open if you are confident they won’t impact your ability to proceed in the Sprint. To aid this process a simple Roman vote can help the group decide if the story is ready.

For more about Example Mapping head to the Cucumber blog here

Mocking a RESTful API using Nock, Supertest, Mocha and Chai


In my previous blog i explored “Testing a RESTful API using Supertest”

In this post i will look at how an API can be mocked using a node package called nock.

Mocking API’s can be incredibly useful for a number of scenarios:

  1. You want to test different responses easily
  2. You want to mock a third party system which you don’t control
  3. You want to simulate some negative scenarios such as a system being unavailable or responding unexpectedly.


In this example we’ll be using the following:

  • nock – “Nock is an HTTP mocking and expectations library for Node.js. Nock can be used to test modules that perform HTTP requests in isolation.”
  • Supertest – “High-level abstraction module for testing HTTP”
  • Mocha – “Mocha is a simple, flexible, fun JavaScript test framework for node.js and the browser”
  • chai – “Chai is a BDD / TDD assertion library for node and the browser that can be delightfully paired with any javascript testing framework.”

Mocking an API

nock allows you to intercept an API call and respond with a programmed response. The documentation on npm is excellent. It provides many examples of how it can be used from simple responses through to the more complex.

I will be mocking the following API – Post Code & Geolocation API for the UK.

Mocking a simple response

Here is a simple example that returns a 200 OK and a simple JSON response

var nock = require('nock');
var request = require('supertest')("");
var expect = require('chai').expect;
describe("Testing API with a mocked backend", function () {
it("returns a successful mocked response", function (done) {
//specify the url to be intercepted
//define the method to be intercepted
//respond with a OK and the specified JSON response
.reply(200, {
"status": 200,
"message": "This is a mocked response"
//perform the request to the api which will now be intercepted by nock
.end(function (err, res) {
//assert that the mocked response is returned
expect(res.body.message).to.equal("This is a mocked response");

view raw


hosted with ❤ by GitHub

Simulating a Time Out

A good example where Mocking API’s can be useful is simulating a Time Out. Good for us is that nock provides this capability out of the box.

In the below example I’m simulating a 10 second delay.

NOTE: Mocha has a default timeout of 2000ms so you also need to increase the mocha timeout otherwise it will kick in before your mocked response completes.

var nock = require('nock');
var request = require('supertest')("");
var expect = require('chai').expect;
describe("Testing API with a mocked backend", function () {
it("returns a successful mocked response", function (done) {
//override the mocha timeout in this test to 60 seconds
//setup mocked backend for a specific end point
//simulate a 10 second delay
.reply(200, {
"status": 200,
"message": "This simulates a 10 second delay"
//perform the request to the api which will now be intercepted by nock
.end(function (err, res) {
expect(res.body.message).to.equal("This simulates a 10 second delay");

view raw


hosted with ❤ by GitHub

Mocking from a JSON file

To keep your mock responses organized you may want to store them in JSON files to enable reuse and reduce maintenance effort.

According to the nock documentation support should come this with the function .replyWithFile. I tried to use this but found that the body property was not populated in the response.

As a workaround i used node to read in the file and assign it to a variable i could then specify in my mock response.

var nock = require('nock');
var request = require('supertest')("");
var expect = require('chai').expect;
//used to read the JSON file
var fs = require("fs");
describe("Testing API with a mocked backend", function () {
it("responds with json file response", function (done) {
//read the json file
var contents = fs.readFileSync('mockedresponse.json');
//parse the contents and assign to a variable
var jsonContent = JSON.parse(contents);
.reply(200, jsonContent);
.end(function (err, res) {
expect(res.body.result.postcode).to.equal("SW1A 1AA")

view raw


hosted with ❤ by GitHub

The JSON file containing the mocked response:

"status": 200,
"result": {
"postcode": "SW1A 1AA",
"quality": 1,
"eastings": 529090,
"northings": 179645,
"country": "England",
"nhs_ha": "London",
"longitude": -0.141587597876975,
"latitude": 51.5010091564599,
"parliamentary_constituency": "Cities of London and Westminster",
"european_electoral_region": "London",
"primary_care_trust": "Westminster",
"region": "London",
"lsoa": "Westminster 018C",
"msoa": "Westminster 018",
"incode": "1AA",
"outcode": "SW1A",
"admin_district": "Westminster",
"parish": "Westminster, unparished area",
"admin_county": null,
"admin_ward": "St James's",
"ccg": "NHS Central London (Westminster)",
"nuts": "Westminster",
"codes": {
"admin_district": "E09000033",
"admin_county": "E99999999",
"admin_ward": "E05000644",
"parish": "E43000236",
"ccg": "E38000031",
"nuts": "UKI32"

view raw


hosted with ❤ by GitHub


The examples i have included are pretty simple but can be incredibly useful when testing an API. The nock documentation has a whole host of other examples including:

  • Setting and Reading Headers
  • Reading request body
  • Using regular expressions
  • Replying with errors
  • Filtering

I will definitely be exploring these features further.

What is coaching?


At the start of this year my job title changed to “Agile Coach”. I’d always thought I had a pretty good idea of what “Coaching” is and that i’d been doing it to some degree in my previous testing and agile roles. Now I was officially a “Coach” i wanted to explore it further. It’s been an eye opening journey.

Firstly lets look at Agile Coaching which Lyssa Adkins defines as:

“Agile coaching is really important because we have a bunch of crappy Agile happening in the world right now. Even when it’s happening fairly well, I just know that pumping up mediocre results faster was not really the main intention behind this way of working.

I think coaches are an integral part to helping teams get to astonishing results because it’s all in the interactions of human beings where that happens. There is no piece of it in the Agile framework that’s going to help you with that. Having Agile framework there and working well, it’s certainly going to provide the structure and the container within which that can happen, the boundaries. But there are so much more to do within those boundaries, so many more things to bring to the team, so many more ideas and things from different disciplines – things from conflict management and facilitation and teaching and mentoring and professional coaching and a few more.” [1]

If we look at this definition Lyssa clearly highlights the benefit a coach can bring to the Agile context. In particular helping teams apply Agile principles and practices more effectively.

Things get interesting though in the second paragraph – “interactions of human beings”. This opens up a whole new dimension to the “Agile Coach”.

Timothy Gallway author of the Inner Game defines “Coaching” as:

“Coaching is unlocking a person’s potential to maximise their own performance. It is helping them to learn rather than teaching them.” [2]

This was an eye opening perspective. When I reflect much of my prior experience has been around teaching. 

In my quest to get a deeper understanding of “interactions of human beings” i’ve been reading Geoff Watts excellent book: 

The Coach’s Casebook: Mastering the twelve traits that trap us.

In the book Geoff explores common traits within individuals that can often trap us such as Imposter Syndrome, Going to Excess and Cynicism. Geoff explains that with the right techniques individuals can harness these traits to become highly successful people.

Geoffs book has provided me with a valuable inisight to coaching and with each trait he provides Tools and Techniques to help harness the traits for good.

 I’m enjoying exploring “Coaching” at a deeper level even though I’m a little overwhelmed by the the small stack of books next to my desk.

[1] –

[2] –

Are you a Super Recogniser?


In 2015 I made a discovery; I have a super power. Unfortunately it’s not the power of invisibility, the power of ultimate strength or the power to fly. Actually, it’s not really a Super Power but if you’ll let me indulge, it does have Super in the name. My power is “Super Recognition”

Super Recognisers are the people who quite literally never forget a face, in possession of an extraordinary ability to recognise men, women and children they barely know.

Dr Josh Davis, a forensic facial identification expert from the University of Greenwich, is conducting a study into super-recognisers and their abilities.

“We have tested them on passport images taken 10 years [ago] and they are still able to recognise where they’ve seen faces before,” he said.

“We think super-recognition is nature, rather than nurture, but I can’t say 100%. People tend to emerge in their 20s and 30s, we’re not really finding any super-recognisers in their teens so far.” [1]

My “Super Power” was confirmed after taking a test by Greenwich University. The test presents you with an array of faces and you need to match them in a subsequent sequence of photos. Incredibly, I only got 1 answer wrong which suggested I may be a “Super Recogniser”

The results of the test were not really a  suprise. Since my early 20’s I’d always had a strange ability to recognise faces with incredible accuracy. For me, it doesn’t stop at faces actually, most objects and places I can quickly match to a visual memory.

A perfect example is travelling on holiday. We’ve all been in that situation, waiting with a few hundred other people in the departure lounge to board a flight. To the frustration of my partner, every time i travel with my partner I recognise faces of people I’d seen for only a few seconds in the departure lounge. On the return flight I’d be able to identify people who’d been on the same flight and sometimes even people who had been on a previous flight maybe the year earlier.

The UK Metroploitan police have been using “Super Recognisers” to fight crime:

New Scotland Yard deploys an elite team of 140 officers across London to try to capture the most wanted criminals.

PC Gary Collins is the Met’s top super-recogniser and has identified more than 800 suspects from photographs, CCTV and his time policing the streets.

His beat is Hackney, one of the capital’s worst areas for crime.

“Whenever an incident happens they’ll call me in and show me the footage straight away.

“I’ll look [at it] and say, ‘Yeah I know that person, I know him from this area or I stopped him on this occasion,’ and it’s just putting a name to the face.” [1]

Using the Power

I started thinking;

“Have I been using my “Super Recognition” power in my day job within the IT Industry?”

Most of my experience has been involved with Software  Testing which encompasses exploring software to discover important information for my employers and stakeholders. Part of obtaining information is recognising when something isn’t right. I do believe my super recogniser power has given me a slight advantage. A quick recognition of unexpected changes means I can obtain useful information quicker and more frequently. It also means changes potentially undetected by others might be picked up when I get involved.

In many cases, automation can be applied to check differences introduced to software in the same way facial recognition software can be used to detect faces. 

Super-recognisers are not the only tool open to the authorities when chasing a face.
The ever-expanding field of facial recognition software offers the mechanical alternative to human talent, the science against the art.

But which offers the best chance of catching the criminal, now and in the future? [1]

The Metropolitan Police have found human “Super Recognition” can be highly complementary to automatic approaches which matches my experience in Testing.

Thinking Differently

It’s quite common for people in the software industry to say Developers and Testers think completely differently. Whilst I agree and disagree with that statement I do believe that the power of “Super Recognition” does help in my day-to-day job as a tester.

With every super power, there are downsides of course. Now knowing my super power is likely to lead me more towards confirmation bias. In the same way superman doesn’t think “Can I still fly?” before he jumps off a building maybe I’ll forget to think “Have I recognised this correctly?”

Are you a Super Recogniser?

Take the test to find out here and compare your score to mine!

If you score highly you can take a longer test to really put your super power to the test!

[1] –

Toby The Testers Travels – Bangkok



Friday 20th – Monday 23rd November

So I’m doing a little tour around South East Asia and first stop was Bangkok!

Day 1

We landed surprisingly fresh after an overnight flight from London and after a 2hr taxi ride through Bangkok rush hour we arrived at our hotel, Eastin Grand Hotel. We picked the hotel due to the excellent Trip Advisor reviews, ranked #9 of 790 hotels.

After check in we wandered through the bustling streets of Bangkok and stumbled across a street food place. No idea what it was called but it was pretty good. The 60bat large bottles of Chang certainly helped.

Day 2

Up bright and early we caught the Chao Phraya Express Boat (15bat – pay on board) to the Grand Palace. We arrived at 9am as we’d heard the crowds can busy later in the day and the heat can be over bearing.
After hearing from a friend that he got taken to the “Fake Grand Palace” by scammer who told him the Grand Palace was closed luckily we didn’t have any trouble. Outside they have a loud speaker blaring out “the grand palace is not closed” so I’m not sure how he got tricked.

We took the short walk to Wat Pho to see the reclining Buddha and more temples. Compared to Grand Palace I enjoyed Wat Pho a lot more. The reclining Buddha was cool but the temples around it were awesome. Probably the best thing we did.

For lunch we visited one of the most popular Thai restaurants, Siam House, for Pad Thai(50bat) and more ice cold beer!
In the evening we headed to Ban Chiang which was amazing. Lovely restaurant and excellent Thai food.

After our meal we decided to checkout the famous Bangkok nightlife. Firstly we headed to the Sky Bar made famous by The Hangover 2. Safe to say, it’s one of the worst bars I’ve been to. The view is ok, but drinks are so expensive and everyone crammed in like sardines. Thailand has it’s share of scams but this bar is probably the biggest scam of them all!

After that we met some friends at a Craft beer pub for a drink(just the one as a beer was 400bat) and headed over to the very odd, Nana district. Very strange bars and what you would expect from Bangkok’s darker side. After walking around and grabbing a beer in the quieter bars we left.

Day 3

A little hungover we headed to the Bangkok shopping district, Siam Paragon, for some AC and relaxation. Whilst we were there we had some spicy Chicken Wings and all was well in the world again.

Feeling revitalised we went for a stroll around Lumphini park which is one of the few green spaces in this crazy city.

Back at the hotel we had a swim in the infinity pool for awesome views of Bangkok and a cool down from the heat.
Our last night we made a reservation at a Thai restaurant, Tealicious. An English guy called Tom runs this with his Thai family. Amazing food again, cheap beers and lovely setting. It seems you can’t have a bad meal in Bangkok!

To finish the night we decided to try another rooftop, Moon Bar at the Banyan hotel. WOW! This one was awesome. A 360 degree view, a live Jazz Band and lovely cocktails. This was so much better than the more famous Sky Bar.
That’s it for Bangkok, amazing vibrant city. I’ll definitely be coming back to eat well and party the night away again!

You cannot Automate a User Journey Test


Most Test Automation models describe User Journey tests as an important component. In the case of the most well loved model, the Test Automation Pyramid, you’ll usually find User Journey tests towards the top(as per below): B95IkAFIQAAxr2z

These are typically some form of end-to-end journey, usually automated through the User Interface, using tools such as Selenium WebDriver, QTP etc.

Why can’t you automate a User Journey Test?

Lets start by defining a User Journey:

User journeys tap directly reflect the thoughts, considerations, and experiences that people go through in their daily lives, beyond the web. Creating a user journey places a strong emphasis on personas and also merges the creation of scenarios and user flows. However, unlike user flows, hierarchies, or functional specs (which explain the interaction between a user and a system’s logic and processes), user journeys explore a user’s mental and lived “patterns, processes, and paths” and translate these into web-based experiences.” [1]


The important part of the definition is that a User Journey is a “mental” and “lived” experience. The journey is deeply linked to “emotions” and these emotions usually have a bearing on the users perception of quality. Within development teams most of our work is focused either on enhancing existing user journeys or creating completely brand new journeys with the work typically broken down into “User Stories”. When building user journeys the success to which we have met the users is needs is based upon:

  • Have we me the users goals
  • Have we understood their motivations
  • Have we alleviated some of their existing pain points
  • Have delivered something that matches their character
  • Does it enable the user to do what needs to be done

As delivering a successful User Journey is so important to many teams its no surprise that many teams look to maximise their testing efforts in this area with some looking to automation. However, as described the key success factors in a user journey are linked to Human Emotion. As it stands, these emotions cannot be encoded into an Automated Test(although in the future it might be possible[2])

Due to this we cannot automate a User Journey test. kobian_sadness_1429339c

Testing the emotions

As a tester some of the most valuable feedback we can provide is on an emotional level.

“Emotions and Feelings are signals. Look into what they’re signalling” [3] 

It is only through experiencing the journey on an emotional level, as human testers, that can we provide feedback on the ‘journey’. A difficult part of testing is to really understand deeply the emotions of people that matter.

– Who is the user in the journey?

– What is their character?

– What are their motivations?

– What are their pain points?

How well we understand the emotions of our users can be an important factor in the success of our testing. If we do not really understand our users on an emotional level we may overlook certain issues such as clunky navigation, slow page responses or misleading messaging.

A great tool we can use(and not, its not Selenium Webdriver) is Personas. These are a great way of “getting inside” the mind of the user. Most agile teams will be familiar with personas as they form part of most User Story templates:

“As Stewart i want to be informed when my loan is due to expire so that i can avoid hefty late return fees”

In my current team we spent alot of time breathing life into our Personas giving them interesting names, personal backgrounds, job titles, goals and objectives. One of our personas is “Sarah the System Admin”. These personas reflect our real user base. We also had “face time” with the users understanding their emotions when using our software. One of our teams even created baseball cards of their personas so it was even easier for them to remember all the ‘players’.

At BDD Exchange 2014 Jeff Patton encouraged the attendees to “Get out of the building, way out of the building” to see how real users interact with our software. A better understanding of user emotions can breathe life into what may be seen as mundane tests. It also allows issues to be discussed on an emotional level “I’m pretty sure Stewart wouldn’t be happy with this flow, he said he wanted something quick, if possible, 1 click” Unfortunately too often this form of ’emotional’ testing falls into a Usability Testing phase. In traditional Usability Testing we prepare a prototype to show the users, usually in an expensive ‘off site’ test center. Following a couple of feedback iterations the idea moves into a lengthy development cycle and once complete, we schedule another session to take the users through the ‘final’ solution. We then go through the development iteration again after we realise further changes are required. Often the gap between this feedback is too long for most teams.

As Testers we can infuse the whole development cycle with our user persona’s. We can ensure their emotions and feelings are considered l so that the developed solution is likely to be closer to the users ’emotional expectations’. As Testers we can do some of our best testing before a line of code has been written through testing paper prototypes, whiteboard designs and challenging assumptions around user expectations.

Many organizations are now realizing the benefits of this type of testing throughout the entire development life cycle. My previous company, Shop Direct Group, are somewhat trendsetters in this area. They have built an in-house customer testing lab located in the center of the office, bringing the customer to the heart of the development process, literally! [4]

Design Thinking [5] is also an emerging as a popular approach. In this the emotion of ’empathy’ is the start of the process.


If you are interested in understanding more about how our emotions influence us in testing, Stephen Janaway has a great slide deck exploring the topic further [6]

In all these examples human emotions are an integral part and Automated tests cannot provide this feedback.

So what can be automated?

Implicit to a good Customer Journey is at least an application that holds together. If i expect a 5 and i get a 2, or if the user expects the home page to be displayed after Login but they get a 404 Page, we can probably assume its not going to be a great Customer Journey. Automation can help in ‘checking’ our application is at least doing what we expect it to. James Bach differentiates these types of checks from testing:

“Checks are evaluations by applying algorithmic decision rules to specific observations of a product.” [7]

Although we cannot automate a User Journey Test to evaluate the emotional aspects it doesn’t mean that we can forget the user in our automated checks. Understanding the ‘flows’ which different user segments take through the system is vital. Observing users on your application and using data analytic tools from vendors such as Google can build a picture of the most popular flows. We can then create automated checks to ensure that the flow between these pages is at least working. In my experience teams can often neglect the user in their checks. Many automated checks take the ‘path of least resistance’. Rather than automating the most popular user journeys the checks are designed to minimize automation maintenance.

For example, at a previous company we automated quite heavily through the User Interface. A key part of this was adding items to basket and ordering. Our automation checks would start by going directly to a product, we would pass in the Product ID as follows:

This was efficient for automation purposes but meant we were skipping one of the most important parts of the customer flow the home page, search and gallery pages, which were the most visited pages of the site.

Our automation also needs to consider user ‘Persona’s’ from a data perspective. Do the users in our automated tests reflect what a real user looks like? Again, in my experience, teams often bulk load in a set of users who are all pretty much exactly the same, again to minimize the overhead of managing lots of different data types. Therefore you’ll often miss issues that occur in the differences between users. A good example is a user returning to a shopping site when they have already added an item to basket. Do all your test start with an empty basket?

To Conclude….

A User Journey is an ’emotional’ experience so we cannot automate these type of tests yet(and probably never will). Ensuring you consider the emotions of your users throughout the entire development life cycle can increase your chances of having an application that will create a good experience for your users. As Testers we can play a valuable part in testing with our users emotions at heart.

Automation can provide an important platform for any customer journey to ensure the application is at least giving the customer the correct result from business logic and allowing to flow through the system.

[1] Introduction to User Journeys

[2] Softbank unveils ‘human-like’ robot Pepper –

[3] Emotions in Software Testing

[4] Shop Direct Test Lab

[5] Testing your Emotions –

[6] Design Thinking –

[7] Testing and Checking refined