Software Testing Blog

User login failures – why do they occur and how can testers spot them beforehand? That’s the latest subject of our Guest Blogger series. Addressing the topic is veteran uTester Sherry Chukpa of Pittsburgh, Pennsylvania. A married mother of three teenage sons, Sherry began her software testing career back in 1998 after obtaining a degree in Applied Science. Aside from being a full-time tester, and an active member of the uTest community, Sherry is also a prolific testing blogger. You can read her blog or you can follow her on Twitter. Either way, testers should be listening carefully to her advice. Enjoy!

This article lists some of the scenarios that cause user login failures. It is my hope that this will give you some new ideas when building future test cases.

What happens if the ODBC Data Source is configured using the incorrect driver version? For instance, I tested an application that was an add-on module to a web application. The add-on module required the Native SQL Server driver. The web application had its own ODBC Driver. The add-on module did not handle names containing spaces if it connected using the web application’s ODBC Driver instead of the Native SQL Server Driver.

What if there is more than one ODBC Data Sources configured to use the same name (one under System DSN and one under File DSN)? I once saw an application that displayed the ODBC Data Source names in a drop down list. The program would only show one of the Data Sources if there was more than one DSN using the same name. You could not be sure which database the program was connecting to.

Does the software handles DSN names containing special characters? The data source name may accept special characters that the application does not handle correctly. Some languages use the ampersand (&) symbol to underline the accelerator key or keyboard shortcut in a menu. The ampersand symbol might be displayed as an underline.

Is the program using the 32-bit registry or the 64-bit registry? The application may require the DSN to be configured using the 32-bit version of the ODBC Administrator. In Windows Vista you can add a shortcut to the 32-bit ODBC Administrator utility with a target of “C:\Windows\SysWOW64\odbcad32.exe” and Start In directory “C:\Windows\SysWOW64”.

What happens if the database user does not have the correct permissions on the database objects? The RDMS will generate a failure, but does the application handle it correctly?

What happens when the program tries to connect using an incorrectly encrypted connection string? The connection string may be stored in plain text in the app.config file instead of being encrypted. The connection string will need to be encrypted again if it was encrypted on another machine or if it was encrypted using a different provider.

Are usernames and passwords of the maximum length handled correctly? I have seen forms users where it stores an encrypted password, but encrypted value is truncated. The maximum length of the password string in the database table is 50 characters and the maximum length on the form field is also 50 characters. After the 50 character value is encrypted it will not fit in the table and is truncated.

Some other questions to ask: What does the application do if it requires a certain service pack on the database server? What happens if the database server is unavailable? What does it do if the incorrect version of the .NET Framework or some other extension is not found?  The most obvious question is it even using the login credentials or are they being bypassed with default values? Does the application work correctly if the usernames and passwords are changed from the defaults?

So the next time you’re struggling to diagnose a user login failure, be sure to ask yourself a few of these questions. I’m always looking for fresh perspectives on testing, so if you know of any other user login tips that I may have missed, be sure to leave me a comment.