QA_Bible
  • Введение
  • FAQ для новичков
    • Ответы на самые популярные вопросы новичков в чатах
    • Качества и навыки, которыми нужно обладать тестировщику?
    • Что должен знать и уметь Junior? Что спросят на собеседовании?
    • С чего начать обучение и куда развиваться?
    • Как составить резюме?
    • Где искать работу?
    • Как происходит процесс найма?
    • Как проходить собеседование?
    • Начало работы Junior-тестировщика
    • Ошибки в работе у начинающих тестировщиков
    • Как взаимодействовать с коллегами?
    • Перспективы профессии
  • Полезные ссылки
    • Список полезных ресурсов на разных платформах
    • Список ресурсов по инструментам тестировщика
  • Общее
    • QA/QC/Testing
    • Почему требуется тестирование ПО?
    • Качество ПО (Software Quality)
    • Принципы тестирования
    • Верификация и валидация (Verification and Validation)
    • Дефекты и ошибки
    • Серьезность и приоритет Дефекта (Severity & Priority)
    • Альфа- и бета- тестирование (Alpha Testing and Beta Testing)
    • Процесс тестирования (test process) (draft)
    • Техники оценки тестов/оценка трудозатрат на тестирование (Test Estimation)
    • Экономика тестирования/стоимость качества (Cost of quality)
    • Подход к тестированию (Test Approach)
    • Импакт анализ (анализ влияния, Impact Analysis)
    • Анализ первопричин (RCA - Root Cause Analysis)
    • Тестирование со сдвигом влево (Shift left testing)
    • Модель зрелости возможностей (CMM - Capability Maturity Model)
    • Тестовая среда и тестовый стенд (Test Environment/Test Bed)
    • Бизнес-логика (Business logic)
    • Политика отсутствия багов (ZBP - Zero Bug Policy)
    • Независимое тестирование (Independent testing)
    • Роли/должности в команде
    • Эвристики и мнемоники
  • Виды-методы-уровни тестирования
    • Методы тестирования (White/Black/Grey Box)
    • Тестирование методом черного ящика (Black Box Testing)
    • Тестирование методом белого ящика (White Box Testing)
    • Тестирование методом серого ящика (Grey Box Testing)
    • Статическое и динамическое тестирование (Static Testing, Dynamic Testing)
    • Пирамида / уровни тестирования (Test Pyramid / Testing Levels)
    • Модульное/юнит/компонентное тестирование (Module/Unit/Component testing)
    • Интеграционное тестирование (Integration testing)
    • Системное тестирование (System Testing)
    • Приемочное тестирование (AT - Acceptance testing)
    • Основные виды тестирования ПО
    • Функциональное тестирование (Functional/Behavioral testing)
    • Нефункциональное тестирование (Non-Functional testing)
    • Тестирование производительности (Performance testing)
    • Тестирование емкости (Capacity testing)
    • Нагрузочное тестирование (Load testing)
    • Стрессовое тестирование (Stress testing)
    • Тестирование масштабируемости (Scalability testing)
    • Объемное тестирование (Volume testing)
    • Тестирование выносливости/стабильности (Endurance/Soak/Stability testing)
    • Тестирование устойчивости (Resilience testing)
    • Тестирование надежности (Reliability Testing)
    • Тестирование на отказ и восстановление (Failover and Recovery testing)
    • Эталонное и базовое тестирование (Benchmark and Baseline Testing)
    • Тестирование хранилища (Storage testing)
    • Одновременное / многопользовательское тестирование (Concurrency/Multi-user testing)
    • Тестирование сервиса (Service Testing)
    • Тестирование безопасности (Security and Access Control testing)
    • Оценка уязвимости/защищенности (Vulnerability Assessment)
    • Фаззинг-тестирование (Fuzz testing)
    • Можно ли отнести тестирование безопасности или нагрузочное тестирование к функциональным видам тести
    • Тестирование совместимости/взаимодействия (Compatibility/Interoperability testing)
    • Конфигурационное тестирование (Configuration testing)
    • Инсталляционное тестирование (Installation Testing)
    • Тестирование на соответствие (Conformance/Compliance testing)
    • Тестирование удобства пользования (Usability testing)
    • Тестирование доступности (Accessibility testing)
    • Тестирование локализации, глобализации и интернационализации (Localization/ globalization/internatio
    • Исследовательское тестирование (Exploratory testing)
    • Свободное / Интуитивное тестирование (Adhoc, Ad-hoc Testing)
    • Тестирование поддержки (Maintenance testing)
    • Регрессионные виды тестирования (Regression testing)
    • Тестирование клиентской части и серверной (Frontend testing Vs. Backend testing)
    • Тестирование графического интерфейса/визуальное тестирование (GUI - Graphical User Interface testing
    • Тестирование API (API - Application Programming Interface)
    • A/B тестирование (A/B Testing)
    • Деструктивное и недеструктивное тестирование (DT - Destructive testing and NDT - Non Destructive tes
    • Выборочное/хаотическое тестирование (Random/monkey testing)
    • Тестирование рабочего процесса/воркфлоу (Workflow testing)
    • Тестирование документации (Documentation testing)
    • Как протестировать продукт без требований?
    • Кроссбраузерное тестирование (Cross-browser testing)
    • Тестирование, основанное на рисках (Risk-Based Testing)
    • Разница тестирования ПО и железа (Software Vs. Hardware testing)
    • Тестирование качества данных (Data Quality Testing)
  • Тест дизайн
    • Тест-дизайн и техники тест-дизайна (Test Design and Software Testing Techniques)
    • Static - Reviews
    • Static - Static Analysis
    • Dynamic - White box
    • Dynamic - Black box
    • Dynamic - Experience based
  • Тестовая документация и артефакты (Test Deliverables/test artifacts)
    • Виды тестовой документации
    • Политика качества и политика тестирования (Quality policy and Test policy)
    • Стратегия тестирования (Test strategy)
    • План тестирования (Test plan)
    • Тестовый сценарий (Test scenario)
    • Тест-кейс (Test case)
    • Чек-лист (Check List)
    • Баг-репорт (Defect/bug report)
    • Требования (Requirements)
    • Пользовательские истории (User stories)
    • Критерии приемки (Acceptance Criteria)
    • Виды отчетов (Reports)
    • Базис тестирования (Test basis)
    • Матрица трассируемости (RTM - Requirement Traceability Matrix)
    • Метрики тестирования (Software Test Metrics)
    • Тестовый оракул (Test oracle)
  • Мобильное тестирование
    • Android
      • Архитектура Android OS
      • Архитектура Android Application
      • Тестирование покупок в Android-приложениях
      • Android Developer Settings
      • Android Debug Bridge (ADB)
      • Android Studio для QA
    • iOS
      • Архитектура iOS
      • Архитектура iOS Application
      • Тестирование покупок в iOS-приложениях
      • iOS Developer Settings
    • Особенности в тестировании мобильных приложений
    • Покрытие девайсов
    • Типы мобильных приложений
    • Симуляторы и эмуляторы
    • Основные различия Android/iOS
    • Последнее обновление Android/iOS, что нового?
    • Основные проверки при тестировании мобильного приложения
    • Каким образом тестировщик получает приложение на тест?
    • Как успешно зарелизить продукт в App Store и Google Play
    • Тестирование требований к мобильным приложениям
    • Тестирование push-уведомлений
    • Тестирование дип линков (mobile deep links)
    • Тестирование сохраненных поисков
    • Тестирование рекламы
    • Тестирование просмотренных товаров
    • Middleware
    • Как проверить использование ресурсов на Android
    • Как протестировать приложение для другой страны?
  • Тестирование в разных сферах-областях (testing different domains)
    • Тестирование веб-сайта или веб-приложения (Web application)
    • Тестирование интернет-магазина (eCommerce)
    • Тестирование платежного шлюза (Payment Gateway)
    • Тестирование игр (Game testing)
    • Тестирование VR программного обеспечения
    • Тестирование мессенджера (Messenger)
    • Тестирование чат-бота (Chatbot)
    • Тестирование электронных писем (E-mail)
    • Тестирование интернета вещей (IoT - Internet of Things)
    • Тестирование облачных решений (Cloud testing)
    • Тестирование сервис-ориентированной архитектуры (SOA - Service Oriented Architecture)
    • Тестирование микросервисной архитектуры (MSA/Microservices)
    • Тестирование платформы электронного обучения (E-learning platform)
    • Тестирование систем розничной торговли (POS - Point Of Sale)
    • Тестирование банковского ПО (Banking domain applications/BFSI)
    • Тестирование страхового ПО (Insurance)
    • Тестирование в сфере телекоммуникаций (Telecom)
    • Тестирование планирования ресурсов предприятия (ERP - Enterprise Resource Planning)
    • Тестирование миграции данных (ETL)
    • Тестирование баз данных (Database)
    • Другое
  • SDLC и STLC
    • Жизненный цикл разработки ПО (SDLC - Software Development Lifecycle)
    • Жизненный цикл тестирования ПО (STLC - Software Testing Lifecycle)
    • Модели разработки ПО
    • Agile
    • Scrum
    • Подходы к разработке/тестированию (... - driven development/testing)
  • Сети и около них
    • База по сетям
    • Клиент - серверная архитектура (Client-Server Architecture)
    • Микросервисная архитектура (Microservice Architecture)
    • Эталонные модели OSI и TCP/IP
    • HTTP
    • Идентификация ресурсов в сети (Identifying resources on the Web)
    • Веб-сервис (WS - Web service)
    • REST/SOAP/gRPC
    • Socket / WebSocket
      • Сокет/веб-сокет (socket/websocket)
      • Тестирование WebSocket на клиентах
    • Хранилище на стороне клиента (Client-side storage)
    • Кэш (Cache)
    • Аутентификация и авторизация (Authentication and authorization)
    • Рендеринг в интернете (Rendering on the Web)
  • Практическая часть
    • Логические задачи
    • Тестирование полей и форм
    • Примеры задач на собеседованиях и тестовых заданий
    • Платформы для тренировок и квизы
  • Автоматизация (beta)
    • Общее
    • Полезные ссылки
    • Как стать автоматизатором и вопросы с собеседований
    • Что нужно автоматизировать?
    • Виды и инструменты автоматизации
    • Инфраструктура и пайплайн (CI/CD)
    • Процессы и автоматизация проекта с нуля
    • Лучшие практики автоматизации
    • Что такое flaky tests?
    • Мутационное тестирование (Mutation testing)
    • Параллельное тестирование (Parallel testing)
    • Подкожный тест (Subcutaneous test)
    • Разница между coupling и cohesion
    • Другое (ссылки)
  • Контакты
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
  1. Тестирование в разных сферах-областях (testing different domains)

Тестирование электронных писем (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. Низкая доставляемость (или попадание в спам-папки)

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

  • Вы не открываете собственные тестовые электронные письма. Если вы используете свой собственный адрес для проверки электронных писем, если вы не взаимодействуете с ними, интернет-провайдеры пометят письма как неактуальные и начнут отправлять их в спам;

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

  • Нет ссылки «Отписаться». Пакеты, в которых нет нижнего колонтитула «Отписаться», с вероятностью 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 могут пригодиться.

Источники:

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

PreviousТестирование чат-бота (Chatbot)NextТестирование интернета вещей (IoT - Internet of Things)

Last updated 3 years ago

Was this helpful?

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

Lorem Ipsum dolor
Should QAs care about email testing?
Подтверждать ли email
Чек-лист. Где нужно тестировать верстку email «руками»
10 best email testing tools for optimized delivery
A/B тестирование для email писем. 30 идей тестов