Monday, November 5, 2007

Test Commonalities: Email

Welcome to part 3 of my Test Commonalities series. In this series we discuss the test areas that come up over and over again across many projects. The goal is to create a good cheat sheet for each so we don't have to recreate the wheel every single time. Today: email.

Email comes up all over applications. It can appear as a login, as a place to send notifications, a place to receive notifications, even a unique identifier for users. In many cases, you'll want to ensure emails are valid. In other cases, you'll want to handle the responses to bounced emails and other trouble.

So, what are the kinds of things we need to test?

  • Email format. Is the email well-formed? Technically, this is covered by RFC2822. However, many mail servers are stricter about what they will accept. Typically, you're looking at allowing some special characters in email: dash ( - ), dot ( . ), plus ( + ). You're also looking at making sure that there is an at symbol ( @ ) and making sure there are characters around it. Don't forget to use special characters right around the @ symbol, which will defeat many email validators.
  • Handling responses. Test how your system handles various responses. What happens if someone replies to an email you send out? How are bounced messages handled? Delivery delays? Often, you'll want the responses to go somewhere so you can get to them.
  • Unique identifiers. Often emails are used as unique identifiers for users.* Test to be sure that an email is unique. Be sure you test across cases to be sure you're not doing case-sensitive comparisons. Also test with an without special characters in emails, since they may be stripped.
  • Comments in emails. It's not uncommon to see emails formatted as user@example.com. This is fine for display, but if you actually need to email users, you will need to find and remove standard comments. Be sure to test for the most common comment formats: all caps separated by dots, delimited by <>, and delimited by ( ).
  • Non-spam format. If your system posts emails anywhere they can be seen or retrieved, consider adding a simple anti-spam helper to them. Simple things like writing out the at symbol ( @ ) will make your users happier without increasing the test burden hugely. More substantial changes are likely to make the testing burden too heavy unless the goal is to render the email unreadable.

This is a case where having a good data set is a great start (I've blogged about that before). To really test emails properly, though, you need to consider both the data and the behavior of the data - not just whether the email is formatted well, but what happens when you send, receive or display it.

* This is actually a really dumb idea, because invariably your users will want to consolidate across email addresses. Email does make for a good login; just be sure you have some other unique identifier to tie your users' multiple emails into a single account.

No comments:

Post a Comment