One of the things I really appreciate about kendo is that we don’t wear coloured belts to denote rank. If I have never fought someone before, I have only what I can read from them to go by, be it how they carry themselves in the dojo, how they dress or the information I can gather from them when we cross swords. I am unfettered by any preconceptions I might have if I was able to see the colour of their belt. Because of this, I am free to attack them with full spirit and I am challenged to use my understanding of kendo to gauge their skill and fight them accordingly.
Testing is no different. When you are asked to test a piece of software you have never seen before, you should form your own opinion of the program’s abilities and complexity. Sure you may have heard a bunch of stuff about the program, but you should be prepared to discard or disregard it, especially if you suspect it may hinder the freedom with which you approach your testing. If you have been told that a piece of software is horribly complex and will do your head in, your response may be to try and perform tests of equal complexity or greater in an attempt to maximise coverage. You might also overlook the fundamentals of your craft – the simple things that can give you greater insights if not immediate results.
As an example, you may have been asked to compromise the security of an online login interface. ‘It’s super secure. You’ll never break in’, says the client. You might go to work with dictionaries and all sorts of wonderous script-kiddy play toys, but if you go back to basics you might learn something interesting. For instance, you might try logging in with ‘guest’ as a user/pass combo. If the test team is security lax, you could try combinations of ‘test / 1234’, or even ‘ or ” = ‘ to see what the db behind it will do. You could use the names and common details of the company itself, the company’s owner, executive team and or board members. That information is easy to come by. I’m not advocating you go try this stuff on the first online login you find, merely saying that simple is good. Fundamental is good. If it doesn’t give you results, perhaps it gives you something to work with.
Observe for yourself. Use what you have heard to supplement your understanding, not as a substitute for understanding. If in doubt, go back to basics.
At the other end of the scale, your preconceptions might lead you to believe that a relative novice will be a walkover. Sure they might only have a white belt on, but unbeknownst to you, they may have been training for years in several other martial arts. Looks can be deceiving. If you assume that someone will be a walkover, you might be right 99% of the time, but for that one per cent you are wrong, you *will* get your arse handed to you.
The same goes with testing. Something may at first appear very simple, take for instance a three radio button interface to a code profiler that switches between active, passive and coverage modes. Nothing too complex there. It looks like a white-belt, acts like a white belt – you switch modes, run the profiler, switch mode again, run again, observe, repeat – nothing too brain busting about that right?
Well, it depends. Maybe it is that simple. Maybe it’s just toggling a bit somewhere to tell the code to use different options. As soon as you assume that this is so, you disregard the possibility that the interface uses a very different style of code-fu for each option. If you don’t adapt your testjutsu to account for that possibility (and it’s 1 per cent time), there may be any number of people lined up to hand your arse to you.