Skip to main content

The Four Hour Tester - Interpretation as a Team Exercise


I do hope that everyone has heard about the Four Hour Tester by now. A fascinating experiment by Helena Jeret-Mäe and Joep Schuurkes, distilling the key skills in testing into a set of exercises over 4 hours. This resonated with me, I enjoy thought exercises where you reduce something down to what you believe to be critical, really making choices and having to let go of previously unrealised biases and assumptions.

After seeing the model demonstrated at TestBash Manchester last year, I thought it would be beneficial for me to gather my colleagues, pair up and attempt the first exercise, "Interpretation":

http://www.fourhourtester.net/exercises/Interpretation.html

Essentially, come up with as many interpretations of the second sentence of the following paragraph:
“You can add reminders in Google Calendar. Reminders carry over to the next day until you mark them as done. For example, if you create a reminder to make a restaurant reservation, you’ll see the reminder each day until you mark it as done.”
Here are some of the results, we came up with:

Exercise:

You CAN add reminders - but nothing else
You can ADD - can you remove?
YOU can add reminders - but nobody else can
Reminders CARRY over - Does it create a new reminder? Does it carry over with the same data? Does it have the created date? Does it keep extending? Is it infinite?
Reminders carry over to the NEXT DAY - Which one? What about on days that cross international borders? Birthdays? Timezones? What about people who fly? International Space Station? Rockets?
You’ll SEE the reminder - IS it visual? Audial cues? What about blind people? Does it take over the device? Does it focus? Does it only vibrate the device (Also visual!)?
You’ll see the reminder EACH DAY - when on each day? Morning? Night?
MARK as done - Tick? Cross? Colour? Fade? To note for later?

Reflection:

1. Yes. Viewpoints from multiple standpoints, ESL, cultural influences, etc etc 
2. VERY! One could develop a system subtlety different to the expected system
3. Times! UI! Permissions! User input!

--------------------------------------------------------------------------------------------------------------------

Spec:
You can add reminders in Google Calendar. Reminders carry over to the next day until you mark them as done. For example, if you create a reminder to make a restaurant reservation, you’ll see the reminder each day until you mark it as done

Analysis:
1. Who can add reminders/ everyone can add/ certain permission levels?
2. You can add reminders either just for yourself/ other people as well/ shared reminders?
3. You can't add them from anywhere else, eg automatically added booked flights
4. You can only add them (not edit/delete?)
5. Reminders are the only thing you can add?
6. Do you need to be able to add text? Locations? Specific times?
7. You can add them for today (or for the future?)
8. You have to mark them as done or they remain indefinitely/ for a set time period?
9. The reminder makes the reservation for you?
10. It shows you the reminder once/day or every hour?
11. Can you snooze/ dismiss without marking as done?
12. Are you shown the reminder only when you open google calendar?
13. Can mark it as statuses other than DONE?

Questions:
1. No, not really. We felt that what is there is relatively clear, but there are a lot of gaps in the specification, which isn't something we can solve other than by obtaining further info from stakeholder. Analysing highlights the gaps but doesn't give a clearer/ deeper understanding of what is required.
2. We felt implementation would be similar, but lacking implied/ not specified functionality due to gaps in the spec. If what was implemented strictly adhered to the spec there would probably be missing a significant amount of functionality.
3. Spec, design, interaction with reminders (CRUD), time zones

--------------------------------------------------------------------------------------------------------------------

Exercise:

“You can add reminders in Google Calendar.”
- You - Do I need to be signed in? Who can view the reminder?
- You - Can I set group reminders?
- You - Can I set a reminder for others? Can others set a reminder for me?
- can - Do I have to? What happens if I don’t?
- add - Do I need any permissions to create? Can reminders be updated, removed?
- Google Calendar. - can it sync with other devices linked to the same Google Calendar?
- Google Calendar. - compatibility with another calendar (outlook) or just Google Calendar?

“Reminders carry over to the next day until you mark them as done.”
- Reminders - Can I set multiple reminders? What’s the Max and Min number of reminders?
- Reminders - Can I set a time for the reminder?
- Reminders - Dose it alert? Visual - sound alert - push notification – vibrate?
- Reminders - Once or multiple alerts per reminder? When will the reminder alert, 5, 10, 15 mins before due. Are settings configurable?
- Reminders - Can I delay/snooze the reminder?
- carry over to the next day - Forever?
- carry over to the next day – do they alert again? Dose next day include weekends?
- day - How long is a day? 8-hour workday, 24-hour day?
- day - Clock type 24hour / 12 hour?
- mark them as done. - Can I delay/snooze the reminder? Dose the reminder update in anyway? What’s the definition of done? Is a history stored?

Reflection:

1. Yes – Its richer with questions to try eliminate assumptions and clear up ambiguities
2. Imp1 ‘Day’ = 24-hour day with 12-hour clock / Imp2 ‘Day’ = 8-hour workday with 24-hour clock 
3. Checking boundaries (lots of them)

