Skip to main content
Article is devoted to the testing of email clients and other software that processes emails. In particular, this article discovers the possible methods of verification of mail messages that are processed by the tested application. Messages are checked for the correctness of their representation and for the standards compliance.
There are many various peculiarities of formatting, displaying, and storing of email messages, so the tester should take into account all these nuances for the definite class of products.
The main attention will be paid to the check of the displaying of email messages, their parameters and properties. Also the attention will be paid to the verification of other record types, i.e. contacts and tasks.
Contents:
Introduction
So what is the email message and what parts does it consist of?
Internet message is a document that consists of three main parts: “wrapper”, header, and message body. The user sees only the header and the message body. The message “wrapper” contains information that is required by delivery programs.
While testing applications that deal with email messages, there is a necessity to compare the structure of the sent message with the structure of the received message on the recipient side. Besides, it is necessary to take into account the requirements and standards of mail messages in the RFC822 document. This document describes all requirements for messages that are sent by the SMTP protocol. It also describes the format of messages.
Mail client or viewer? No matter what to test
The message should correspond to the source message and should not “lose” its properties while its displaying and viewing, irrespectively of the fact if it was downloaded directly from the mail server or imported from the mail database.
We can distinguish two main types of mail applications:
- Viewers – perform import or export of messages that were saved locally and also perform viewing of messages (often of various formats);
- Mail clients – perform sending/delivering messages from the mail servers, storing, and viewing of messages. Mail clients also provide some additional features of the organization of the mailbox structure.
All these applications have a common feature: they store messages locally in some data structure and let viewing them as a document that includes the message text and the system information about the message. No matter what the aim of the application is, it must display the source data correctly. On its basis, we can create a set of tests that will be applied for most programs, which work with messages.
The mail message
The main object of our research is, of course, the mail message. Namely, we will examine the message structure, its main properties, and also fields and formats of its representation.
The structure of the mail message includes 3 parts: the “wrapper”, the header, and the message body.
The wrapper includes information that is needed by the delivery programs, such as the sender and recipient addresses. The wrapper is invisible for the user but its contents can be duplicated in the message header.
The message header is the system information about the message, which includes the addresses of the senders and recipients, additional address fields, information about mail servers that it passed through, and also the message status and priority.
The message body includes transferred user data (text, images), i.e. information for which the message is actually sent.
MessageID is the unique message identifier that is assigned to the message by the sender node automatically.
- We can verify the value of this field by getting access to the mail server and comparing the corresponding value with the one stored on the server;
- We should be attentive while checking this field value to not mix up it with the similar message identifier, which is assigned to the message by the mail client itself (InternetMessageID ≠ ClientMessageID);
Date field contains the date when the message was sent. The field value is defined automatically by the mail client while sending the message. For the group of fields representing the time of some event (receiving, sending, or creating of the message), we can do the following:
- Check the correctness of displaying of the date of message receiving with the regard to the time zone, when the message sender is located in another time zone;
- When checking, we should pay attention to the time boundary values, i.e. when the displaying of the time in other time zone includes the date change. For example, the message that was sent on 31.12.2009 at 23:00:00 in UTC-06:00 time zone to the recipient in UTC-04:00 time zone should has the date of sending equal to 01.01.2010 01:00:00;
- As an alternative, the time can be displayed in the UTC format that helps to display the time in the “correct” format without additional conversions;
From field contains the sender address, i.e. the address of the message author. If the message is forwarded to another recipient, this field will contain the address of the initial message author.
To and Cc fields contain the addresses of the message recipients. Cc field contains the addresses of additional message recipients.
- At least one of the To and Cc fields should be filled. To check this requirement, it is necessary to send messages with the following data combinations in the fields:
| To | Cc | Expected result |
| Not filled | Not filled | Not acceptable |
| Not filled | Filled | Acceptable |
| Filled | Not filled | Acceptable |
| Filled | Filled | Acceptable |
- In the recipient filed, it is allowed to set the target list of recipients that are separated with commas. The number of commas before and between the addresses does not play any role. To check the correctness of perception of such “null” commas, we can perform the following test: send the message with the filled “Sender” field as follows:
To: “ , , [email protected], , , [email protected], , , “.
As a result, the message should be sent successfully. When receiving this message, only the recipients without “null” commas between them should be displayed.
The message body can be displayed in three formats: Plain Text, Richtext, and Html.
Plain Text indicates that the message body contains the text.
Richtext defines the text with embedded tags that influence the text displaying (for example, <bold>Now</bold>).
Html is the format of hypertext documents. It also defines the text with embedded tags. But besides the text formatting tags, it includes tags that describe the hyperlinks (<A HREF=”test.html”>This is an example</A>).
To check the message formats, we can create one test message that will contain the possible text formatting, attached images, hyperlinks (images as the hyperlinks). When viewing such message, a number of rules and limitations for each format should be followed:
- Plain Text. The message body in the Plain Text format should contain nothing but the text. As a result, when viewing such message, the text formatting should disappear and the hyperlinks transform into the plain text. Images in the Plain Text format should be displayed as the attached files. Managing tags in the Plain Text format should not be displayed as a text and should not define the text format.
- Richtext. The message body in the Richtext format should preserve the formatted text representation (font, size, style, color, text aligning). All this should be preserved when forwarding the message and viewing the message in the RTF format.
- In the Html message format, first it is necessary to check the work of hyperlinks, namely the link to another part of the same document, a link to the external Internet resource, and also a link represented by an image.
Attachments
The mail message allows sending attached files of different formats along with the text data. To check them, first, it is necessary to pay attention to the integrity of the sent files.
- The easiest way to check the integrity of data is to check file checksum (CRC). We should compare the checksum before and after the file sending. If it is the same, we can be sure that the file is not distorted while message sending/receiving.
- Along with standard formats, the mail message can also be the attached file. We should check the possibility of the program to display such message as an attachment but not as a part of the message.
Additional records: notes, reminders
Mailstorages also contain some specific catalogs that store various notes, tasks, and user account contacts.
The structure of the records data differs from the one of mail messages, that’s why we should pay attention to the following aspects while checking their correctness:
- Check the text fields (subject, description) for the correctness of text representation in different encodings. To do this, we can create a number of notes and in each of them some definite encoding should be used for all fields. The diversity of the checked encodings directly depends on the specification of the tested application and the target region of deployment.
- Check of the date fields for the adequacy of date/time according to the system settings. When changing the time displaying format, the program should adjust to the new system settings. E.g. after changing the time format from 24-hour to 12-hour with specifying AM and PM, we can see the program reaction to the change of time.
- Check of the priority and the color group of the event. Nearly every record in the mailstorage can be assigned a low, normal, or high priority, and also some definite color group. To check them, we can create three messages with different priority. Two messages can get some color labels and the third can be without the color group.
Checking the address book and contacts fields
We can check the correctness of displaying of several address books. To do this, we can create two address books in the same mailstorage with several addresses in each of them. When importing and viewing such mailstorage, there should be no situations of the address book loss or merging of all addresses in one address book.
- Address books may contain the mailing groups that include the list of addresses. We should check if the message, which is sent to a group of recipients, is delivered to everyone, because there can happen the following:
- Only the first and the last address from the list are processed;
- The name of the list is taken for the recipient address;
- Invalid program recognition of address separators can involve the mess in addresses.
- Several contacts with identical names and mail addresses cannot be created in one address book. So, in situation with already existing mail address, the program should response with the proposal to change or update the record fields of the given contact;
- One contact may contain several mail addresses and each of them should not be “lost”;
- There may be user groups in address book that, in their turn, may contain other subgroups, so forming the group hierarchy. In this case, we should check the name of the group, its location relative to other groups;
Import of mailstorages and messages
Mailstorage is a structured local storage of messages or mailboxes with the preservation of their structure and properties, so providing the possibility to work with messages locally. Different mail clients can create mailstorages in different formats, and so there is a neccessity to import mailstorages from different formats. When importing the mailstorage to the tested application, it is necessary to pay attention to the specificity of the file structure as well as to the logical structure of the element arrangement within the mailstorage.
Physically, the mailstorage can represent a set of files that contain message data, additional elements data, configuration files data, etc. The mailstorage can be also represented as one data file that contains all information, messages, and message attachments.
Logical structure is the arrangement and the displaying of mailstorage folders and messages within them.
To check their structure, we should perform the following tests:
- Import mailstorages that are stored as a data file and as a file catalog. While importing the mailstorage from the directory, we can check for the possibility of the recursive search of the mailstorage in subdirectories.
- Check the possibility of importing several mailstorages and also the correctness of their separation, i.e. import the mailstorage after one mailstorage is already added. In this case, if their structure is the same, all data from the directories should be updated and complemented with messages from the imported mailstorage. We should pay attention to adding duplicated messages. In this case, the program should make it possible to rewrite messages or cancel their import.
- A separate test should be performed for the import of the mailstorage backup copy that was created by the tested e-mail client itself. In this case, all messages and the account settings of the e-mail client should be fully recovered.
- When checking the folder vstructure of the mailstorage, we should not forget that besides the standard folders (such as inbox, outbox, sent), there can be created custom user folders. To check them, we should create folders in the mailbox root as well as some subfolder, which includes a pair of its own subfolders. Then, we should create and save several messages in one of these subdirectories. Such structure should be preserved while viewing the mailstorage and also while importing the mailstorage with modified catalog structure. We should pay attention to the fact that messages in attachments and empty catalogs are not lost.
- Besides the import of the entire mailstorage, there should always be a possibility to import a separate mail message. Test can be performed on standard message files, such as EML or MSG files.
MIME standard for the check
MIME standard defines the format of the data transferring with different types of contents in the mail messages. To check the correctness of the message format, we should compare the information defined in the message header. During the message exchange, the data is divided into 7 types: Text, Multipart, Application, Image, Audio, Video, and Message.
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1251
- To check each type of data and the correctness of its displaying in the MIME header, we can create a message that will contain an attachment of the definite type.
- Multipart type contains several parts of different types (for example, text together with an image). That is why, for its check, we should create a message that will contain several types of files. Ideally, we can add all 7 types of files, mentioned above.
Conclusion
When testing applications that work with mail messages, we should understand the specificity of the application itself as well as the common standards of mail messages. The compliance with such standards plays a great role in the quality and validity of the information transferred by the application.
And the diversity of data, formats, and representations of the information in the mail messages provides a field of action for testers…
