Whether it be watching children’s tv or movies with my 2
boys, driving in the car with them or going for walks with them; its always the
same. Question after question after question after question…..
My eldest boy is at that wonderful age where he is learning
about his world. To do that means he is continually bombarding my wife and I
with a flurry of questions about everything he sees.
A recent example as we were watching ‘Toy Story’ and Woody
finds himself no longer the favourite toy as Buzz Lightyear comes along:-
Child: ‘Daddy, why does Andy no longer like Woody?’
Dad: ‘Its not that he doesn’t like him, its just he has a
new toy and he is playing with it instead, much like you do with your new toys’
Child: ‘But Woody is sad’
Dad: ‘Yes, he is sad but he will be alright. Andy will play
with him again soon’
Child: ‘But why is he not playing with him daddy?’
Dad: <repeats answer from above>
Child: ‘But why daddy?’
And so it continues. I have heard it said that ‘kids make
great Testers’…..
Now 1 of 2 things are at play here. Either my answer is not
making any sense to the child or he is not satisfied with the information he
has and wants more information. Now the method he is using to get the info is
to repeat the exact same question, but that’s what a child will do as he
doesn’t realize to frame the question in another way. However, the intention is
similar to any good Tester.
A good Tester will ask many, many questions in an effort to
paint a picture in their mind as to the problem. In other words, they want to
make sense of the issue or at least clarify it. To do so, good Testers will not
ask the same question over and over, instead, they will ask a question, use the
answer to ask another but phrased slightly differently. An example is below:-
Tester: ‘The app appears to be responding with an incorrect
message format, according to the spec’
Stakeholder: ‘It would appear that way, although that spec
is only a guideline and the 3rd party that the app integrates with
is not that fussy regards format’
Tester: ‘Ok, it may not be strict regards format but the
spec is our frame of reference, correct?’
Stakeholder: ‘well it is supposed to be, but as said the
app’s integration with the 3rd party behavior is the key frame of
reference’
Tester: ‘Ok, if that’s the case then why do we have a spec,
why is it not always reflecting the app’s behavior?’
Stakeholder: ‘S’pose we should update that but we just
‘know’ to use whatever comes back from the 3rd party as the correct
behavior’
Tester: ‘if that’s the case then how would we ever know if
there is an issue with the app integrating with the 3rd party?’
Stakeholder: ‘We would usually just know, but fair point, we
need to ensure our specs are correctly representative of behavior’
Tester: ‘well otherwise, we are saying that our testing will
only ever tell us what is being returned at that time. That’s not testing, that
is merely confirming’
Above, the Tester didn’t just ask the same question which
could have been ‘but why’ each time when the stakeholder explained the spec
wasn’t the key reference but instead, the Tester used rational reasoning and
the previous answer to frame the following question. Eventually painting the
picture not only for himself but also for the stakeholder, that all is not as
it should be.
And that’s the crux, Testers ask questions. NO!!!!. Testers ask GOOD questions, questions that
require a non-closed answer as much as possible.
Now earlier I mentioned that it is a popular opinion that
‘kids would make good testers’. That’s not strictly true, their questions are
immature which is perfectly understandable, they are kids after all. However,
they display one of the key traits that makes a good tester, they ask question
after question after question….
Being a good Tester? It’s not really child’s play J
"Testers ask GOOD questions, questions that require a non-closed answer as much as possible."
ReplyDeleteThis is an important point. A "yes" or "no" question focuses attention on the information objective associated with the Yes or the No. An open question is more likely to defocus, which reduces the chance that we'll miss an important problem. That's the root of this idea: Instead of asking pass or fail (a closed question), try a more open question: Is there a problem here?
---Michael B.
I’m my experience there is much value to be had in both open and closed questions, I find it very much depends on the personality of the stakeholder as too which style will yield the best results.
ReplyDeleteIn an ideal world both the tester and stakeholder will have bought into the fact that the spec simply isn't a guide but in fact ‘gospel’. In this case the tester can easily have the confidence to say “The app is responding with an incorrect message, as per the spec”. At this point the stakeholder would simply agree.
However, we don’t live in an ideal world and should the stakeholder not agree or take issue with your assertion then I almost feel that at this point we engage in a line of open questioning to ultimately convince of coerce the stakeholder into agreeing that something has to be addressed.
I have experienced stakeholders who very much don’t want to get into an open ended discussion; they appreciate the matter of fact of the tester, QA: “This is a problem”, Stakeholder: “Ah thanks, let’s fix that” while others don’t, and actually this matter of fact approach will result a more defensive stance by the stakeholder that ultimately hinders progress.
I think there is much value to be had in both styles but ultimately the real value comes not just when the tester has the ability to use open ended questions, but knows when and when not to apply them. The tester/stakeholder relationship is very important, as a tester it is important to understanding the personality of the team around you.