--------------------------------------------------------------------------------------------------------------------

Exercise:

You can add reminders - but no-one else can
You can add reminders - but it’s not compulsory
You can add reminders - But you can’t delete, share or edit
Reminders carry over to the next day - not an hour, not a week, not a month
Reminders carry over to the next day - not 2 days, not 3 days, but every day
Reminders carry over to the next day - you can’t snooze them for a specific amount of time
For example, if you create a reminder to make a restaurant reservation, you’ll see the reminder each day until you mark it as done. - but you won’t be able to hear it, or touch it
For example, if you create a reminder to make a restaurant reservation, you’ll see the reminder each day until you mark it as done. - not each hour, not each week
For example, if you create a reminder to make a restaurant reservation, you’ll see the reminder each day until you mark it as done. - only you can mark it as done, no-one else
For example, if you create a reminder to make a restaurant reservation, you’ll see the reminder each day until you mark it as done. - you can’t delete it, or complete it, but you can mark it

Reflection:

1. The question is ambiguous because there are multiple sentences. However, my interpretation did become richer as it aimed to expose all possible interpretations of words, and consequently help reduce the ambiguity.
2. Very different, because there are multiple interpretations for the majority of the words.
3. The adding of the reminder, the carrying over of the reminder, marking the reminder as done

--------------------------------------------------------------------------------------------------------------------

(Shared with permission from the team taking part)

A few thoughts from me on the exercise and the session:

  • Questions or interpretations? - I think the temptation to ask questions rather than search for interpretations surfaced here. I guess the key difference for me is empathy. How might someone else interpret this, as opposed to answer my questions. 
  • Gradual realisation of where a requirement seems clear - A few people said, "thats actually pretty clear" as a requirement at first, a tester tries to see the complexity in the simple, more interpretations and questions followed each other cumulatively once that barrier had been breaches.
  • Interpretations of one word, a phrase, the whole sentence, the whole paragraph - this was my favourite part, the difference between micro (one word) and macro (the whole thing) context is at times equally massive. Interpretations of one word can send a ripple of misunderstanding, equal to that of misunderstanding the whole paragraph.
Give it a try as a team! We'll be moving on to exercise 2 as a group in a few weeks....

Comments

  1. Yeah I have heard of the four hour tester, really cool, the first exercise interpreter seems interesting, i think this always gives diverse results

    ReplyDelete
  2. This comment has been removed by a blog administrator.

    ReplyDelete
  3. This comment has been removed by a blog administrator.

    ReplyDelete

Post a Comment

Popular posts from this blog

Testers Guide to Myths of Unit Testing

One area that testers might be able to enhance their contributions to software development teams is how we perceive and contribute to unit testing. I believe testers busting their own illusions about this aspect of building something good would bring us much closer to developers, and help us realise what other layers of testing can cover most effectively.

Also, I want to do a talk about it, so I figured I would test the premise, see if potential audiences were into it. I put this on Twitter:
Working on a talk about what testers might believe about unit #testing & how we interact with developers creating unit tests. Any challenges/additions for my list below? #development#agilepic.twitter.com/4oT5HE4qs3 — Ash Winter (@northern_tester) December 19, 201730 replies with ideas tends to indicate that people might be into it. 
The ListI thought, as my final blog of 2017, I would provide a super useful list of the myths and legends we as testers might believe about unit testing:
That developer…

Wheel of Testing Part 2 - Content

Thank you Reddit, while attempting to find pictures of the earths core, you surpass yourself.
Turns out Steve Buscemi is the centre of the world.

Anyway. Lets start with something I hold to be true. My testing career is mine to shape, it has many influences but only one driver. No one will do it for me. Organisations that offer a career (or even a vocation) are offering something that is not theirs to give. Too much of their own needs get in the way, plus morphing into a badass question-asker, assumption-challenger, claim-demolisher and illusion-breaker is a bit terrifying for most organisations. Therefore, I hope the wheel is a tool for possibilities not definitive answers, otherwise it would just be another tool trying to provide a path which is yours to define.


In part one, I discussed why I had thought about the wheel of testing in terms of my own motivations for creating it, plus applying the reasoning of a career in testing to it. As in, coming up with a sensible reflection of real…

Wheel of Testing Part 3 - Applications

I've only had to quit two jobs to finally find the time to finish this blog series. Winning at life. If you need reminders (like I did) check out Part 1 and Part 2 before reading on...

After the first two blogs regarding the Wheel of Testing, I was delighted to receive a few requests for the wheel itself, which got me thinking about applications of it, beyond what its original intent was, which I've explored in detail in part 1 of this series of intermittent blogs. Most models need a little air time to show their value, in software development we crank out models all the time, but I'm not sure how many get used. I am inspired by models such as the "Heuristic Test Strategy Model" by James Marcus Bach, as I have used it and seen the benefits it has brought for my clients, particularly the ability to ask questions. So, I wanted to create a model which has a number of use cases, both real and imagined:

Helping to unlocking a career in testing which may be stuck

It is no…