We gave the first exercise an extra 10 minutes testing. We looked at moving away from one-at-a-time testing, reflecting some people's work with the bulk input tools (the 'parametric slider'). We did not get to the 'dependent behaviours' exercise.
The Behaviour framework is a discipline to help you explore and identify the different ways that your subject works. You’ll identify behaviours and :places where (or :situations when) those behaviours change.
This framework helps you explore the different ways that a system reacts to input. It's a handy model for working with systems with state, and for making a model of how those different states interrelate. It's not so good for systems whose behaviour is determined by combinations of many indpendent state machines. It can help when focussing in on combinations of a few interdependent state machines, and is particularly helpful when modelling lifecycles of persistent data entities i.e. accounts, tariffs, user sessions, offers.
It’s up to you what you might call an event, a boundary, or a behaviour. You’ll probably need to write a few things down before you start to group them. Use your exploration to help you identify and differentiate the items in your lists more clearly.
Once you have a collection of behaviours and events/boundaries, try to identify and isolate the relationships between different behaviours, and the ways that the events/boundaries can mark the transition. Can some groups be isolated? Do some seem more important than others? Allow your exploration to guide you to answers to these questions.
Think about what triggers the change in behaviour (you? another system? chance? a combination of factors? an undo? a bug?) and what happens when that trigger is followed swiftly by another.
Exercise: Behaviours and boundaries
15 minutes exploring, 15 mins debrief
Use Converter_v3 . Please ignore the sidebar for now.
- Consider your input as a range
- What boundaries can you find where the output changes in some way?
- How do you distinguish between different ways that it changes?
- Explore behaviours around
- Are those behaviours shared for different units?
- We'll talk about what you've seen
Debrief – publish your notes on Miro. Check out other people's work. Can some understanding be communicated in notes?
Exercise: Dependent behaviours
5 minutes exploring, 5 minutes debrief
Return to the timer used in Day 4 – Exploration and Testing.
Consider four entities – the start button, the step button, the moving dial, and the input field.
Examine the state diagram for several things which change behaviour (start button, step button, moving dial, and input field). Pick a couple. Explore the timer to see how those states interrelate.
Debrief: do those states fall into groups? Compared with your first exploration of the timer, how do you feel about this exploration?
We're halfway through. I want to make some space for questions, and to revisit the past 5 sessions.
If we've covered that ground, we'll preview the coming content.
Exploratory Testing Without Tools is Weak and Slow
We've been exploring these systems, so far, by putting one thing in at a time, then observing the output. While this is great for revealing how we work, and for exploring the princicples and mechanics of exploratory testing, it's a poor choice for commercial work.
Most testing, exploratory or not, involves tools to take action, and tools to collect results. As we progress into the second half of this workshop, we'll be using tools to help us work with many experiments.
Different means of input
If you're testing the UI, use the UI. Maybe write a test system to lie the other side of the UI so that you can manipulate the UI from both sides.
If you're looking to test through the UI, and investigate the deeper system, then let the UI help, but don't get stuck on it. In the next exercise, you'll switch to changing the input swiftly and perhaps carelessly.
Exercise: Input with a Slider
3 minutes, mostly debrief
Choose the radio button labelled "slider"
Work with the slider to reveal more about the system under test. Do you need more than a minute?
Debrief – What's different about your interactions with the system under test, when you're using the slider?
In this exercise, you'll use a slider whcih lets you set the ends. You typically woudn't find this on a UI, but it will push you to think about test design.
Exercise: Input with a Parametric slider
3 minutes, mostly debrief
Choose the radio button labelled "parametric slider"
Choose the start and ends of the slider. Play with the slider. What have you found?
Debrief: Share your slider ends (and perhaps why you chose them). Share what you learned about the system under test.
:x Ranges in time
When we think in terms of time, we recognise that behaviours tend to last until an event. Events punctuate behaviours. What persists? What changes? What marks the change?
:x Ranges in position
When we think in terms of a range, a behaviour is shared by all members of a group within that range. Perhaps we'd think of boundaries in that space, rather than an event in time.