Interview with Santhosh Tuppad on Usability

 Do you like great interiors and ambience at hotels or restaurants you visit? One could correlate food to functional and interiors and ambience adding up to usability which adds value to the dining experience.

Here is an interview with Santhosh Tuppad who emphasizes on usability being crucial testing for any software that is designed and developed for people around the world or people of specific location or any living being or could be anything. Usability is a deeper study and testers who say, “Oh, usability is to see if application is user friendly”, they are mostly faking it. The hard truth on the contrary is, it's not easy and has never been easy.  I got Santhosh to answer a few questions. Take a look.

Why do you call usability as a crucial ingredient for software?

It is because, you want to;

a.      Win more customers

b.      Give the best to your customers

c.       Win over your competitors

d.      Entice your competitors customers as your customers

e.      Give better user experience for your customers

f.        Want to make more business and increase your revenues

g.      Make people spread a word about your software

h.      Ultimately, help do GREAT BUSINESS!

My management is not serious about it or developers just reject the usability bugs I report?

This is a classical problem that most of the testers find. Here are some tips that might make them serious about it. Even if you could change ones thinking, then you have made a better impact).

• Build good rapport with your manager and make him / her understand about usability and its importance.
• Conduct a meeting with your team members and speak to them about usability and how to report them (Bug Advocacy).
• Even if developers reject your bugs, there should be a genuine reason and not just like that. Keep reporting even if they reject. All the testers in your team should report huge number of usability bugs and then I bet they will not reject them or higher management looks into them because so many bugs are being rejected. At least, you will not be pointed when customer reports the same usability bug which you wanted to report but were biased that the developer may reject it and hence did not report it.

What books do you read / how do you practice usability?

• Psychology reference book
• http://useit.com/ and http://boxesandarrows.com/ are good ones to refer (Be careful, you need not agree with everything these people are telling. There need to be your own thinking, that’s when you could make things better rather than following someone else’s ideas blindly. Here, you will see how I opposed the idea of Jakob Nielsen – http://useit.com/ however; I refer to it for some cool study).
• I design websites (Well, buggy ones)
• I interact with UI / UX designers
• I attend conferences on UI / UX
• I keep myself updated with new technologies which could add value to software when implemented or when enhanced
• I co-related usability with the things in day to day life. I do exercises with the things around me about usability.

What are the important skills you think you posess for getting better at Usability testing

Analyzing “What could be good” for end-users. Most of the times, I have succeeded when I analysed things over time. However, there is bad side to it when you just start getting biased by your thoughts of usability rather than seeing it from customers’ point of view.  I have seen testers saying, “You got to put yourself in customers shoes” and then test for usability. Well, its easy to say; but too challenging to do it. Your customers might range from -- millions, billions, trillions of end-users with different brains, different thinking abilities and different ways of using software. Now, you see, “Wow, this is really challenging”. If you still do not feel it, then either you do not want to accept it or you do not understand it. Continue to do your functional testing. Most of the organizations are happy with it.

I have cultivated a practice of arguing with my own thoughts about usability. I have seen at times, when my colleagues just agreed whatever I said but, I go back and think on those lines. Finally, I get better approach than what I really said. So, that’s the thinking power. Do not stop just because people stopped arguing with you. You argue with your own thoughts or you say to yourself, there is something better I can do rather than sticking to my old ideas.

Do you conduct workshops or talks or would be interested in guiding aspiring testers?

I am not ready to conduct workshops on usability yet. In future, I will be.

With respect to talks, I am interested to explore opportunities in formats like half-day seminars or 2 hour talks on usability.

With respect to mentoring or guiding someone, I feel I am running out of my bandwidth as there are many people who are approaching me for security testing. However, I could support you people over e-mails but, do not expect quick replies. I would at least take 1 week however; you might receive responses at the earliest in few hours or minutes as well.

Related articles on Usability

http://tuppad.com/blog/2012/01/04/a-quick-usability-cooking-through-mindmap/

