Thank you for coming to the Hands-On Lab at EuroSTAR2018!
You’ll find more up-to date exercises and info at WorkAndPlay.workroomprds.com
In this all-day session, we ran through a collection of hands-on exercises.
Each exercise has a description here, and a longer description on GitHub. You’re welcome to run these exercises with your colleagues back at work. Be aware that you may need licenses or other access.
Facilitated by James Lyndsay (@workroomprds) and Bart Knaack (@Btknaack) within the TestLab (@TheTestLab).
Activities
Wednesday only. Each HandsOn Lab session is 45 minutes long.
- 10:45 Defuse a Bomb
- 11:45 Black Box API
- 13:30 What can I Learn by Testing with You?
- 14:30 Repair a Spaceship
- 16:00 Taste Test
Suitable for everyone. Bring your own device.
We may limit numbers for some exercises.
Defuse a Bomb
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.
API testing for a Black Box puzzle
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.
What can I learn by testing with you?
We’ll split into groups. Each group will work together for 5 minutes to test something.
At the end of their testing, they’ll talk about what they 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
Repair a Spaceship
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.
rience?Taste Test
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
Full exercise description on GitHub