After RST namespace announced deprecation of the term "exploratory testing", I've been using it even more. For me, in the beginning there was just testing. Later, there was an understanding that there are two kinds of testing: one that starts with performance and learning in mind (exploratory) and the other just as important that starts with artifacts and automation in mind (unit testing / test automation). Both can end up in the same place, because around both learning and thinking happen. It just happens with a different kind of emphasis. This way of thinking around words is akin to the way we think of guitars. There was only one kind of guitar, but with the birth of an electric guitar, the other one became acoustic.
When talk with people who are strong in testing with the artifacts view, on the level of discussion of our perceptions and ideas, we can easily end up in an argument. I get to hear I will be replaced by automation and that there's nothing I do that would provide value with respect to what they have already put into the automation. The other gets to hear that the automation he's created with love is missing something abstract. Unhappiness on both sides is ready. I've left numerous agile sessions with the feeling I just will leave the industry not to feel this bad.
Instead I've grown to realize that if I get to pair up on real and practice problems with one of these people instead of the abstract conceptual ideas, very different results emerge. I quoted one of those from a private discussion (with permission) yesterday:
As we test together, things stick. Some of the things that used to be testing to me are now design and discovery for the developer. We both learn on, every day picking up new stuff. And with the differences in focus, there's again something different I can contribute, often from the side of product ownership in a very practical, empirical and hands-on way.
In exploratory testing, I actively and knowingly build conditions that enable learning while testing. I avoid repetition, I vary my paths, my approaches, my pace, my tools, everything. When given a spec, I see what it says but most of the pay attention to is between the lines. I focus wider than what I think I already know.
Seeing developers find appreciation of discovery through experiencing exploratory testing is great. But this only comes from shared experiences, not from sharing theories of relevance. Test together. And learn to fight to get your voice heard - it was one of my big challenges on this path, to convince the developers to just do things my way instead of immediately transforming them to "automation" and missing out on what I actually do.
When talk with people who are strong in testing with the artifacts view, on the level of discussion of our perceptions and ideas, we can easily end up in an argument. I get to hear I will be replaced by automation and that there's nothing I do that would provide value with respect to what they have already put into the automation. The other gets to hear that the automation he's created with love is missing something abstract. Unhappiness on both sides is ready. I've left numerous agile sessions with the feeling I just will leave the industry not to feel this bad.
Instead I've grown to realize that if I get to pair up on real and practice problems with one of these people instead of the abstract conceptual ideas, very different results emerge. I quoted one of those from a private discussion (with permission) yesterday:
For me it's been clear that in order to build things, developers explore around their problem and solution. It seems to me that sometimes their need of coming to a solution within all the constraints takes so much of their focus, that they can't let their mind wonder to the extent I can, as the tester. Being able to see what developers think enables me to identify parallel thought tracks that lead me to insights of problems and ideas of how we could be better. It's like I'm backtracking tasks, and only now feeding back ones that are directly applicable for the ongoing flow. Yet the rest might come back, as soon as I have empirical evidence of their existence or a chance to set up a task to go find that empirical evidence.'After experiencing exploratory testing, I'm discovering and appreciating discovery more while unit testing' - @LlewellynFalco— Maaret Pyhäjärvi (@maaretp) July 12, 2016
As we test together, things stick. Some of the things that used to be testing to me are now design and discovery for the developer. We both learn on, every day picking up new stuff. And with the differences in focus, there's again something different I can contribute, often from the side of product ownership in a very practical, empirical and hands-on way.
In exploratory testing, I actively and knowingly build conditions that enable learning while testing. I avoid repetition, I vary my paths, my approaches, my pace, my tools, everything. When given a spec, I see what it says but most of the pay attention to is between the lines. I focus wider than what I think I already know.
Seeing developers find appreciation of discovery through experiencing exploratory testing is great. But this only comes from shared experiences, not from sharing theories of relevance. Test together. And learn to fight to get your voice heard - it was one of my big challenges on this path, to convince the developers to just do things my way instead of immediately transforming them to "automation" and missing out on what I actually do.
