Acting the fool

Testers can be idiots. In fact, it's almost part of the job description - unless the product you are delivering is aimed at one specific user, or requires the user to undergo training before use, there has to be an allowance for all levels of  intelligence, knowledge of conventions and familiarity with the product, and the tests need to reflect this. I see this as a major difference between the way developers and testers approach a project - in my experience, developers tend to see requirements as a set of "happy paths" they can use to construct the required code; I often look at requirements as a challenge - given a particular set of rules, what are the limits of behaviour that still fit within those boundaries?

I'm not having a dig at developers - the process of building happy paths first is similar to the way I write these blog posts, starting with something basic then refining until you have a finished product. It's like the old artist's trick of smothering a blank canvas with paint, then completing the picture on top of that - editing is much easier than creating. Also, approaching a project from different angles is what makes the developer-tester interaction so strong and stops it becoming simply a rubber-stamping exercise.

An example. If a spec says "user must create a username and password between 8 and 15 characters", most devs would be able to quickly knock out a webpage to do just that without questioning the requirement. My immediate thoughts are: does the restriction only apply to the password? Can I have exactly 8 (or 15) characters (depending on the interpretation of the word "between")? Can I include spaces? Special characters? Non-western alphabets (e.g. Cyrillic/Chinese)? What happens if I try to use the wrong number of characters? Can I edit my credentials later and break these rules? Is there an admin role that can edit these credentials, and if so, does the limit apply there? I'm not saying developers wouldn't consider these points, just that they aren't necessarily at the top of the agenda.

Some of those questions may seem frivolous, but all are possible in real life - for example, I have heard of a database that was corrupted because a user submitted a form that contained an emoji. Murphy's Law most definitely applies - whatever can happen will happen; if there is a flaw in the system, someone will find it (side note - if, as mentioned on Wikipedia, Murphy's law comes from mathematician Augustus De Morgan, I think it is a colossal misunderstanding of what he was saying. But that's a post for another day).

And there's the problem. Users are not well-behaved, good-intentioned individuals that always act rationally (or what we would like to think of as rationally). Some are genuinely naive (an instruction "press any key" prompts the question "which one is the any key"), others are downright malicious (hackers attempting script injection), all have their own motives and rationales for acting the way they do.  As Douglas Adams put it:

“A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.” ― Douglas Adams, Mostly Harmless

And that's where the testers come in, doing what they do best - acting like idiots.

Comments