Work And Play

We’ll split into groups. Each group will work together to test something for a few minutes. I’ll give you something to think about while testing.

At the end of that testing time, you’ll talk to each other, in your groups, about what you’ve learned from each other.

We’ll switch subjects, and test again.

After 2-4 rounds, we’ll gather and summarise.

Test Subjects

Puzzle 29

Puzzle PP05

Puzzle 31

Full exercise description on GitHub

A short game to help testers build connections.

Make a group. Distribute cards. Take turns. Each turn, one of you reads a question, and its options, out loud – then chooses one option, privately.

The reader may give points to anyone who predicts (or sways) their choice.

Points are pointless.

NB: Everyone can give the reason for their choices, if they like. Some people may be open to persuasion.

Notes for players and facilitators :

Setup and Timing: A small group can deal with a question in anywhere from 30 seconds to a few minutes. More (much more) when the conversations get going. So if you have groups of 4, you’ll need around 5 minutes to get through a round of one question each. At the other end, this game gets stale after much more than 20 minutes.

This game has no winner.

This is /not/ a game about finding out information, necessarily. It’s about the conversations that happen around those nuggets of information. Encourage each other’s surprise, greet their scepticism when they wonder “Why would you do that?”.

Players should at least try to stick within the constraints of the available answers – choosing between equally-silly options /is/ the game. If people propose a further, “more right” answer, the activity becomes about what’s /right/ rather than what’s personal. It becomes more judgemental and less playful.

Players might find it hard to answer a question. If it’s you, and you don’t want to pick another question, don’t be concerned, but do wonder. If you want to get unstuck, you could use one of these tricks:

Add one word to the question (keep the answers)
Ask your group for which answer (and why) they’ve picked for you
Invert your round: which answer would you throw away?
List the answers, ask the group for a question, award points
Pick another question (or another card)
Say you’re finding it hard, ask for help, and consider why you’re stuck.

This game works fine without a facilitator. If you’re a faciliator, be clear in your own mind about why you’ve taken that role.

You may find that the volume increases over the first few minutes, and drops after 15. Look for poeple smiling, include anyone who’s looking confused. Mix things up by moving between groups. Encourage people to play with the game (that’s why the points are pointless).

Some thoughts about how to wrap up:

As a closing question, “What would you like to share” tends to be more open than “What was your favourite question” or “What did you learn”.
With a team who know each other well, pay attention to collective surprises and points where individuals have changed their minds. Allow those conversations to grow after the end of the game.
With a group who don’t know each other well, you could, in the conclusion, ask people whether some of them were suprised by something they learned about themselves. People often are, and sharing that can make the group receptive to more chances to change.
If groups hack points, share how. Messing about with pointless points can be a good distraction from over-serious attention to questions.
Avoid “What did you learn about someone else?”, as whoever is picked out may be uncomfortable withe the attention. Try “Did you say anything that surprised those around you?”.

