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 proffesionals have to be themselves to complete their tasks - a teacher is a person that 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 concern about how to make the character reliable at the eyes of the audience. Sometimes you must know what your adversary is thinking, like in chess or tennis. But 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), 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 testers 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 that knows about the product motivation, technical aspects, 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 in mind between the professional software tester and the client (when I say “client” I am especially thinking of someone that uses apps not as a significant tool of his trade, 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 manusly move the table to see its full content).

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 don’t. Testers like to start every day a-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, do some bug-hunt sessions where not all participants are testers. Some use focal groups, UI researches. 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 (+ 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 or will care about.

Solutions?

I can’t think of a very simple or straightforward way to overcome it. But I think that being conscious about 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 think, and if you have some ideas about it try to back them up by stats or user reviews.