If I were to be given three wishes for the world, my third wish (after world peace and ending world hunger) would be to standardize international phone numbers, because testing them is so complicated! Let's take a look at some phone number patterns from around the world:
Phone numbers are ten digits, plus an area code of either two digits or three digits. So the local number will be either twelve or thirteen digits.
Landline numbers are generally nine to eleven digits, but some can be as short as six. Mobile numbers are usually ten digits, but there are also some nine-digit numbers.
Telephone numbers in Japan have an area code, an exchange number, and a subscriber number. Area codes can have between two and five digits. Generally the length of the entire number is limited to nine digits, so if the area code is longer, the exchange and subscriber numbers will be shorter.
Now let's think about international calling codes. Calling codes can range from one digit (such as the US's +1) to three digits (such as +351 for Portugal). So between the international calling codes and the phone number itself, there is a wide range of the number of digits that might be expected for a phone number.
Finally, let's think about number separation. While US numbers are always separated in a 3-3-4 pattern, in other countries the numbers can be grouped in various ways. Here are just some of the ways that phone numbers are grouped in England:
(xxx) xxxx xxxx
(xxxx) xxx xxxx
(xxxx xx) xxxxx
Therefore, it is extremely difficult to validate on whether the pattern of numbers, parentheses, and dashes entered by a user is correct.
So how on earth are we to validate international phone numbers? The most important thing to do is to make sure that the developer doesn't try to come up with a validation regex on their own- that will make them (and you) go crazy! Fortunately an international phone number formatting standard called E.164 has been developed. Many companies such as Microsoft and Google have come up with regex patterns that can be used for E.164 validation. For testing, there are free websites that will let you know if an international phone number is valid. Most of these sites will require some sort of registration. You can come up with a list of international numbers to test, verify with the website to see if they are valid, and then try them in your application. For negative testing, simply use a sampling of invalid numbers and verify that you get an appropriate error message.
What format should a user use when entering in their phone number? Some users might want to put parentheses, spaces, or dashes into their number. Then there is the plus sign, which is used to indicate a country code. For simplicity's sake, it would be best to expect nothing but digits and a plus sign. It would also be good to prompt the user for what format the application is expecting. For example, in the United States you might have a message such as: "Enter your phone number with no dashes, parentheses, or spaces. For numbers outside the US, a plus sign (+) and the country code should be used." Then for validation, if the number does not have a plus sign, simple US number validation rules can be applied, and if the number does have a plus sign, international validation rules can be applied.
Similarly, you may want to store the number in the database with the plus sign, to indicate that the number is an international one. How should the numbers be displayed when retrieved in the application? For many countries it's nearly impossible to know how the numbers should be spaced, unless the validation code you are using returns that to you. If your country has a standard number formation, you can display the number in that standard. If your country does not have a standard formation, or if you are displaying a number from outside your country, you can simply display the number as is, such as: +442073238299.
When it comes to international phone numbers, there really are no easy answers, which is why I am wishing for world standardization! There are other ways to (mostly) solve the problem, such as 1) expecting only between 6 and 20 digits, not validating the number beyond making sure that it's within that number of digits, and displaying the number as entered, or 2) having a separate field for the country code, validating the number for that specific country, and formatting the number according to that validation. What is most important is that you communicate closely with the developer to decide on a clear strategy and test it accordingly.