Questions, and printable deck, here: [https://github.com/workroomprds/QuestionsForTesters](github.com/workroomprds/QuestionsForTesters "GitHub - workroomprds/QuestionsForTesters")

Test a Black Box Puzzle via an API or via the UI.

Questions we’ll be considering:

What qualities does the API have, and what does that tell you about the puzzle?
What information does the API require, and what does it return?
What are some differences in your approach?
What is simpler – and what is more different?

Tools you could use: the URL in your browser – it’s just a GET. Postman. Paw. cURL.

Kit you’ll need: At a minmum, something with a browser (ie your phone). Better: something easy to type on, something which runs your weapon of choice, something you can generate data with (ie your laptop).

Puzzle29 Bare API, working example.

Puzzle31 Bare API, working example.

Note that these APIs validate your input and tell you what they expect, and (roughly) what’s wrong.

Docs via Postman

Here are the graphical interfaces for Puzzle 29 and Puzzle 31

Full exercise not yet ready on GitHub.

Explore a simulation of discovery and diversity

These simulations model testing and discovery.

We’ve made a groteque simplification: we know how many bugs there are, and we model our work to discover them by deciding that some are hard to find, some easy.

We introduce a wrinkle: a limit on how many bugs we can find, in a single bit of work. This adjustment makes the output easier to grasp, and is closer to experience.

In this simulation, we have a budget for work. We can see work that has been done / yet to be done, and bugs that have been found / yet to be found.

We’ll play and predict to dig more deeply into the model, to examine one role of diversity in testing, and to understand our own beliefs about how we organise and budget discovery activities.

Exercise 1 - basic

Exercise 2 - single tactic

Exercise 3 - mulitple tactics

Exercise 4 - switching tester

Exercise 5 - switching testers

We’ll be in groups to play SpaceTeam.

Everyone in a group needs to fix the same spaceship – but the tools and information needed to fix the ship aren’t usually near what needs to be fixed. One person in each group will be the observer.

Some groups will play SpaceTeam on their phones. One group can play the card game. Video instructions here.

After each game, we’ll talk about what went well, what went badly. We’ll each write down a principle that we’ll play by in the next game. We may shuffle ourselves between SpaceTeams.

We’ll debrief after a few games by discovering which principles seemed appreciated by team members. We’ll make a poster to share.

This exercise explores how we manage communication across many channels simultaneously.

SpaceTeam is free to play on iOS and Android.

Full exercise description on GitHub.

In this exercise, you’ll write code to satisfy some pre-existing tests.

Each small group here has their own server in the cloud. James has just given you a piece of paper with a number identifying your server. To get to it, go to James’s server here , then use the list of links at the bottom of the page to get to your own server. You’ll know you’re there when the subtitle contains your server’s number.

The index web page on each server has instructions to give you routes to

testing (Jasmine for automation, something trivial for exploration)
editing (IceCoder) and
visual coding (Blockly) if you want to try it

You’re writing code – a file called main.js with a function main in it that transforms a variable inbound into something else, and returns it. Your pre-written tests express some things about the transformation.

Your job is to write code to do the transformation, editing a file (on the server) to add and change code, and another file (on the server) to enable (and write) tests.

Some of this coding will be trivial, some will be confusing. Please work through the confusion, and wok with each other. Experienced coders are encouraged to pair with inexperienced participants, but should not write the code on their server.

In our guided tour, we’ll

point your browser to your own page on your own server
run Jasmine tests and read the dead ones
get into our coding environment (setting a password on the way) and browse to files
read testMain.js, recognising the conenction with Jasmine, and change it to enable or add a test
rerun jasmine to seeing the new (probably failed) test
read main.js and edit it to change or add code

Then you’ll pick a test to enable, and write code to make it pass.

We’ll review what you’ve done, do more, maybe refactor.

At the end, we’ll share what we’ve done and our reactions to it.

Play “Keep talking and nobody explodes”

Here’s the Game – James and Bart have a copy each.

Here’s the bomb manual.

We’ll be in 1-2 groups, depending on how many bombs (and people) we have. Each group needs one Bomb Disposer (who interacts with the bomb via the computer) and a bunch of Bomb Disposal Experts (who have the manual, but not the bomb).

We’ll play the game a couple of times, then work in our groups to create some communication rules-of-thumb to share.

This exercise explores how we communicate in assymetrical groups with lots of information, a single narrow channel, and limited time.

Full exercise description on GitHub.

We’ll take something that exists in a range of flavours – chocolate, cheese, beer. We’ll have 5-10 things to taste, and enough of them that we stand a chance of each having 3-5 small samples.

Individually, we’ll taste two, identifying key differences.

We’ll pair up to compare those two (so 2-4, depending on overlap) and our analysis. In pairs, we’ll add more, so that each pair has 5 things. Those pairs will create a list of potential properties and ranges they’ve seen. We’ll keep an eye on how our lists grow – and on the differences we see between tasters as well as between subjects.

We’ll get into larger groups, comparing our lists, sampling more. We may, individually, identify those properties, and the points in their ranges, where we feel that quality is higher.

We’ll debrief with questions about what “quality” might be for these subjects.

This exercise explores the ways we move from specifics to generalisation via classification.

This exercise explores the ways we experience things, and how we try to share that experience with classification.

Can we arrive at an objective assessment of quality from our collective subjective experience?

Full exercise description on GitHub

Work And Play

Schedule

EuroSTAR 2019 – Work and Play

Exercises

What can I learn by testing with you?

Test Subjects

Questions for Testers

Notes for players and facilitators :

API testing for a Black Box puzzle

Are we Done Yet?

Repair a Spaceship

Write Code to Satisfy Tests

Defuse a Bomb

Taste Test

Previous outings

Outings

London Tester Gathering 2019 – Work and Play

Agile Testing Days 2018 – Work and Play

EuroSTAR 2018 – Hands-On Lab