HTML markup

Чек-лист QA

Задачу сверстать html письмо каждый решает более удобным для него способом, можно отдать верстальщикам внутри своей компании, заказать фрилансерам или обратиться в маркетинговое агентство.

Наступит этап приема работы и возможно вы сами, специалист QA, маркетолог, Project Manager приступит к беглой или внимательной проверке выполненной работы.

Возникнет вопрос с чего начать и что проверять?

Предлагаем вашему вниманию универсальный чек-лист QA для проверки html писем. Следовать всему списку или только определенным пунктам вы решите самостоятельно.

1. Проверяем Pixel Perfect.
2. Проверяем выполнены ли все требования к проекту.
3. Проверяем адаптивное перестроение контента в браузерах.
4. Проверяем письмо на html валидаторе.
5. Проверяем орфографические ошибки в тексте.
6. Проверяем вес html файла и изображений.
7. Проверяем нет ли лишних изображений в папке с письмом.
8. Проверяем правильно ли использован PNG или JPG формат.
9. Проверяем названия изображений, удобны ли они для работы.

10. Добавляем в заголовки больше текста, смотрим на межстрочный интервал.
11. Добавляем текст в блоки, смотрим на поведение рядом стоящих элементов.
12. Добавляем новые ссылки по всему письму, проверяем стилизацию глобальных ссылок и цвет ссылок в блоках с разным фоном.
13. Добавляем текст в кнопки, они должны тянуться и иметь полную кликабельную область.
14. Делаем рассылку на все интересующие вас почтовые сервисы, открываем почту на мобильных устройствах.

15. Удалены ли лишние классы.
16. Удалены ли лишние символы.
17. Удалены ли лишние css стили.
18. Удалены ли лишние html атрибуты.
19. Удалены ли лишние html вложенности.

20. Хорошо если html код имеет читаемое оформление.
21. Хорошо если в коде присутствуют html комментарии.
22. Хорошо если логотипы и иконки имеют альт-текст и стилизацию для него.

Заказывая вёрстку письма, требование Pixel Perfect должно выполняться по умолчанию. PP считается выполненным, когда открытое письмо в браузере совпадает пиксель в пиксель с PSD макетом, проверяется это очень легко с помощью плагиннов, в интернете доступно множество информации на эту тему. Если присутствуют расхождения с дизайном, верстальщик должен дать развернутый ответ причины несовпадения, обычно о них должны предупреждать еще на этапе ознакомления с дизайном.

HTML markup

Давайте немного отвлечемся и расскажем вам как должно выглядеть нормальное тестирование, насколько это важный этап в разработке любого html письма.

Команда существует около 8 лет, почти с самого начала мы поняли, что сервисы типа Litmus или Email on Acid нам не подходят, беспокоила периодическая погрешность в отображении, медленная скорость, результат отображения выдавался в виде изображений и т.д.

Решили перенять опыт зарубежных коллег StyleCampaign, сделали собственную тестовую зону, собрали четыре Windows машины с аутлуками и не только, поставили Mac, приобрели необходимые мобильные устройства. Пока наши конкуренты сидели на сервисах, мы в свободное время от коммерческих задач занимались исследованием новых конструкций, методов email вёрстки и особенностей отображения сложных писем в почтовых клиентах, в какой-то момент поняли, что ребята в блоге Litmus пишут о новинках, которые мы освоили еще год назад, а по нестандартным перестроениям до сих пор нет информации, клиенты были восторге, но об этом в другой раз. А еще отдельное место для тестирования позволяет свободно подойти и никому не мешая выполнить проверку :)

По нашим стандартам письмо проходит три этапа тестирования. За первую проверку по всем пунктам чек-листа QA отвечает email верстальщик письма, далее он передает код свободному email верстальщику на перепроверку 3, 15-19. После этого к работе подключается QA специалист, чтобы свежим взглядом проверить все пункты кроме 15-19, но при необходимости готов выполнить и их, так как владеет базовыми знаниями вёрстки html писем. Если замечаний нет, то проект можно готовить к передаче заказчику и спокойно ожидать подтверждения приема работы.

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

Можем рассмотреть несколько ошибок поближе.

Ограничились стандартной реализацией фона — прощай фон в ауткуках.
смотреть пример

Пропустили всего один символ в стилях для текста — получили обнуление.
смотреть пример

Не поставили вертикальное выравнивание в колонках — текст живет своей жизнью.
смотреть пример

Забыли о глобальной стилизации ссылок — синий цвет наш новый друг.
смотреть пример

Оставили атрибут width пустым — ширина колонок в ауткуках уплыла.
смотреть пример

Не проверили Gmail app — а там что-то поломалось.
смотреть пример

Fail от Litmus — вёрстка не по зубам Thunderbird.
смотреть пример

Печальный список можно продолжать долго, просто берегите свои письма от багов.

Планируем периодически обновлять статью.