Manage Learn to apply best practices and optimize your operations.

Test software with a user perspective

When testing software you need to think beyond how users are intended to use software. Think also about how they could misuse it.

There are many aspects to testing. One intention is to prove that the final product meets the customer requirements. The tests are usually done in two parts: The tester makes sure that all of the required features and functions are present and accounted for, then the tester makes sure that the features and functions behave as expected.

There is a straightforward way of testing. But there are other aspects testers ought to be aware of.

Trying to break the application on behalf of the user
Let's take the example of a Web application that has a lot of online processing. If the first screen asks for a user id and password, I will start off by entering no values and see what happens. Did I get in? Did an error occur? Does the screen just sit there? What should happen is the application should consider this an invalid response and return the appropriate error message.

Users will type any value into online fields
When I get into application screens, I enter all kinds of crazy values. If the field expects an alpha, I enter a numeric. Then I enter special characters such as (*&%$â ™. I run through the rest of the fields the same way.

I also try to screw up any pre-populated fields. I always tell developers that if you don't want a field changed, then do not allow a user to place a cursor in it and type. I guarantee you that if you leave a field open for input, at some point, at some time, someone will try to type a value into it.

More information about usability testing
Usability testing vs. user acceptance testing

User acceptance testing and test cases

What software testers can learn from children

Users will hit every combination of available logic flow 
In addition to simple editing errors, I also try every combination of logic flow. When I look at a Web page, I try every hyperlink and see where I end up. The developers look at me and wonder why a user would ever do that. Again, the point is that they may not do it on purpose. However, you should expect that every combination of logic would be attempted at some time.

Look at the presentation
The last thing I look at is the presentation and overall look and feel. I try to make sure that screens have a nice appearance, nice font and that they are consistent. Consider a bulleted list: All items in the list should have a period at the end or they all should not. The fonts should also be consistent. If the headers on one section are 14-point fonts, they should all be that size. This is all a part of making the application look professional.


Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

One method I've had a lot of success with when reporting defects that occur from undesired, unexpected user behavior is phrasing the defect as the result of a user mistake. This deflates the common 'no user would ever do that' argument, because everyone understands that while no one intends to make mistakes, they happen all the time. I find it is especially helpful to enlist the expertise and support of customer service reps when using this argument, since they can easily recognize both common and less common but highly damaging mistakes customers have made in the past.
Hi Carol, Thanks for the tips. A variation of the user mistake that might help when users are employees and the developers want to "just train users not to do that," is the malicious user. If we depend on our users to not do that thing that breaks everything, then what happens when that shady user over in building three gets angry because he doesn't get the raise he thinks he deserves?
The article by Deepa Nallappan claims to have been first published in February 2008, but it is plagiarized from Tom Mochal's column written in March of 2003. See the original here:

The alleged author of this article barely re-worded any of Mochal's original column.
Comment cut off -- I agree that Mochal's insights into testing from the end user perspective are worth noting. I don't fault Nordeen for missing the plagiarism. I only caught it because I am researching a topic and read the articles in rapid succession.