http://tuppad.com/blog/2012/03/14/an-awesome-test-for-testers-take-the-challenge-now/

http://tuppad.com/blog/2011/12/05/do-you-really-understand-usability/

About Santhosh Tuppad

Santhosh Tuppad is the Co-founder & Senior Tester of Moolya Software Testing Private Limited (www.moolya.com). He also recently won the uTest Top Tester of the Year 2010 apart from winning several testing competitions from uTest and Zappers. Santhosh specializes in the exploratory testing approach and his core interests are security, usability and accessibility amidst other quality criteria. Santhosh loves writing and he has a blog at: http://tuppad.com/blog/. He has also authored several articles and crash courses. He attends conferences and confers with testers he meets. Santhosh is known for testing skills and if you are passionate in testing, feel free to contact him at: Twitter: santhoshst | Skype: santhosh.s.tuppad | Santhosh.Tuppad@gmail.com

Why testing isn't good? - Inspection Vs. Prevention

Once upon a time in Testerland, there lived an enthusiastic tester called Ether (Enthusiastic Tester). Ether was a well known tester at the time. He had great rapport with Techland, Devland, Businessland, Salesland to name a few. His knowledge and talent was the talk of the land for every release that went into trouble just before the D-day. His reputation was such that a new phase called 'Ether' was introduced for every release. This meant Ether had to bless every feature before his organization Org released it to the market.

Ether was happy with the way his life was going. He had been getting a pay hike every six months and a promotion every two years. Not to mention the heap of awards showered on him on a quarterly basis.

And then came the storm
Suddenly, Org wanted several "Ethers" in Testerland. They wanted to create more Ethers, train them and do what it takes to replicate many such Ethers. After all, one Ether could not succeed in blessing all releases 24/7. He was human and he needed to avoid burning out. Organization thought the same. Thankfully.

Org lined up all its concerns in testing with Test-eagle, the highest authority in Testing. Test-eagle had set up the first team in Org which had now grown to about 10,000 testers in Testerland alone. He was a key guy responsible for all the innovative stuff that had happened in Testerland so far. It was only obvious he had to get involved in this mission.

Test-eagle met up with top executives in Testersland and heard them out. He decided that a few decisions had to be made. His questions were pretty simple:

1. Why are more testers not transforming like Ethers?
2. What is stopping Org from building more Ethers?

He thought for a week's time and presented a report to his leadership team. His proposal was okayed in a day's time. No questions asked. After all, Test-eagle knew exactly what he was doing.

Test-eagle lined up all the managers in Testerland, Devland, Techland and others and passed a mandate on the following:

1. A new role 'Lead tester' was created who report to Quackle, who headed QCOE - Quality Center of Excellence 
2. For every two testers, there will be a lead tester
3. Lead tester will supervise tester's work on a day to day basis
4. Lead tester will come up with metrics based on tester's work
5. Lead tester will present the findings to the leadership once every Quarter

Lead testers were the new Quality Inspectors

Test-eagle was to review the results after 1 month. Interestingly, Test-eagle didn't have an inkling of what was happening with testers in Testerland although he passed the "Inspection Bill" and expected it to rock as always.

One month later...........
Test-eagle was welcomed with a pile of results and findings from lead testers who were proud of their findings. Some key observations were listed as below:

1. Ether had left Org for greener pastures
2. "Ethers in the making" had left Org for greener pastures
3. Testers in close proximity to Ether in talent and knowledge also left ...... for greener pastures of course!
4. Testers who were doing well on an average stopped doing so. Motivation had dropped
5. Testers who were doing what they were told to do no longer did it; instead stopped doing anything at all. Productivity was as low as nothing
6. Testers who didn't do anything meaningful continued to do the same
7. Customer started complaining that even basic requirements were not functioning properly

Quality lay breathless at Org's Doorstep

What happened?

