“But what,” you might ask, “should I do in the afternoon?”
That’s a little unfair of me. But this is one of Musashi’s principles that can only come with experience. It stands against the snap judgement, “we have to do something; this is something; therefore we should do it” position that you get in so many situations.
It may not be about deciding to do a thing; it may be about deciding not to do a thing. I came across a bug yesterday that I thought was happening when the system did a certain thing. But examining it further showed that this was a coincidence and the bug was happening without the certain thing happening as well. My intuitive judgement was to look a bit further and try out a number of scenarios before committing the bug report back to the devs.
I have had a working career of nearly fifty years. I’m not for one moment suggesting that people with less experience than me are not suitable to be testers – far from it. But I’m often finding that I draw on experience dating back before I was a tester, or sometimes even before we had computers in the workplace, to inform me about user behaviour and business needs. It is a question of developing the art of seeing, a capacious memory for odd things that people do at work, and being able to develop the intuition to link the two.
That skill doesn’t come overnight. But neither does the repository of experience. Keen testers need to start developing the habits of observing and finding out about other people’s lives, jobs and transactions. You never know when a bit of obscure knowledge will come in handy.
It’s no good thinking that “my company makes software for soft toy manufacturers, so I need to learn everything there is to know about soft toys.” That may be so, but restricting your hunt for knowledge only to soft toys will not make you a better tester. One day, a problem will arise that can only be solved with reference to the outside world.
A tester can never have too much knowledge.