This is conversation between two friends
Kris: I have to tell you a secret… I have big problem with “learning” if we talk about ET (exploratory testing).
Lisa: Hmm… It’s always been taught to me as “learning about our product”. But I am not an ET expert by any means.
Kris: For me “learning” means “to change behaviour”
Lisa: oh, interesting! for me it’s just gathering knowledge
Kris: Gathering information doesn’t include using it. You use information by changing your behaviour (huge excursion in my experience as mother and trainer). But only thing what we want to change is the software. So no real learning on human side.
Lisa: We might learn about features we are missing?
Kris: That is functional or contractual acceptance testing. No learning.
Lisa: So if I do exploratory testing on some feature, and then I realize, before customers can use this feature, they need another capability that we haven’t even thought of before – I didn’t learn something? Or if I find something is really hard to use – I didn’t learn something?
Kris: How do you know that they need something else? Hard to use – do you mean usability? Testing usability?
Lisa: How do I know? Because I’m exploring as a particular persona or role or job, I have a scenario of what I want to accomplish with the app, and I run into a roadblock. The persona is blocked, Lisa has learned that we didn’t provide a necessary capability.
We might be splitting hairs on words and semantics, but exploratory testing is called a process of learning, and it has seems correct to me.
Kris: For me it is very important to clarify what we mean by words. I always liked language (in Latvian we have more then 30 words how we call a mother), but as older I get as more aware I am about layers of language, coded messages and communication in general. People, who name things, make mistakes (just like everybody else). I am not looking for fight… It just feels wrong to call it “learning” if we only gather information.
Kris: The way how I understand whole team approach is that if we have situation as you described it, the tester in the team should be able to identify and categorise the problem. Is it functionality, usability or performance? then to decide what following tests should the team run to gather missing information.
Am I aiming too high?
Lisa: IME it works best if the tester collaborates with the team to do all that. We don’t want to be the safety net so that everyone relies on us to point out issues. We want to help teammates prevent the issues from happening in the first place by building shared understanding of features, using good tech practices for code correctness, fast feedback loops with automation, exploratory testing before committing changes…
More a consultant role than doing all the testing for the team.
You know, you have some interesting ideas here, it would be nice to discuss this on the AgileTestingFellow slack.
Kris: Maybe… but I don’t feel there yet. And I didn’t mean that tester is a safety net. What I meant is that tester has this knowledge about testing techniques and approaches and she/he guides the team. This is what I understand with tester as testing coach for the team.
Lisa: Sure but we have to be continually helping everyone else ramp up those skills. If we make all decisions ourselves, we take autonomy about testing away from the rest of the team. Guides, yes, that’s the ticket
Kris: Yes, helping others. But tester should be able to recognise it her-/himself first. Only then she/he can guide others.
Lisa: I like what you say there about recognizing it in ourselves.
I really, really LIKE how James Lyndsay phrased it:
“Systems are weird. Are you looking for trouble? Exploratory testing can help you to find unexpected truth, about what you really got.”
Exploratory testing is technique to find out, gather information. As a team we will decide later what we want to do with information with gathered. Maybe we will ignore it, because risk is too low, maybe we will use it and make decision based on it. And maybe we will learn out of it, adapt our behaviour and leave the issue in the past. If it will not reappear, then we really can tell: “we learned something!”