1. Lead testers brutally pin pointed how testers can be better in what they do.
2. Lead testers wanted the testers to follow 50% scripted approach and 50% exploratory approach in addition to 20% of time/effort contribution to Automation
3. Lead testers wanted to review every bug before it was reported in the bug tracking system
4. Lead testers questioned the severity of bugs
5. Lead testers rejected several valid bugs because they didn't think that those were bugs
6. Lead testers questioned testers if they missed any bugs
7. Lead testers questioned testers if they thought testers tested very little on a particular day

Lead testers forced the testers to TRY HARDER and DO BETTER which testers were already doing. Something more had to be done. No one knew what that "something more" was.

What went wrong?
Test-eagle ignored the following which was a sub-set of problems that existed:

1. Test environments were never stable. Release management team hardly took onus
2. Test environments if available needed lot of troubleshooting from testers before it worked
3. Checking in code changes into environments took days at a stretch
4. Code drops to testing teams never happened on time. There was always a 2 week delay 
5. If code drops happened on time, then a very small code mass came for testing. For e.g, if there were say 10 features, only 1 feature would have been available in testing
6. Code drops coming towards release deadlines contained massive number of features
7. Availability of data for testing was always a problem. Data team always forced testers to compromise testing with workarounds. Data team provided invalid or nonsensical data at times. A laptop for example would cost only 2 Baht
8. Infrastructure in testing environments were never provided on time. If the production environment needed 3 load balancers, testers would be advised to test without the load balancer and certify that the code works fine and doesn't break anything new. Whether the code worked with 3 load balancers in production was a question not to be asked
9. And a lot more..........

What's wrong with the inspection approach? 
Inspection chokes! How will you feel if your mom or dad just kept staring at you without saying a thing to you while you do your household chores. Same thing had  happened to Testerland testers.


There was a need for a CHANGE IN THE SYSTEM in totality. What Test-eagle did was to transform just the "Testing System" converting people in other systems to Supervisors who oversaw testing work and mocked at it. Test-eagle put complete responsibility of quality with testing team and let others go scot free.

Test-eagle failed to understand that Quality is everyone's job, but management's responsibility. 

Test-eagle was highly de-motivated. What on earth failed his plan on which he had invested his blood and sweat on. He had to calm down. He had to come down to tester's level. He had to prevent some or all of the tester's problems listed above to be able to improve the quality of testers. He had to fix a few problems that were built into the system even before blaming the 'Testing system'. And he did. As a first step, he figured he didn't need Lead testers. Not that he fired them. He still kept them, but after stripping off their Inspector roles. He made them part of the system.

Inspection Vs. Prevention mind-set
Test-eagle moved away from an Inspection mind-set to a Prevention mind-set. He thought that if he fixed a lot more problems in many other non-testing teams, testing teams could do better. Testers could do better. Ethers could come back to Org without a second thought. He looked at some of the key problems that Org was facing for a long time. He identified top five problems to begin with. He summoned the respective stream leaders and discussed problems in detail. A brainstorming session followed. Few action items were noted. And the group was off to execute.

Courtesy: www.docstoc.com

The first improvement was on the Test Environment challenge. The release manager was answerable for every minute of test environment downtime. He took the onus of fixing the problems right away, of course after being reprimanded by Test-eagle (Sometimes, position power is the only power that works.) After a while, testers were happy. They no longer suffered long hours of environment downtime. They could test a lot more in the same time that was scheduled for testing. They didn't have to waste time on mindless things.

Test-eagle took each stream to task and fixed the problems one after the other. Slowly, testing team was empowered. Empowered to TEST BETTER!

*This post is inspired by John Guaspari's book 'I Know It When I See It'.

Regards,
Parimala Hariprasad

Guesstimate - An estimation challenge

Suppose I ask you to test category 'Books' on www.flipkart.com.

Let's take the task of testing 'Send email' feature. As a project lead, I might say it takes 5 man days to test this feature. Suppose that a tester needs to pick this task and complete it in 5 days time.

