I remember developing a really fast technique for advancing/reversing audio cassette tapes using hexagonal shaped pencil and a lot of technique. Part of it was the pointless childish challenge, but also down to the brutality of my stereo player at the time. Fast forwarding from beginning to end of a C90 tape could take less than a minute, climaxing in an almighty clunk as the stereo took a few seconds to register the tape could be moved no further. I repaired the occasional broken tape using tiny pieces of sellotape – again, a childish challenge. For a child, adversity can take many forms, and as a child (occasional tantrums aside), we are persitent in our goal of navigating round obstacles put in our path – be they parental rules, or dodgy stereos. Our dogmatic belief is there is always a way round a problem.
An application presents a tester with a systematic set of challenges to overcome. We know there will be bugs somewhere, we know improvements can always be made, and we know there will be vulnerabilities. But unlike a child, we have to follow a more logical structure rather than the unstructured systematic approach of a small child. However, we can have both … end users can be viewed as childlike beings, and there is no reason you cannot add some method to the erratic methods of children to reach a goal.
I am well aware of my own behaviour when surfing. I turn into a cantankerous, impatient user who will leave your unusable site, just to spite you. Yes, I can be that petty. As a tester, I try to carry that with me. When users encounter a problem they may just give up, or they may just hammer away trying to get something to work. They may be bothered to write you an irritated email, but lets face it – how many of us can be bothered with that. I do it – but only as opportunity to introduce myself and testing services 😉
So we need to account for two broad user groups – those that give up at drop of a hat, and those that will persist doggedly to get round a problem. Both a major traits of a small child that are carried through to adulthood, and surface in differing situations. None more so than the web, which is most likely to bring out the sulky child in us all. This is possibly why I have always had positive experience using school leavers/undergraduates as testers, as they still have significant amounts of that childlike energy. You need to channel of course, as random chaotic testing can end up providing little value.
There are advantages to both, and testers need to play both roles, depending on the type of testing you are trying to perform. Doing a usability check definitely warrants the former group, as by far a major cause of people dropping off sites is Usability. If you are doing a security test, then an approach that covers multiple courses of action will highlight potential unexpected behaviour or security issues. You must have noticed, if you have ever been in a User Acceptance Test session with project stakeholders, there is also one person who will ask the awkward questions, and will deviate from path of instruction. They are the most useful person in the room, even if it may be painful to hear what they have to say sometimes!