> For the complete documentation index, see [llms.txt](https://vladislaveremeev.gitbook.io/qa_bible/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vladislaveremeev.gitbook.io/qa_bible/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-elektronnykh-pisem-e-mail.md).

# Тестирование электронных писем (E-mail)

Тестирование электронной почты относится к нескольким методам проверки электронной почты перед ее отправкой. Для маркетологов по электронной почте это больше касается анализа контента и кампаний A/B-тестирования. Для разработчиков и QA, которые работают с приложениями, отправляющими транзакционные электронные письма, тестирование электронной почты относится к более широкому циклу действий - от анализа HTML до обеспечения доставки электронной почты.

**Ошибки рендеринга = плохой пользовательский опыт**

К сожалению, не все почтовые клиенты в одинаковой степени поддерживают HTML и CSS. Например, Outlook или приложение Gmail для учетных записей, отличных от Google, не отображают фоновые изображения. Точно так же почтовые клиенты часто имеют определенные рекомендации по разработке электронных писем: Yahoo Mail обеспечивает соблюдение полей, в то время как Gmail обрезает письма, которые длиннее 102 КБ. Поскольку дизайнеры не обязательно заботятся о стандартах рендеринга в широком спектре почтовых клиентов, задача тестировщика - удовлетворить все требования.

Вот почему вам следует сосредоточиться на тестировании кампаний, прежде чем делиться ими с пользователями. В противном случае человек может увидеть ваше письмо обрезанным, со смещенным макетом, не отвечающим на запросы или неподдерживаемым содержанием. В результате плохой UX гарантирован, и есть большая вероятность, что клиенты не вернутся. Если учесть, что вся кампания содержит битые электронные письма, это расстраивает.

**Доставляемость берет свое**

Обеспечение надежного пути между электронной почтой в приложении и конечными пользователями имеет решающее значение для поддержки больших баз пользователей. Поскольку многие команды используют уведомления по электронной почте для обмена паролями и уведомления сообщества об обновлениях продукта, невозможность связаться с подписчиками - серьезная проблема.

Возьмем для примера типичный кейс регистрации на сайте. Какую роль может играть подтверждение e-mail при регистрации?

* Провести double opt-in, т.е. убедиться, что был введён валидный адрес пользователя и этот пользователь действительно дает свое согласие на регистрацию на данном ресурсе и получение дополнительных рассылок/писем. Это позволяет отсеивать "мусорные" регистрации, когда подписывают на что-нибудь посторонних людей (намеренно или нет), уменьшать количество спама (за что очень больно бьют по рукам) и т. д.;
* Для защиты страницы. Если кто-нибудь попытается получить доступ к аккаунту пользователя, то на почту пользователя придет соответствующее уведомление;
* Для быстрого и самостоятельного восстановления доступа (логина и пароля). Многие пользователи испытывают затруднения при восстановлении доступа, если не указали email при регистрации;
* Для отправки необходимой информации и электронного чека после оплаты услуг сервиса;
* Для защиты от ботов;
* Если не подтверждать емайл, то в этом поле можно будет написать все что угодно (в рамках проверки). Соответственно один и тот же пользователь будет регистрироваться множество раз, забывая и свой предыдущий пароль, и логин.

В электронном маркетинге доставляемость электронной почты - это X-фактор, который определяет, может ли пользователь получить доступ к вашему важному сообщению. Критериев, определяющих доставляемость кампании, множество: количество писем, попавших в спам, взаимодействие пользователей с письмами, показатель отказов и другие.

Обеспечение бесперебойной доставляемости - тяжелая работа, и обычно за нее отвечает команда инженеров. QA должен помнить, когда и сколько транзакционных электронных писем отправляет веб-сайт или приложение. Наоборот, спустить все усилия на ветер на удивление легко - нескольких неработающих ссылок или неудачной проверки на спам достаточно, чтобы свести на нет месяцы усилий.

Тестирование доставляемости (Deliverability testing) - это способ предотвратить такие разочаровывающие неудачи, поскольку оно позволяет команде контроля качества:

* избегать спам-ловушек (поддельные электронные письма, рассылаемые интернет-провайдерами по всему Интернету, которые часто сканируются ботами и включаются в базу подписчиков);
* выяснить, какие элементы инфраструктуры электронной почты настроены неправильно (IP-адрес, записи DNS, записи аутентификации электронной почты и т. д.);
* убедиться, что в контенте нет спам-триггеров.

Если QA или разработчик игнорируют проверки на спам и тестирование доставляемости, кампании или важные электронные письма не доходят до конечного пользователя. Как пользователю сбросить пароль или получить ссылку для регистрации, если непроверенное письмо летит куда-то по сети? Из-за недоставленных электронных писем компания может пострадать от потери клиентов и других сбоев в бизнесе.

**Репутация затронута**

Теперь высоко персонализированные электронные письма являются прочной тенденцией. Однако при отправке сообщений, полных динамических тегов, ситуация часто выходит из-под контроля.

Не новость, что получатели получают письма с неправильными тегами имен или темами вроде «Здравствуйте, имя пользователя». Для брендов небольшие оплошности убивают конверсию всей кампании и ухудшают отношения брендов со СМИ. Причина проста: у вас не будет второго шанса произвести первое впечатление. Если вы облажаетесь один раз, подписчики, скорее всего, пометят письмо как спам или оставят отрицательный отзыв. И бренд будет ассоциироваться с отправителями неработающих писем только потому, что кто-то пропустил тестирование HTML/CSS.

**Четыре болевые точки тестирования электронной почты (+ способы их обойти)**

**1. Тестовые электронные письма отправляются реальным пользователям**

Эта досадная проблема возникает из-за того, что группы контроля качества используют рабочие домены для запуска тестовых сессий . В результате легко перейти черту и случайно отправить тестовое сообщение списку подписчиков. Вдобавок ко всему, использование производственного сервера для запуска тестов раздувает объемы отправки для домена и наносит ущерб авторитету домена. Легко убедиться, что вы не отправляете электронные письма реальным пользователям по ошибке, если вы используете отдельную среду для тестирования. Есть два способа безопасно протестировать электронную почту:

* Тестирование среды разработки с использованием API-интеграции;
* Использование инструментов, имитирующих работу реальных SMTP-серверов с возможностью проверки общих SMTP-портов и других элементов инфраструктуры.

**2. Низкая доставляемость (или попадание в спам-папки)**

Если ваши электронные письма с предварительным просмотром попадают в «Спам», это не обязательно красный флаг. Прежде чем предупредить команду маркетинга и перепроверить инфраструктуру, вычеркните следующие возможности:

* В вашем электронном письме для предварительного просмотра все еще есть текст-заполнитель. При отправке тестовых писем убедитесь, что тело сообщения точно такое, какое увидит пользователь. Такие артефакты, как «[Lorem Ipsum dolor](https://ru.wikipedia.org/wiki/Lorem_ipsum)», запускают спам-фильтры и снижают вероятность доставки тестового письма;
* Вы не открываете собственные тестовые электронные письма. Если вы используете свой собственный адрес для проверки электронных писем, если вы не взаимодействуете с ними, интернет-провайдеры пометят письма как неактуальные и начнут отправлять их в спам;
* Адрес отправителя и получателя совпадают. Для успешной доставки электронных писем почтовые клиенты требуют, чтобы адреса отправителя и получателя не совпадали с одним и тем же почтовым ящиком. Итак, когда вы делитесь тестовым сообщением с самим собой, выберите адрес электронной почты, отличный от того, который вы используете для отправки теста.
* Нет ссылки «Отписаться». Пакеты, в которых нет нижнего колонтитула «Отписаться», с вероятностью 99,9 % будут отклонены или будут помечены как спам;
* Добавление скриншота отписки.

**3. Плохой рендеринг и кросс-девайсный отклик**

Еще одним препятствием для проверки качества является обнаружение того, что сообщения отображаются по-разному в почтовых клиентах или типах устройств. Если это относится к вашему тестовому пакету, вот несколько соображений по рендерингу для конкретного клиента, которые вы должны проверить в теле письма:

Gmail :

* Изображения поддерживаются по умолчанию;
* Электронные письма размером более 102 КБ автоматически обрезаются;
* Тег style размещается в заголовке письма;
* Автоматическое масштабирование электронных писем на iPhone (изображения будут казаться смещенными от центра, поэтому лучше указать «padding:0» в body;
* Минимальный размер текста - 10,5 пт для текста и 16,5 пт для заголовков, чтобы обеспечить удобочитаемость на смартфонах.

Outlook:

* Нет поддержки фоновых изображений;
* Нет поддержки интерактивных элементов, таких как формы или флажки;
* Нет поддержки видео HTML5 или GIF;
* Ограниченная поддержка заполнения.

**4. Низкая эффективность тестирования**

Еще в 2000-х тестирование электронной почты было ручным, статичным и утомительным. Команде тестирования нужно было с нуля создавать электронные письма и отправлять их на тестовые адреса. Хорошая новость заключается в том, что в настоящее время большинство этих шагов можно легко автоматизировать.

Вот несколько инструментов, которые помогают QA-командам тратить меньше времени на тестирование отдельных элементов электронной почты:

* Email preview: Litmus;
* Email servers: GMass;
* Email API: Mailosaur;
* Spam check: SpamAssassin;
* Email deliverability: Mail-Tester;
* HTML check: HTML Email Check;
* Browser automation system: Selenium.

Если вам нужно комплексное решение для тестирования, которое позволит протестировать все технические аспекты электронной почты, включая SMTP, API, HTML/CSS, отдайте предпочтение удобным для совместной работы инструментам, таким как Mailtrap .

**Основные элементы электронной почты, которые вы должны протестировать**

Теперь, когда вы знаете, почему нельзя отказаться от тестирования электронной почты, и понимаете, как справляться с основными препятствиями, с которыми сталкиваются группы контроля качества при проведении сеансов, пришло время создать пошаговую стратегию тестирования, которая обеспечит высокую доставляемость и безупречный рендеринг ваших писем.

**1. SMTP-мониторинг**

Ошибки SMTP являются распространенной причиной проблем с доставкой электронной почты или сбоев всей инфраструктуры электронной почты. Вот проблемы, на которые QA должны обратить внимание:

* Брандмауэр блокирует связь;
* Ответ сервера занимает слишком много времени;
* SMTP-сервер подключается с неправильным именем хоста;
* SMTP не поддерживает данные команды.

Чтобы упростить оценку SMTP, группы контроля качества используют специальные инструменты: Web Biz или Wormly .

**2. Тестирование API электронной почты**

Тестирование API позволяет разработчикам тестировать электронные письма, не выходя из среды IDE. Используя API, вы можете:

* Максимально автоматизировать процесс;
* Получать письма в коде;
* Извлекать и проверять содержимое тестового электронного письма;
* Применять сопоставление с образцом;
* Отправлять тестовые письма с вложениями.

Различные языки программирования запускают разные сценарии для тестирования электронной почты API. Чтобы упростить процесс, рассмотрите возможность внедрения таких инструментов, как Mandrill или MailSlurp.

**3. Локальная тестовая отправка электронной почты**

Еще один способ проверить электронную почту - настроить локальный сервер. Таким образом, группы контроля качества снимают нагрузку с производственной среды и отделяют тестирование от реальной кампании. Тестирование электронной почты на локальном сервере - это полезный способ убедиться, что вы не отправляете тестовую партию подписчикам по ошибке. Инструментами, которые следует рассмотреть, являются Mailhog или Mailcatcher .

**4. Доставляемость электронной почты и тестирование на спам**

Как мы уже упоминали, доставляемость электронной почты и тестирование на спам помогают контролировать репутацию вашего домена и IP-адреса и обнаруживать, не занесен ли адрес отправителя в черный список интернет-провайдерами. Mail-Tester или GlockApps могут пригодиться.

Источники:

* [Should QAs care about email testing?](https://theqalead.com/topics/should-qas-care-about-email-testing/)
* [Подтверждать ли email](https://www.rsdn.org/forum/web/6075019.hot)

Доп. материал:

* [Чек-лист. Где нужно тестировать верстку email «руками»](https://vc.ru/marketing/169685-chek-list-gde-nuzhno-testirovat-verstku-email-rukami)
* [10 best email testing tools for optimized delivery](https://theqalead.com/tools/best-email-testing-tools/)
* [A/B тестирование для email писем. 30 идей тестов](https://habr.com/ru/company/sendpulse/blog/299932/)