Monday, 10 April 2017

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....

Monday, 3 April 2017

Wheel of Testing Part 1 - Motivations



(This will be part of a blog series - part 2 will discuss the content of the wheel itself and what I think it means, part 3 more how it can be used) 

I recently attended the peer conference NWEWT2 in Liverpool, which is my favourite type of conference. You get to share your ideas, have them scrutinised and hopefully walk away a bit wiser. The theme here was "Growing Testers", something that I had wrestled with my whole career, so I looked forward to getting involved. I got some excellent feedback. Also, to my delight, I was also accused of aloof wizardry by Gwen Diagram as I wouldn't offer a definition of 'tool assisted testing' to those who had used the wheel (see above), so I walked away happier and more wizardly than ever.

When I became a manager a few years ago, the world opened up more of the vast variance of human motivation to me. I had to consider contributing the development of others, as well as the self. Problem is I thought I could develop other testers, without really having their buy in, I had the answers. I was completely wrong about that. I had to learn it the hard way. Thats a whole other story but contributes to the existence of this "Wizarding Wheel of Testing".

Hints had been there for a while. Someone said to me while practicing a workshop about "Testable Architecture":
"Why would I need to learn about architecture? I just work on tickets."
Then in a team meeting, someone else said:
"I don't just want to push tickets across the board, but what can I do?"
*Where tickets might be stories, issues, features, enhancements, bugs or whatever on a teams visual radiator/information refrigerator (otherwise known as Jira)

I grant you this is not an overwhelming amount of empirical evidence, but the testers in many organisations I had worked in had such a narrow focus, dictated by delivery demands. How does one open minds but not replace one repressive model with another? Always the danger, replace one tyrant with another? No matter what your original intentions were...

Underlying motivations...

Lets look at what was going on in my mind:
  • Open as many doors as possible - the more doors opened, more chance to walk through them. Literally no one can walk through one for you.
  • Promote questions and not answers - buckets of detail lead to buckets of dependence and dogma. Careful.
  • Not obsessed with definitions - defining things is useful, until it becomes divisive. See 'Testing vs Checking' when used as a stick. Socially generated definitions in organisations through conversation. Useful.
  • Represent the core of a tester - what are the core skills of a tester. Now thats an interesting question. Choose wisely from the multitude. Discuss.
  • Was your career linear? - did your career progress beautifully along a smooth curve? Bullshit. Career models generally ignore the bumpiness of reality. And are created by managers who do not listen to their own experience.
  • More you learn, the less you know - testing is a vast discipline, which is part of its allure. I have no idea how much I don't know. Each segment of the wheel could be a specialism/career in learning in itself.
  • Disciplines overlap as much than they differ - create something that developers. product people recognise too? Similarities as well as differences are important.
  • For the buccaneers - ever seen an organisational career model which reflected never mind rewarded buccaneering learning? They are generally about finishing stuff not learning stuff through broad horizons. 

More here:



Then, the wheel was then born! Gandalf wasn't there. Or Dumbledore. Just me. More soon. 

Original slides from NWEWT2: