Persuading about Exploratory Testing: The provocative-analogy way Henrik Emilsson
This is my reply to the thread “Persuading about Exploratory Methods” in software-testing@yahoogroups.com.
This starts out with the problem that it is sometimes hard to persuade a manager about Exploratory Testing, when all that matters to the manager is that tests ought to be documented (in order to know what should be tested, how many test to produce and execute, etc). Or at least, this is often their argument in such discussion.
And it is also often the case that a tester or test lead find it difficult to explain why it would be suitable with exploratory methods; and exploratory testing in particular. Partly because managers don’t know how to test efficiently; and partly because the tester/test lead find it hard to speak at the same level as the manager.
So here is an example of how you can use the provocative-analogy way when discussing this with your manager.
You:
“Dear Boss, I am concerned about the meetings you attend and what you say on those meetings. I am especially concerned about the coverage of the important issues that should not only be brought up, but also be solved in these meetings…
So, here is what I think you should do:
a) Document everything that you should say on the meeting in advance, by first identifying all possible issues that we have, then by writing down exactly what should be said in a specific order.
b) Write down the expected answer or solution to the issue.
c) Remember to ignore anything else that is brought up on the meeting, the only thing that matters is those issues that you have prepared in advance.
d) Take notes during the meeting (but only when your issues of interest are discussed).
e) Finally, write “OK” for each of your issues where the meeting came up with the solution/answer that you had foreseen, and “Not OK” for those issues where the solution/answer disagrees with yours.”
Boss:
“Are you kidding me!?! Do you have any idea of how a meeting really works?
You see, what we come up with on the meetings are through conversation and interaction.
Yes, there are important things that we know of in advance and that needs to be resolved; we put these on the meeting agenda. But there are also things that come up during the meeting that we could not have foreseen, things that come up during interaction between the attendees.
Also, the answers or solutions to the issues are sometimes very hard to predict.”
You:
“Oh, I see… That it something I can somewhat understand and relate to.
As I understand it, this somehow resembles how we do testing:
We have a conversation with the product and interacts with it to get to know more and more. You see, what we come up with in testing are through conversation and interaction. And yes, there are important things that we know of in advance and that needs to be tested; we put these on the testing agenda.
But there are also things that come up during the testing that we could not have foreseen, things that come up during interaction with the product. Also, what the actual result should be is sometimes very hard to predict.”
Boss:
“Oh, I see… That it something I can somewhat understand and relate to. I have not thought of it in that way. I will never ever tell you to do scripted testing again.
Do the brain-stuff! I am your friend!”
Disclaimer: The last comment might not be said, but hopefully you get my point. 🙂
———-
Another less provocative way is to just use the analogy with testing and meetings/discussion/dialog in your efforts to explain why exploratory methods should be used and promoted.
I have experienced an opposite case as a Test Manager where I tried to get the testers to do ET instead of their regular scripted testing. Many of them came directly from school as electrical engineers and had little experience of test methods. The major resistance in that case was that there was a belief that our contractor, who was going to take over all documentation in the end, wanted to know exactly what we have tested so that they could re-run our exact test scripts, see what result each test gave and if they deviated from the expected result.
I honestly do not think that original intent was for the customer to be able to re-produce each test executed or that they needed to know each result and especially not to see deviations from expected result. They surely want to know that what we have covered and the result of these tests, but that can be obtained using ET as well. I guess the inexperience is just with the format of the reports and a resistance to change.
So, coming back to your thesis it might be good to ask the Boss to explain why there is a resistance to change. What drives the decisions?