Dear tester, you will never test like a user behaves

 "By that experience, Tukey and I discovered that what goes on in different people’s heads when they think they’re doing the same thing—something as simple as counting—is different for different people."

Feynman, Richard P.. "What Do You Care What Other People Think?": Further Adventures of a Curious Character (p. 59). W. W. Norton & Company. Kindle Edition.

Usually, when you think about professions other than software testing, it seems that the professionals have to be themselves to complete their tasks - a teacher is a person who teaches, etc. You may think of an actor as his primary role is to be someone else. But thinking deeply about it, an actor doesn’t try to portray someone else, but he or she is more concerned about how to make the character reliable in the eyes of the audience. Sometimes you must know what your adversary is thinking, like in chess or tennis. But do not be them, certainly act like them.

This is not the case in software testing.

The software testing field is so rich and developed (sometimes I think only testers know it, and not even all of them), that we are practically one of the leading technology fields. There are numerous articles and books about software testing, conferences, etc.

Still, the fundamental conflict of our trade is rarely discussed as an essential topic for itself (but aspects were discussed many times): how can a software tester be able to perform tasks that are, by definition, contradictory. How can he be a professional software tester and at the same time, as part of the tests, the true representative of the end user?

It is expected that a test engineer should emulate the client. This was always a significant part of the tester's job. But the tester comes from a different POV and state of mind, and can never use the app as a client, and even if so - as one of many. The test engineer is someone who knows about the product motivation, and technical aspects, and probably knows about the feature in much depth. When a tester enters the app, his whole state of mind is different.

Here are some differences that come to mind between the professional software tester and the client (when I say “client” I am especially thinking of someone who uses apps not as a significant tool of his trade, but as an accounting app for a CPA, but people that use apps as part of their daily tasks or entertainment).

(in case you are on a mobile device, you might need to manually move the table to see its full content).

 

Test Engineer	User
Usually has a high confidence level in his knowledge	On many occasions, the app is something used rarely and not all is clear.
Target - find bugs.	Target - do some functionality or enjoyment.
Tries to figure out how users will use this app.	Uses the app as a user.
Works in a methodological way, for example, tests feature rarely used by the clients.	Uses a small part of the app.
The tester has, in many cases, much more “app use time” than the client.	Uses when it needs it.
The testers know so much more about the app (from peers, training, and papers) than the client. Not only the functionality but also the technical aspects.	The user knows only what he needs, and sometimes he will miss relevant functionality.
The testers probably are emotionally involved in the software more than the client. The tester wants the app to be a success.	The user just wants to finish a process.
Both testers and clients has cognitive biases. The tester, on the one hand, should be conscious enough to overcome some of the biases, but some should remain because, well, the clients have them.	The clients mostly are just being themselves.
A tester will debug the problem. Only the fact that the tester knows how is changing his or her POV.	A client comes over a bug and then… well, usually that’s it. At most try to find a workaround or call support.
Testers know about field conventions (like how a link is supposed to look in the UI).	Sometimes.
Testers might have relevant special knowledge like in UX, social behavior, and university degrees.	Not mostly.
Testers use tools like sniffers.	The user will never know about that.
Tester gets paid for using the app	They do it for pleasure, for certain functionality. If it is for work, they are paid for a purpose that using the app is a tool for the purpose.
A tester gets over time a “feel” about the app. This might help him or her but also make him blind to things a user will see at first glance.	For a user, some aspects are seen at first glance.

And of course, the environments are different too. Usually, a tester has better hardware than most users. The environment of the client includes apps that the tester usually doesn’t. Testers like to start every day new, while the end user might leave the app open for months.

The answers to these issues are available. But they are nothing but workarounds, for example, from the top of my head: use a diverse team, Exploratory Testing, and do some bug-hunt sessions where not all participants are testers. Some use focal groups and UI research. Some will even test your app while drunk, trying to emulate a certain type of user. Some use different hats and some known characters. We use crowd testing and we use user stories.

The list above (plus unit Tests and any other quality tools) can lower our risk. But they will never eliminate it since we can’t be all the users in all their sessions. On the other hand, we may find bugs that look very critical to us, but most of the users will either not encounter them or will not care about them.

Solutions?

I can’t think of a very simple or straightforward way to overcome it. But I think that being conscious of the above differences might help us by trying to see the app, not always, but from time to time in the eye of a user. Don’t be arrogant about what the user does or thinks, and if you have some ideas about it try to back them up by stats or user reviews.