Pesky Bugs

Some bugs keep popping up in project after project.  It’s important to catch these sneaky bugs before they get into a production system.

In the past, in a one month period, I caught three separate bugs that occurred due to improper handling of special characters.  This type of bug can be easily missed if the test team isn’t specifically looking for it.

Culprit 1 – <

The innocent less-than sign is usually used for good.  However, it can be a menace when it falls into the wrong hands.  It can be used to send malicious executable scripts into systems from web pages.

Our program screened out HTML characters from the main entry screen by design.  So, we didn’t expect to have any problems.  However, it turned out that a portion of data in the system was imported from a spreadsheet rather than entered through the data screens.  When the user tried to use a feature that created a new record from an existing record, the system failed.  With a little digging and changing the settings that determine how the error messages are displayed, we identified the error.

Of course, this brings up an additional issue of how to handle data imports to screen out data that would fail the validation rules, but that’s a discussion for another time.

Culprit 2 – ñ

Of course, any site that accepts names should be sure to accept the letter ñ.  In my experience, this letter typically hasn’t caused a problem, but it did cause a problem on a recent project.  We built a system where people could set up a secure profile that included their name.  The name and some other information were then sent to a third party that would send a welcome e-mail.  Because we utilized Embedded Quality, we tested profile creation early, which included testing names containing ñ.  Everything worked fine early on.

In a later round of testing, the ñ started causing an error.  As we dug into the problem, we found that the issue was that the 3^rd party e-mail system could not understand the Unicode representation of ñ.  Instead, the 3^rd party expected this character to be in UTF format.  Once we realized that, we were able to convert the format of the characters before sending them to the e-mail vendor. 

Culprit 3 – : )

On the same project, we encountered an error that became known as the “smiley face” bug.  This bug was not found until user acceptance testing, which is much later than I like to find bugs.  In this case, we had tested online profile IDs that contained every acceptable special character without a problem.  However, we did not specifically test the situation where the profile ID ended with a smiley face emoticon.  When one user created an ID of janed:), the profile creation failed.

It turned out that the expression in code that checked for a duplicate profile ID before creation could handle any special character except for a single, right parenthesis.  It interpreted that character as part of the expression, and caused a failure.

Summary

Encountering these 3 special character errors within a one month period reminded me of how important it is to test for every special character before going live.  The experience validated my general rule of “if the system allows it, the users will do it.” 

Have any of you found bugs due to special characters?  Have any made it into production?  If so, what was the consequence?