A text field with a postal code looks so simple, and yet it can be one of the most complex things to test on a form. There are two important questions to ask before you start testing postal codes:
1. What countries does our application support?
2. What formats will we be accepting for the postal codes?
It always comes as a bit of a relief when I find out that the application I am testing will only be supporting US Zip codes. Zip codes traditionally come in a five-digit format, such as 10012. But there are also Zip +4 codes to consider, such as 10012-1234, and this is where the second question comes into play. Will the application be accepting Zip +4 codes? Will it be requiring the hyphen between the first five digits and the next four digits, or will a space be accepted as well? What about just nine straight digits, with no hyphen or space in between? If nine straight digits will be accepted, it’s important to also verify that 6, 7, and 8 digits will not be accepted.
And there is another very important thing to test with US Zip codes: the leading zero. There are many fields which will strip leading zeros off of a number upon submission. It’s very important to submit some Zip codes with leading zeros and verify that they have been saved correctly to the database.
The next likely postal code type you may encounter (if you are based in the US) is the Canadian postal code. All Canadian postal codes are six characters in this pattern of letters and numbers: A1A 1A1. It’s important to clarify with the developer whether the space between the two groups of three characters will be expected, or whether you can submit the code with no space. Hopefully the validation will expect the correct letter-number pattern, and will reject postal codes like 1A1 A1A.
What if your application expects both US and Canadian postal codes? If this is the case, the third important question to ask is:
3. Will there be a separate validation pattern for each type?
If there is a separate validation pattern, the code may first look to see what country the address contains, and then use the appropriate validation. In this case, it’s a good idea to test that you can’t choose “United States” for your country and then add “A1A 1A1” as the postal code. Or the validation pattern may be chosen by the number of characters submitted. If six or seven (including the space) characters are submitted, a Canadian validation pattern could be used. If five, nine, or ten (including the hyphen) characters are submitted, a United States validation pattern could be used. Understanding what validations the developer is using will allow you to craft appropriate test cases. For example, in a scenario where only US and Canadian postal codes are used, there should never be a scenario where eight characters are accepted.
When we move into postal codes for other countries, things can get more confusing. Many countries have five-digit codes, which are easy to validate. Other countries, such as Russia, have six-digit codes. But consider Great Britain, which has postcodes in two sections: the first section can have between two and four characters, and the second section always has three characters. There is a space between the two sections, and the postcode will always start with a letter, not a number. In this case, it’s best if the developer has ways to recognize if a British postcode is being used (perhaps by looking at what country has been entered in the form) and uses a separate validation regex for those codes. For testing, be sure to try several different valid postcodes from various places in Great Britain, with two, three, and four characters in the first section. You can also test with codes that have the right number of characters, but have the space in the wrong place, or with a code that has a number as the first character.
Finally, remember to check that the valid postal codes that you have submitted have been saved correctly to the database, and remember to verify that retrieved postal codes are displaying correctly. Also be sure to check that any invalid codes in the database (that may have been added before the correct validation was in place) are displaying as added, or not at all, and that it’s possible to edit both invalid and valid postal codes.
I hope that this post has helped you see that postal codes are not as simple as they seem! Asking the three questions listed above can help you and your developer to recognize potential issues even before testing has begun.