In above scenario, 5 days time is a rough estimate. An estimate is a guideline, not a deadline. The project lead would have arrived at number 5 due to one of the two reasons below:
1. He just picked a random number out of the time available for completing testing
2. He knew the product in and out and made this guess

What factors the project lead may not have considered about the feature and the tester while estimating?
a. Time required to explore and learn the feature by the tester
b. Time required for ideation and test design for that feature
c. Test data avaialability for sending emails. For eg, Anti-virus testing - Procuring Eicar files as attachments while sending emails
d.

First Year AWESOMENESS @ Moolya

It's been an year already since I joined a Sexy Startup called "Moolya". It was time for an interview as part of the company tradition. This interview is very special to me as it comes from people who I not just work with, but also have profound respect for. My interview is now posted on Moolya blog HERE. 


Below is an appreciation of my work from Pradeep who often calls me a "Damager" :-). I am humbled to the core!

************************************************

Padmasree Warrior, CTO of Cisco is one among the many who made it big and is noticeable. So is Kiran Mazumdar Shaw of Biocon. If you ask me who would it be in testing, I would bet it is Parimala from India. Talking is easy, walking through the talk is difficult. Parimala makes walking the talk look easy. She has a Parimala way of working and I believe she has a large influence on people working with her. Not all people who are touched by her blog, so some of what Parimala does remains hidden and secret. Through this interview with her, I am trying to see if I can bring to the world what she does and how she does that. What has Moolya been able to offer to this great woman, who doesn’t actually need Moolya to do great testing but Moolya definitely needs her to remain delivering moolya.

When Mohan Panguluri joined us as the CEO, he was wondering how many appreciation emails does she get after looking at a stream of appreciation emails from our customer and their teams she works with.


 Look at some of the amazing things she said in this interview. The one of empathizing with people was a gem of a thought and writing. To work with Parimala, I have to raise my standards, otherwise I start to look bad to myself. Even if I do not raise my standard, Parimala would respect me for who I am. Not because it is the so called Pradeep Soundararajan but because she treats everybody the same and respects people. She teaches us humility.

Salute!

************************************************

 Special Thanks to Moolya and Moolyavans for making my stay here so Awesome. Looking forward to many more years ahead.

Purely a marketing blog post. Jokes apart, this means a lot to me!

Regards,

Damager Pari

CAPTCHA and Customer Context

In my previous blog post, my friend and colleague Santhosh Tuppad asks, “What are the different contexts in which customers might want to use CAPTCHA?”

Captcha and customers always makes for a difficult discussion. As a customer myself, I am annoyed at Captchas that are hard to read. If I had an option, I would obviously opt out as it reduces one step :-). However, as a tester, I would be concerned about the implications of not opting for a captcha. Here are a few contexts where customers might want to use Captcha. Some of these could be repetitive from my previous blog post - do bear with me.

Image credits : www.onlineaspect.com

Where would a customer prefer captchas?
Sign up
Suppose I run a testing forum on my website. This requires users to sign up to be part of the forums. What if a script is written to register infinitely? I would like a captcha on the registration forms to isolate fake accounts from genuine users. Unlimited Sign ups without appropriate verification could become a daunting challenge for website owners to solve.

Login page
If a user has keyed in wrong password 3 times consecutively, present a Captcha to this user to prove if he is a human or not :-). I have assumed that user’s account is locked out after 5 unsuccessful accounts. Some applications limit it to 3. Captcha along with account lockout policy helps curb brute force attacks early on.

Forgot password page
If an attacker tries to hack into another user’s account using Forgot Password feature, he could write a script for the same. I would prefer a captcha on Forgot password page as a second level check so that scripts are not capable of bypassing the same. Note that first level check for Forgot Password feature is to ask the user for username/email address. Also note that captcha database must be robust enough to prevent attackers from exhausting that list quickly. Captcha usage on this form prevents email spamming (could be one email or mass emails at a time).

Forms (Comments, Feedback, Suggestions, Sales queries etc)
Comments
As a blog owner, I get bogged down with all kinds of spam comments. I prefer a captcha to be presented to users who want to add genuine comments and keep spammers away.

