It’s funny how one can take different media and apply them to what you want to…in this case software testing. I recently watched a World of Warcraft ad with Mr T from the A-Team days (http://www.youtube.com/watch?v=bqJE5TH5jhc )
Mr T created a new character, a Night Elf Mohawk – the ‘directors’ of the ad said that he couldn’t do that. In Mr T’s own way, he boldly announced that he was ‘handy with computers’ and ‘hacked his own Night Elf Mohawk.’
Like most things software, the developer is looking for a solution to a problem. A tester (in this analogy, Mr T) is looking for a problem in the solution or in other words looking outside of the box.
Being *bound* by specifications and scripts is what I mean by box. Now I don’t mean that i am anti specification and anti scripts (they may be valuable resources, oracles if you will, in the right context) but reliance on these solely leads to the box being painted (http://viscog.beckman.illinois.edu/flashmovie/20.php for an example of *box painting* – INSTRUCTIONS FOR THE CLIP: Count the number of passes made by the team in white. Record the number of passes and continue reading….(at the end of this post is the next set of instructions but don’t go there yet!)).
In the ad, Mr T is looking outside of the box. He is thinking outside of the bounds of the requirements.
Why?
If the software delivers as per the requirements, has it not passed?
No.
Outside of the *bounds* are the areas testers love to tread because we then are looking at potential bugs. When we find bugs and report them, they are resolved in some way. As they are resolved, then potentially the quality of the product is increased.
I once worked on an application whereby the requirement of an input field (stated in the specification) said “truncate 32 chars”.
This was a java based browser hosted financial application.
A colleague and I started testing. We typed into the input field and as much as we tried, we couldn’t type past 32 chars.
So we created a very large string (1,000’s +) and copied and pasted into the same input field.
BANG!
CRASH!
DEAD!
The application fell over completely!
The developer had followed the spec and had coded for it but he did not cater for a copy and paste (let alone a large string!)
It took the developers about an hour or two to resolve it.
In this case, we thought outside of the box – we dared to push beyond the realms of the spec. We tested for something that wasn’t considered and this is an important consideration for testers – to question and challenge what is in front of us. Challenge what we have been given and the value that we will add as testers will be made manifest (i.e. bugs!!)
Happy hunting!
**INSTRUCTIONS from the video clip continued – what did you notice? Was there anything interesting going on? If haven’t found anything, review the clip and defocus your vision or in other words, look outside of the box.
Brian Osman 