I am not a Web development guru. Although I have been in development management for a long time, I began my career as a developer. When I can, I try to help out in the development process, particularly when I think I can provide value through my knowledge of testing online client-server and Web applications.

After the developers have completed their tests, I typically review their work for two reasons. First, I want to be able to talk intelligently with the client about what the application looks like and how it behaves. Second, I want to see if there are any obvious errors that can be corrected before the client sees the results.

I know it is frustrating for my developers to have me in the middle. This frustration is not because I am a bottleneck, since I try to turn around my testing within a day after the developers tell me the application is ready. What really frustrates them is that they can test and test the application and think they’ve found everything. However, usually within 30 minutes after I start, I end up with a page of notes that describe things that I have questions on or things that don’t seem to work right.

This testing strategy usually frustrates me as well. Sometimes I wonder how developers can say that the application is ready when they have neglected to find items that I find in a few minutes. However, in general, the errors are usually caused by a lack of testing sophistication. The developers are focusing on proving that the application works correctly. I tend to see if I can break it from a user’s perspective. I also tend to look for inconsistencies and a lack of intuitiveness that I think reflects the user experience.

Proving the application is correct
There are a number of different aspects to testing. One desire is to prove that the final product meets the agreed upon requirements. The test, done in two parts, requires the tester to make sure that all of the required features and functions are present and accounted for. Then, make sure that the features and functions behave as expected. There is nothing wrong with this type of testing. But you should go further.

Trying to break the application on behalf of a user
The place that a lot of developers fall short is that they test based on the way they expect the user to react. They do not give enough thought to testing off the beaten path. For instance, let’s say you have a Web application with a lot of online processing. If the first screen asks for a userid and password, I will start off by entering no values and see what happens. Did I get in? Did an error occur? In some cases, does the screen just sit there? Instead, 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 like “(*&%$’. It’s amazing to me how many times the application will have problems. I run through all of the rest of the fields the same way. If the field contains a drop-down list, I will try to type a value in instead. If certain fields are prepopulated, I will change them. If some values are database keys and need to be left alone, I will change them. I also try to overflow every field by adding as many digits or characters as the screen will allow. Then I click on the available buttons and links and see what happens.

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

Why would a user type in special characters in a field expecting numeric input? The point is that they probably wouldn’t, intentionally. However, keying mistakes happen all the time. If you present a numeric field to a user, the chances are that over time, miskeying will result in any character being entered into any field. I figure I might as well try to catch them now, rather than have a Web application blow up on a user later.

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. If you place a period at the end of some items in a bulleted list, for instance, they all should have the period. Or else they all should not, depending on your editorial conventions Likewise, the fonts should 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.

Be prepared for the worst
In a number of groups I have managed, the developers did a great job of ensuring that their applications worked as specified. In many cases, though, they did not do enough testing from a user perspective. The focus should be on ensuring that the application is foolproof. The users will maneuver around the application as you expect 90 percent of the time. However, one time out of 10, they will do something screwy. When that happens, your application needs to handle the situation gracefully and successfully. You don’t want to have a great application that blows up the first time the user enters a 12-digit Social Security number instead of a nine-digit number. Make sure you test to confirm that your application works as advertised. However, also test as many combinations of the unexpected as possible. You need to make sure that there is no combination of faulty data or faulty process flow that ends up with the user getting any kind of unexpected system messages.