Sales queries
Many startups can’t afford a 24/7 toll free line to answer customer queries. They place a nice little page on Contact Us section of their websites to invite sales queries. If some thirsty spam bots find such forms, it’s crocodile festival ;)

Feedback/Suggestions
I prefer a captcha on feedback or suggestion forms to prevent random feedback from spammers or spam bots.

Discussion forums
Users who are willing to submit questions on forums that don’t mandate users to register are easiest targets for spamming. Presenting captchas while user posts a question is a good practice.

Facebooking
You post an update or upload a photo and you are presented with a captcha. There are two facets to captcha usage here.
1. As a user, if I am presented with a captcha while updating the status or uploading a photo, which is a one time activity, I would do it no matter how annoyed I am about this prompting. If I think of my account in an attacker’s hand, I would be worried about spam bots. Though I acknowledge the fact that spamming status updates can be done manually, it may not be done at a speed that a script would accomplish.
2. As a business woman selling something on facebook, I would hate a captcha. Suppose that I have a facebook account for my retail business where I am needed to update my status or post pictures quite often. Providing captcha details could be very annoying, yet unavoidable in this context. This could affect user experience.
Note: In either of the cases presented above, it’s better to have captchas.

Customer preference of a Captcha
Some customers who prefer captchas may have security aspects in their mind while many other think it spoils their user experience. Above listed contexts are a few where I would prefer captchas. If you have a different view, you can always spam me in the comments section as I don't have a captcha ;)

Take it with a pinch of salt
As users we think that if captchas are in place, we can bypass spam. Captchas are not 100% spam proof. Neither are they 100% secure. In today’s world where most of the captcha implementations are easily broken, its hard to trust captchas completely. Some friends suggest that re-Captcha is not broken yet. Well, it could just be a matter of time ;)

Addendum
Santhosh Tuppad has written a cool blog on Testing Captchas. Have a feast.

Regards,
Parimala Hariprasad

Gotcha CAPTCHA?

A CAPTCHA is an anti-spam program that generates tests that humans can pass, but computers can’t. CAPTCHA is an acronym for Completely Automated Public Turing test to tell Computers and Humans Apart originally coined in 2000 by Luis von Ahn, Manuel Blum, Nicholas Hopper and John Langford of Carnegie Mellon University. Captcha is typically used where the application needs to know that it’s a human on the other side and not an automated script or another computer(which can’t think for itself).

Imagine going to the public library and picking a century old book. If this book has to be converted to an e-book, the computer must be capable of reading the book. A machine unlike a human cannot identify a real bug, some dirt collected over the years, missing letters, wrongly spelled words and others. i.e., computers cannot read distorted text. This is the funda behind Captchas.

Types of CAPTCHA

Text

Human is challenged with a text captcha with some amount of back ground noise.

Image

An image with or without text is presented to the user and a question is asked based on it. For E.g., “Which is the bird presented in the picture below?”. This captcha could even take the form of a graphical puzzle which the user must solve.

Q and A

User is presented with a question like “How many hands does a crow have?”. If this type of captcha has a limited set of questions and answers, it could be broken easily.

Math puzzle

A mathematical puzzle such as 2+3=? is presented to the user who is expected to complete the math problem.

 

Game captcha

 

Why do we need CAPTCHA?

• To prevent spammers from creating fake accounts on websites [Registration page]
• To prevent unauthorized users from accessing features that help hack email accounts and/or spam user’s inbox [Forgot Password’]
• To prevent automated software from participating in online activities by impersonating a human [Online polls/surveys]
• To prevent spammers from commenting on websites [Comment forms] 

 

Bypassing CAPTCHAS

Bypassing Humans

Hire humans who can enter values in captcha fields when needed. This means that a script can be written to register or spam on the web.

Automated scripts

