Тестирование электронных писем (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», запускают спам-фильтры и снижают вероятность доставки тестового письма;
Вы не открываете собственные тестовые электронные письма. Если вы используете свой собственный адрес для проверки электронных писем, если вы не взаимодействуете с ними, интернет-провайдеры пометят письма как неактуальные и начнут отправлять их в спам;
Адрес отправителя и получателя совпадают. Для успешной доставки электронных писем почтовые клиенты требуют, чтобы адреса отправителя и получателя не совпадали с одним и тем же почтовым ящиком. Итак, когда вы делитесь тестовым сообщением с самим собой, выберите адрес электронной почты, отличный от того, который вы используете для отправки теста.
Нет ссылки «Отписаться». Пакеты, в которых нет нижнего колонтитула «Отписаться», с вероятностью 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 могут пригодиться.
Источники:
Доп. материал:
Last updated
Was this helpful?