Phone number fields are without a doubt the most time-consuming thing I have ever tested. This seems so unlikely- phone numbers are standardized to ten digits in the US, so how can they cause so many headaches? The answer is that, as we saw with Zip codes, there are so many ways to get them wrong.
As with Zip codes, it’s important to consider how the phone number is saved to the database. The best strategy for US phone numbers is to strip out any formatting and save the number as just the ten digits. That way the number can be displayed in any way the UI designer deems appropriate.
Next, it’s time to think about how bad phone numbers will be displayed to the user. If a number has been saved with formatting, will it be displayed with that formatting? Will some attempt be made to strip the formatting? Will it be displayed at all? I have seen all kinds of bad numbers in databases. One of my favorites was “dad’s office number”. No one can format that! A good strategy would be to format any ten-digit number by stripping out all of the non-number characters, and then adding in whatever format is desired for display. If the phone number is eleven digits and starts with a 1, the leading 1 could be stripped off and then the number could be formatted for display. With any other values, the “number” could be displayed as-is, or it could not be displayed at all. Whatever is decided, it’s important to test with whatever bad numbers are currently in the database.
Another wrinkle not often considered is phone extensions. Many offices still use extensions to direct a call to a specific person. Sometimes phone fields allow extensions as part of the number, but this is a bad idea, for the same reasons that allowing the user to format their own number is a bad idea. Phone extensions can be any number of digits, so allowing them as part of the phone number means that now the validation can’t expect a specific number of digits. Also, how might the user indicate that an extension is part of the number? Will they enter 800-867-5309 ext. 1234? 800-867-5309×1234? Allowing these types of variations will mean allowing letters and other characters, which it makes it more difficult to validate. A far better solution is to include a separate field for an extension. If your developer expresses interest in including the extension as part of the phone field, some testing with entries like 8008675309extextext…1234 will probably dissuade them.
Finally, remember to test editing phone numbers, especially numbers that are in an incorrect format. What will happen when the user has a phone number like 800-867-530 and tries to edit another field on the form? Will they be notified upon saving that the number is incorrect and needs fixing? This can be a good way to involve users in cleaning their own data. What should happen when the user tries to fix an invalid number? Ideally they should be able to save the value with a new valid number.
I hope that this post has emphasized the importance of having good phone field validation. If you are fortunate enough to be testing a brand-new application with an empty database, taking good care to ensure that only valid phone numbers are saved to the database, you will prevent many testing headaches in the future!
This post only tackled United States phone numbers. In my next post, I will take on the even greater challenge of international phone numbers!