A spammer patiently downloads all the captchas on the website over a period of time and builds a database. He could in turn write a script to compare captcha images and instruct the script to key in appropriate values into the captcha fields based on comparison operation. These are situations where Q and A and puzzle related captchas come in handy to considerable extent. However, it’s important to note that these captchas could be programmable as well. 
Using Free OCR, spammers can decode text based captchas. Spammers can use one such tool to build a robust captcha database and use them to bypass captchas.

Using session ids

Most captchas may not destroy the session ids when correct captchas are keyed in. These session id’s can be exploited with the help of a few lines of code and bypassed easily.

Eliminating the CAPTCHA element

If captchas are validated at client side and not on the server, users can remove or eliminate the captcha element using an add-on like Fire bug or knocking off the captcha code in HTML source code. Easy bait, isn't it?

CAPTCHAs and Usability

* These days many websites present captchas that are difficult for humans to decode, forget about machines :-). Background noise in captcha (anything other than the text that makes it difficult to read the text) must be optimal enough making it easier for humans and difficult for computers.
* If users are unable to recognize a particular captcha, there needs to be a provision to re-generate a new captcha. In general, every page refresh displays a new captcha to the user. 
* Providing audio captcha supplements captcha functionality by allowing the user to listen to the audio in case he cannot decrypt the captcha. 
* Suppose a user is on a registration page and has already entered captcha information. For some reason, form submission failed. Here, user is presented with a new captcha for a second time. If the user has already proved that he is a human by keying in captcha data, why present it repeatedly to the user. 
* Look and feel of captcha elements with respect to the web page background color and images is important. Keeping captchas at the end of the page where they are hardly noticeable becomes a problem for users who realise that there is a captcha after page validation fails on that page. 


There are some applications where the same captcha is presented even if user enters wrong data instead of presenting a new captcha post page refresh (LOL).

 CAPTCHA and Accessibility

* Displaying captcha with a lot of background noise becomes a problem for differently-abled users. For e.g. a visually impaired user cannot see what’s on the screen. It needs to be read out loud. This requires audio support and hence the need for an audio captcha.
* Accessibility functions need to be built into the web application for screen reader tools to read captcha elements and invoke an audio captcha.
* Few applications display captchas that are hard to decode by humans themselves. This often poses an accessibility problem for all groups of users. 
* Dyslexic people could have problems with captchas too [Just wondering]

CAPTCHA and Security

A small database of captchas is easy to collect and crack. If a website displays about 20 captchas on a website in a random fashion, a regular user on that website can figure out all of those, write a little script and crack them. Below is a snippet from one of my blog posts on how absences of captcha can impact security.

* No Captcha on Registration forms
This is a wholesome option. I recently needed 50 valid email accounts to be created for testing a website. All I did is write a simple automated script using iMacros (FREE add-on) for account registration and creation. All I had to do is activate these email accounts manually (note that this step could have been automated too). At the end of the testing effort, these accounts were discarded. Now, if you are a company that allowed 50 email accounts for a single imposter, you lose an awful lot of revenue. Is this what you want? If you had a captcha in place, my script would have failed as captcha expects different data at each times which needs human intervention. Building a captcha on registration forms is a good design idea to snub away not-so-serious users or spammers.

* No Captcha on Forgot Password forms
If there is no captcha on Forgot Password form, I would possibly write a script to feed in umpteen number of valid email addresses to the Forgot Password page. Why would any user do that? He could be a cranky user. He might draw fun in irritating fellow users. He might be an unethical hacker. He doesn’t know what to do with his life!

* No Captcha on Comments forms on websites and blogs
As a blogger, I get a lot of spam comments for products that I don’t need.. I wish spammers took segmentation and targeting seriously and routed their ads to appropriate audience :-). Without a captcha in place, spammers can write easy little scripts to post these *free ads* in the comments section of any website. Having a captcha would require human intervention which in turn might block spam to a reasonable extent. 


Addendum on 21st June 2012
Added Game captcha. 


Regards,
Parimala Hariprasad (yeah, changed my surname. Do remember ;))