Testing - Child's Play?

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 3^rd 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 3^rd 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 3^rd 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 3^rd 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

Need To Know

Bernard Woolley: But, you only need to know things on a need-to-know basis.  
Sir Humphrey Appleby: (quite animated) I need to know “everything”. How else can I judge whether or not I need to know it?  
Bernard Woolley: So that means you need to know things even when you don't need to know them. You need to know them not because you need to know them but because you need to know whether or not you need to know. If you don't need to know, you still need to know so that you know that there is no need to know.  
Sir Humphrey Appleby: Yes!
 http://www.youtube.com/watch?v=vh1eCDotdSc (about 1.35 onwards)

The above quote comes from the popular 1980s sitcom ‘Yes Minister’ which was an amusing look at the high handed and snooty aspect of British politics at the time. The show provided a different way of looking at politics, often in a comical way. The actual scene from above has Sir Humphrey, who was the Permanent Secretary to the Cabinet Minister and is quite manipulative in his dealings with the Minister, in the aim of ensuring his own agenda is fulfilled. Alongside him is Bernard, who is the private Secretary to the Minister (a body man of sorts), loyal to the Minister and quite naïve.

When I saw this scene, it got me thinking of how this “need to know” relates to the Testing field. I have on many occasions, been asked ‘what makes a good tester’. My language I find varies dependent on audience, but a few central themes never change. Creativity, inquisitive, understands the role (as in it’s not about being a Yes person and following the ‘green bar’) and crucially, ability to focus and de-focus. It is this final point that I want to elaborate on.
The main difference between an average tester and a good tester is that ability to appreciate how and what they are testing and how that relates to the bigger picture. Too many testers can test their feature/application/story at that time and see it almost as an individual entity. That’s fine, there is value in that aspect (they can focus).
However, the really good testers will do that AND be able to place it into the bigger puzzle (defocus). In other words, ‘I am testing feature x, ok that works, great (focus). Now, what about feature y and application z, they have dependencies on feature x and there is a knock on from application abc, as that feeds into feature x. Ok, I need to pull together a map/compass as to how I am going to test those dependencies. Oh, also, a customer might do d, e and f that rely and interact with feature x. I need to test that too’ (defocus)

Remember what service a tester provides. The tester provides information on a feature/application/software. That information shouldn’t just relate to the feature/application/software in isolation, it should also be information on as many aspects of that feature/application/software as possible, in the time allowed.
Now, an average tester might say ‘oh, I didn’t know I had to do that and I am testing the story/feature as that’s what the requirement is, I don’t need to know what feature y and application z do’.

 My counter to that is ‘you should want to know everything, how else will you judge what you need to know’. Sir Humphrey was right in this instance.