Scene: In a restaurant, a family of 3 arrived – parents and a toddler. After ordering the most favourite pizza, the family was relaxing and toddler started playing with the chopsticks laid on the table. He liked them and decided to eat his dinner using chopsticks only.
He announced his desire and parents, busy in talking, agreed upon it. When the pizza was served, the toddler started using chopsticks and was failing number of times in getting the pizza in his mouth. Suddenly the parents noticed it and ordered the toddler to not use chopsticks. Toddler did not convinced as the parents had already agreed upon his desire earlier. When parents started teaching about eating pizza with knife and fork only, toddler questioned the belief, but I want to eat it with chopsticks only and why is it wrong? And while using chopsticks when he was not able to eat his favourite pizza, he got impatient and ultimately threw the chopsticks away and decided to not eat pizza as well. Parents, frustrated too, could not do anything and the family dinner time turned up as worst time of the day.
Now, replace some words in above para as following and re-think about it:
Parents: Project management team including Business analyst, sales person, development manager and architectural team.
Toddler: Customer / end user
Pizza: product / application
The most favourite application is only favourite until user does not make mistake and does not see the worst behaviour of application. Once experienced, the user never comes back to the application. And therefore, as a tester, it is very much necessary to understand user’s mind set, how he is expected to behave, what wrong he can do with the application, what could be the worst mistake made and many more.
Most of the time, I have been asked in forums as well as by in-house team members about how to replicate user’s experience while testing. My answer has always been simple – Be a user :)
Although it’s easy to say than implement, it’s right time for the software testing industry to move into direction of revolution where user experience and feedback is more important than anything else.
How a Tester can think as an End User?
Presenting hereby some typical examples of behaving as an end user and finding surprises, I have observed during past few days:
#1) While testing a date field, when user selected or manually entered correct date value, it worked fine. But when user ended up entering totally incorrect value like 12/00// and clicked on OK, he was presented with error message about invalid date value.
Now user does not correct the date but refreshes the page. What should happen? Well, many of you can guess what should happen, but can you think of what happened with the application? After refreshing the page, user was presented with following and the same value was saved in database also.
So…..the tester has replicated the user over here, agreed?
#2) While testing an application, where the work flow is to submit various forms in special sequence, if followed the order, it worked fine. But what if the user tried to go back to #3 form, from #5 form?
Again, rather than thinking about what should happen, let’s see what happened…
Tester was dumbfounded but felt pride in turning up himself as user…..Agreed?
#3) After successful login, user clicks on back button of browser. Again, let’s see what happened…
The credentials should have cleaned up but it did not. Moving further, on this Login page, user clicks on Forgot Your Password link. Be clear that user had already logged in and had been on login page by clicking the back button of browser. The click on Forgot Your Password navigated the user to the home page of application.
Tester turned to user…..Agreed?
#4) After observing the URL for search page (http://x.x.x.x:y/#/Search) of application, tester modified the URL as http://x.x.x.x:y/#/Search/test? and can you think what would have happened?
Well, the application crashed and again tester turned to user…..I hope you won’t disagree.
I guess, via these examples, I have conveyed enough of what I wanted to.
Really, testing does not mean to check the workflow of application and neither it means to break the application but it certainly means to check user’s experience even when he make the mistakes.
About the Author: This post is written by STH team member Bhumika Mehta. She is a project lead, carrying 10+ years of experience in software testing. She appreciates good ideas and innovations and risks too. And of course hates monotonic work, people and environment.
And yes, let’s turn the tester in ourselves to end user….Agreed? :)
So…..we would like to hear more examples like these from you and would like to have your opinions too.