E2e тестирование что это

Руководство по сквозному тестированию: что такое E2E-тестирование с примерами

Сквозное тестирование (End-to-end, E2E, Chain testing) — это вид тестирования, используемый для проверки программного обеспечения от начала до конца, а также его интеграцию с внешними интерфейсами. Цель сквозного тестирования состоит в проверке всего программного обеспечения на предмет зависимостей, целостности данных и связи с другими системами, интерфейсами и базами данных для проверки успешного выполнения полного производственного сценария.

Наряду с программной системой тестирование также обеспечивает проверку пакетной обработки и обработки данных из других вышестоящих и нижестоящих систем. Отсюда и название «End-to-End». Сквозное тестирование обычно проводится после функционального и системного тестирования. Для его проведения используются реальные данные и тестовая среда для имитации рабочего режима.

Зачем нужно сквозное тестирование?

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

Процесс сквозного тестирования:

На схеме ниже представлен обзор процесса сквозного тестирования.

Основные виды деятельности, связанные со сквозным тестированием:

• Изучение требований к сквозному тестированию;
• Настройка тестовой среды и требования к оборудованию/программному обеспечению;
• Описание всех процессов системы и ее подсистем;
• Описание ролей и ответственности для всех систем;
• Методология и стандарты тестирования;
• Сквозное отслеживание требований и разработка тест-кейсов;
• Входные и выходные данные для каждой системы.

Как писать тест-кейсы для сквозного тестирования?

Фреймворк сквозного тестирования включает в себя три части:

1. Создание пользовательских функций
2. Создание условий
3. Создание тест-кейсов

Рассмотрим каждую из них подробно.

Создание пользовательских функций

Как часть построения пользовательских функций, должны быть выполнены следующие действия:

• Перечислить функции системы и их взаимосвязанные компоненты;
• Перечислить входные данные, действия и выходные данные для каждой характеристики или функции;
• Определить отношения между функциями;
• Определить, является ли функция многократно используемой или независимой.

Например, рассмотрите сценарий, при котором вы входите в свой банковский аккаунт и переводите деньги со своего счета на счет в другой банк (сторонняя подсистема):

1. Войти в банковскую систему.
2. Проверить сумму остатка на счете.
3. Перевести определенную сумму со своего счета на другой банковский счет (сторонняя подсистема).
4. Проверить текущий баланс счета.
5. Выйти из приложения.

Построение условий на основе пользовательских функций

В рамках построения условий выполняются следующие действия:

• Построение набора условий для каждой определенной пользовательской функции;
• Условия включают последовательность, время и условия данных.

Например, проверка дополнительных условий, таких как:

Страница авторизации

• Неверное имя пользователя и пароль
• Проверка с действительным именем пользователя и паролем
• Проверка надежности пароля
• Проверка сообщений об ошибках

Сумма остатка

• Проверьте текущий баланс через 24 часа (Если перевод отправляется в другой банк)
• Проверьте сообщение об ошибке, если сумма перевода больше суммы текущего баланса.

Создайте тестовый сценарий

Построение тестового сценария для определенной пользовательской функции

• Войти в систему
• Проверить сумму остатка на банковском счете
• Перевести сумму остатка на банковском счете

Создание нескольких тест-кейсов

Создайте один или несколько тест-кейсов для каждого определенного сценария. Тест-кейсы могут включать каждое условие как отдельный тестовый пример.

Инструмент сквозного тестирования

testRigor

В мире сквозного тестирования лидером отрасли является testRigor. Он помогает создавать тесты без кода для веб-интерфейса, нативных и гибридных мобильных приложений, мобильных браузеров и API. С его помощью можно тестировать электронную почту и SMS, загруженные файлы .XLS, .DOC, .PDF и т. д.

Функции:

• Написание тестов без кода просто на английском языке.
• Покрытие Web + Mobile + API в одном тесте. Кроссплатформенная и кроссбраузерная поддержка.
• Создание тестов в 15 раз быстрее по сравнению с Selenium.
• Сокращение обслуживания тестов до 99,5%.
• testRigor безопасен и соответствует стандарту SOC 2 Type 2.
• Интеграция с CI/CD и управлением тест-кейсами.
• Выполнение 1000 тестов и получение результатов менее чем за 30 минут.

Метрики сквозного тестирования:

Ниже приведены некоторые метрики, используемые для оценки прогресса сквозного тестирования.

• Статус подготовки тест-кейса: показывает реальный прогресс подготовки тест-кейса по сравнению с запланированным.
• Еженедельный прогресс тестирования. Дает подробную информацию о завершении теста за неделю в процентах. Неудачные, не выполненные и выполненные тесты по сравнению с запланированными для выполнения тестами.
• Статус и детали дефектов — показывает процент открытых и закрытых дефектов понедельно. Кроме того, распределение дефектов по неделям в зависимости от серьезности и приоритета.
• Доступность среды — общее количество часов доступности / общее количество часов, запланированных в день для тестирования.

Сквозное тестирование vs системное тестирование

Сквозное тестирование

Системное тестирование

Проверяет программную систему, а также взаимосвязанные подсистемы.

Проверяет только программную систему в соответствии со спецификациями требований.

Проверяет весь сквозной поток процессов.

Проверяет функциональные возможности и функции системы.

Для тестирования рассматриваются все интерфейсы и серверные системы.

Рассматриваются функциональное и нефункциональное тестирование

Выполняется после завершения тестирования системы.

Сквозное тестирование включает в себя проверку внешних интерфейсов, которую сложно автоматизировать. Следовательно, ручное тестирование предпочтительнее.

Для тестирования системы можно выполнять как ручное, так и автоматизированное тестирование.

В заключение

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

Приглашаем всех желающих на открытое занятие, на котором мы познакомимся с фреймворком Selenide и перепишем существующие тесты на него. Регистрация доступна по ссылке.

• java qa
• end-to-end testing
• сквозное тестирование
• E2E тестирование
• selenide

• Блог компании OTUS
• Тестирование веб-сервисов

Сквозное (e2e) тестирование

Сквозное тестирование — это проверка (валидация) приложения полностью, от начала до конца, вместе со всеми зависимостями.

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

Тестируется весь user flow (путь пользователя). Например, при разработке онлайн-магазина тестировщик «идет по пути пользователя» от входа посетителя на сайт и регистрации до завершения покупки.

Правильное сквозное тестирование

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

Хаотически выполненные быстрые ручные e2e-тесты могут выглядеть приемлемо для менеджмента, но принесут проблемы в будущем.

Рутинные операции e2e-тестов автоматизируются, чтобы сэкономить время. Современные приложения часто и регулярно обновляются — поэтому необходимостью становится автоматизированное непрерывное тестирование. Трудно выполнять все e2e-тесты вручную каждый раз при обновлении кода. Если есть возможность написать один тест-сьют и запускать его всякий раз когда нужно сквозное, что многие и делают, время действительно экономится.

Но каждый уровень и тип тестирования имеет свои ограничения. Если пытаться «выйти за рамки» каждого типа/уровня, такие тесты могут создавать проблемы. Может возникнуть ситуация, когда больше времени уходит на написание кода автотестов и его обслуживание, чем на продвижение с кодом собственно самого приложения. Иными словами, может потеряться крупнейший плюс автоматизации — ускорение всех процессов.

Поэтому, выполняя e2e-тестирование, нельзя забывать о тестовой пирамиде, о том что e2e-тесты находятся на ее вершине. Пирамида точнее всего отображает правильный баланс уровней и типов тестирования. Этот стандарт устоялся в ИТ-индустрии уже очень давно, около 20 лет назад, и продолжает быть вполне применимым и в 2023.

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

Уровни пирамиды

Пирамида тестирования имеет три «слоя»: юнит-тесты, интеграционные тесты и сквозные.

Далее, на самой верхушке, располагаются приемочные (для простоты примем, что они пока исключены из пирамиды; также примем, что функцию системных тестов у нас выполняют сквозные; о разнице между сквозными и системными — далее).

Юнит-тесты

Обычно «юниты» — это функции или классы. Они как правило небольшие, и не имеют внешних зависимостей. А если имеют, то вместо зависимостей «вставлены» моки.

Когда юнит-тест падает, определить причину достаточно просто. Очень маленькая область тестирования определяет то, что юнит-тесты просто писать, быстро выполнять, и очень легко обслуживать.

Интеграционные тесты

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

Сквозные тесты

Как мы уже знаем, сквозные тесты фокусируются на user flow, от самых простых к сложным и негативным. Сквозные тесты с какой-то точки зрения можно рассматривать как «многоэтапные сложные интеграционные». Сквозные тесты самые медленные, потому что время уходит на билд, деплой, запуск приложения, и выполнение (очень) большого количества действий.

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

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

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

Стратегии сквозного тестирования

Вертикальное e2e-тестирование

«Вертикальный подход» проверяет, как бы подытоживая, все уровни пирамиды, начиная с выборочных юнит-тестов, продолжая интеграционными, и заканчивая проверкой интерфейса. Стандартно применяется в CI/CD-пайплайне для автоматизированного запуска тестов при новых коммитах/pull-реквестах.

Горизонтальное e2e-тестирование

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

Типы сквозного тестирования

В данное время автоматизированные e2e-тесты применяются более широко чем ручные (по крайней мере если брать по количеству выполняемых операций). Автоматизация возможна двух видов: codeless и стандартная общепринятая (с написанием тестов на ЯП).

Стандартное e2e-тестирование

Если речь идет о e2e-тестировании веб-приложений, подразумевается применение фреймворков автоматизации браузеров. Самый популярный инструмент, разумеется, Selenium, но многие предпочитают Cypress (по крайней мере для JavaScript). В принципе, оба фреймворка работают более-менее похожим образом. (Подробный материал об инструментах — по ссылке).

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

Ниже пример [мока из документации Cypress], можно видеть, как работает этот е2е-инструмент:

1. Пользователь заходит на сайт https://example.cypress.io.
2. Если пользователь кликает на линк включающий слово “type”, то URL должен содержать “/commands/actions”.
3. Если в поле имейла “.action-email” введено значение “fake@email.com”, проверяется, что оно теперь содержит это значение.

Codeless e2e

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

Внешне это выглядит как lowcode-платформа, с перетаскиванием и вставкой блоков. Ниже гифка — как это делается (на примере TestCraft):

Как видим, крайне удобные функции, не требующие глубокого знания языков программирования (что актуально для выпускников базовых курсов QA), такие инструменты тем не менее обходятся компании дороже чем обычные. Но если остро стоит вопрос времени, подобные codeless-решения могут выручить. Разумеется, эти фреймворки еще слишком сырые в целом, они не могут полностью заменить всю сложность и функциональность существующих фреймворков, и тем более ручного тестирования которое остается по очевидным причинам. Если приложение имеет очень сложные пользовательские пути, если эти пути часто меняются, то конечно классическое e2e-тестирование незаменимо. Если приложение более-менее простое, и вопрос времени основной, то codeless-решения помогут.

Инструменты

Puppetry

Существует также бесплатный Puppetry с открытым кодом (!_не_путать_с_Puppeteer_!):

Как он работает:

Бесплатная платформа сквозного тестирования, работающая в связке с Selenium и Appium.

Пример (можно включить русские субтитры):

Разница между сквозным и системным тестированием

Системное тестирование сосредоточено на полной валидации функциональных и нефункциональных требований. То есть, системное тестирование предполагает еще больше действий, чем сквозное. В системное тестирование включает такие подвиды тестирования, как тестирование масштабируемости, производительности, или надежности. Иногда задачи системного тестирования могут передавать внешней QA-команде, которая работает с приложением в режиме черного ящика.

В то время как сквозное тестирование фокусируется, грубо говоря, «на правильности прохода пользовательских путей».

Сложности

• Сквозные тесты не обязаны «тестировать как можно больше за один раз», то есть одним тестовым набором всю функциональность. Часто тестировщики пишут огромные сквозные тесты, верифицирующие буквально каждый аспект пользовательского пути, вдаваясь в ненужную детализацию там, где это не так уж обязательно. Например, для проверки пути логина в большинстве случаев будет достаточно верифицировать перенаправление пользователя на главную страницу после успешного логина.
• При падении сквозного теста бывает довольно-таки сложно определить «место падения», то есть его причину. Можно уменьшить время на дебаг автотестов, более внимательно отрабатывая бизнес-логику в юнит-тестах и интеграционных. Также существуют неплохие инструменты, дающие анализ причин, со скриншотами и логами этапов.
• На сквозные тесты требуется большое время в CI-пайплайне, что может тормозить или даже блокировать разработку.
• Сквозные тесты имеют «непрерывную» природу: каждая новая функциональность или изменения существующей приводят к необходимости обновлять сквозные тесты. Этот фактор можно смягчить, создавая реюзабельные компоненты, абстрагирующие детали имплементации. Опять же, в современных инструментах есть подсказки и автокоррекции, адаптирующие сквозные тесты к изменениям кода приложения.

Советы

Первый совет — делать сравнительно небольшие, по возможности независимые, и реюзабельные e2e-тесты (или делать реюзабельными хотя бы их компоненты). Это позволит «нанизывать цепочку» тестовых компонентов на полный end-to-end пользовательский путь. Вместо написания множества изолированных, нигде больше не задействованных тестовых компонентов. Что позволит снизить время на поиск проблемных мест в автотестах и быстрее обновлять тест-сьют.

1. Покрывать e2e лишь критическую функциональность

И не тратить время на отработку сообщений об ошибках во второстепенных пользовательских путях — они как правило достаточно просты и не требуют внимания на таком высоком уровне как e2e; и вообще, они должны были исчезнуть на первом уровне модульного тестирования. Следует сосредоточиться на valuable flows, то есть лишь тех которые влияют на пользователей.

1. Сквозные тесты не должны слишком зависеть от деталей имплементации

Вовсе не обязательно обновлять e2e-тесты при каждом изменении деталей имплементации в каждом конкретном пользовательском пути. Как говорилось выше, желательно «абстрагировать» отдельные компоненты. Тогда тесты будет проще писать, а далее обслуживать.

E2E Tests

Сквозное тестирование, оно же End-to-end или E2E, — это процесс тестирования, при котором происходит подробная эмуляция пользовательской среды. То есть при данном тестировании имитируют: щелчки мышью, нажатия на кнопки, заполнение форм, переходы по страницам и ссылкам и другие поведенческие факторы.

Для чего нужно это знать?

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

Какие базовые понятия включает этот навык?

Нет единого алгоритма сквозного тестирования, так как многое будет зависеть от сложности самого проекта и что конкретно нужно тестировать. Е2Е — это лишь название процесса тестирования, а не его метод или алгоритм. Но при этом выделяют два основных типа сквозного тестирования, на которых мы немного остановимся. Типы Е2Е-тестирования: Метод «черного ящика». Это специальный E2E-процесс тестирования, при котором само тестирование проводится только с интерфейсом пользователя. «Черным ящиком» называется, потому что тестировщика интересуют только проблемы интерфейса: работоспособность функций, ошибки при взаимодействии, ошибки при определенном поведении пользователей и т. д., и его абсолютно не интересует, как это все работает внутри программы. В большинстве случаев тестировщик даже не понимает, как с помощью кода получается тот или иной функционал. Такой тип тестирования считается самым распространенным. Метод «белого ящика». В этом типе тестирования тестировщику известна «внутренняя кухня» программы. А это значит, что ему известно, как себя должна повести программа при определенном действии пользователя. Он анализирует, совпадает ли задуманный результат поведения с реально происходящим, и понимает, где нужно вносить необходимые корректировки. Любой сквозной тест — это: в первую очередь тестирование UI; тяжелый и медленный тест; применение метода «черного ящика» и найм сторонних тестировщиков, никак не связанных с разработкой программы; тяжелый «отлов» найденной проблемы; тестирование всех модулей и всех систем целиком, поэтому требуется сложный и эффективный софт или работа «руками»; гарантия, что программа работает так, как задумано, или нет. Е2Е — это дорогой и сложный процесс тестирования, к которому нужно подготавливаться основательно. Давайте проведем аналогию с мостом. Мост через реку — это тестируемая программа. Так вот Е2Е-тестирование — это не просто проехать по мосту груженными КАМАЗами и смотреть издалека: выдержит или не выдержит. Е2Е — это куча всевозможных датчиков, расставленных по всему мосту, которые сигнализируют о каждом шаге и готовы фиксировать любой сценарий развития на «мосту»

Где я могу освоить этот навык?

Освоить навык «E2E» ты можешь проходя обучение в нашей менторинге по программе «Frontend-разработчик» и «Инженер по Автоматизированному тестированию».

Home

Недавно я разговаривал с моим непосредственным руководителем про end-to-end (e2e) тесты и их предназначение. Возможно, дело в моем лингвистическом прошлом, но я лучше думаю, Когда пишу. Я решил перечислить, чем должен быть хороший e2e-тест и что он должен делать, а чего не должен. Так я и пришел к этому списку.

Кстати говоря, список этот и не задумывался исчерпывающим – он будет меняться и развиваться вместе с изменениями и развитием моего тестирования и понимания тестирования, поэтому смело делитесь своими предложениями про e2e-тесты.

Что должен делать хороший end-to-end тест?

Не буду углубляться в словарные определения e2e-тестов – думаю, любой в состоянии их нагуглить. Меня больше интересуют те характеристики e2e-тестов, которые я считаю ценными.

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

Если смотреть на e2e тесты с точки зрения терминологии тестирования, можно сказать, что они ближе к вариантам использования, а не тест-кейсам – см. определения ниже:

Тест-кейс: конкретная ситуация в тестировании, в которой тестировщик выполняет действие или набор действий, при конкретных предусловиях, состоянии окружения и данных, чтобы валидировать свои убеждения и/или ожидания от функциональной корректности продукта.

Вариант использования: сценарий, в котором конечный пользователь (отсюда название – «вариант использования») выполняет цепочку действий в продукте или идет по определенному пути, следуя к конкретной конечной цели. Зачастую задействовано несколько функциональностей, подсистем и внешних результатов.

Умных тестировщиков должен интересовать второй вариант – даже если по какой-то причине мы решим частично проводить тестирование, разбив его на небольшие функциональные тест-кейсы. Мы должны концентрироваться на опыте конечного пользователя.

Учитывая вышесказанное, e2e-тесты намеренно кросс-функциональны – они прыгают от одной функциональности к другой, иногда – даже с помощью внешних приложений или ресурсов (почтовый агент для проверки получения верификационного письма, и т. д. ). Если ваш тест задействует только одну функциональность – то он скорее функциональный, а не end-to-end.

Он должен охватывать сценарии целиком, учитывая два измерения

Обсуждая end-to-end тесты, можно легко задаться вопросом, о каких концах речь? Где они? Мой ответ: в e2e-тестах мы хотим растянуть тест-покрытие в двух измерениях.

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

Такой сценарий может выглядеть как-то так:

Клиент авторизуется в приложении электронной коммерции, ищет конкретный продукт – скажем, худи, — открывает и изучает его карточку, сравнивает с другим товаром, оформляет заказ, выбирает метод оплаты, платит на странице внешнего оператора платежей и завершает заказ.

Какой набор проверок нам тут желателен?

• В корзину добавлен правильный товар (с верной ценой и скидкой, если она есть)
• Показан правильный экран успешной операции
• Во внутренней системе добавлен заказ
• Пользователю отправлено правильное письмо с информацией о заказе
• Проверка правильной обработки платежа, и т. п.

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

Он должен соответствовать вариантам использования или приемочным критериям

Приемочные критерии и варианты использования – фактор, который часто упускают и в тестировании, и в разработке. Это легко объясняется тесными временными рамками релизного процесса. Работа с ними и их внедрение в e2e-тесты – хорошее упражнение для критического мышления. В целом тут речь о том, что при релизе ПО мы должны ответить на вопрос, в чем цель того, что мы делаем. Это ПО, приложение, игра, бинарник, нативное облачное приложение – в чем его цель?

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

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

Откуда идет термин «приемочное тестирование/приемочный тест»?

Давным-давно, когда создание ПО было привилегией лишь нескольких специализированных компаний, обычные предприятия подписывали контракт на проекты по разработке с вышеупомянутыми специалистами. В этом контракте задавались приемочные критерии – набор критериев, которыми должно обладать ПО, или тестов, которые оно должно успешно пройти или продемонстрировать принимающей стороне, дабы она приняла работу и выплатила остаток. Надеюсь, сейчас вы понимаете, как глупо звучат заявления продуктовых компаний вроде «мы проводим пользовательское приемочное тестирование» – они же выступают и в качестве поставщика, и в качестве приемщика (еще и пользователя, если они решают «самостоятельно попробовать свой собачий корм»).

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

Он должен выполняться в конце релизного цикла, после прочих фаз тестирования

Уже чувствую волну возмущения этим заголовком, поэтому, пожалуйста, обратите внимание – я сказал «после», а не «вместо» прочих фаз тестирования – пожалуйста, сохраняйте спокойствие до конца статьи.

E2E-тестирование должно быть церемонией коронации процесса поставки. Ожидается, что все функциональные и парафункциональные баги уже выловлены и исправлены ранее. В момент автоматизированного прогона e2e его задача – верифицировать соответствие ожиданиям конечного пользователя.

Он должен быть частью критериев готовности (DoD) – устного контракта, которому мы должны следовать ради релиза

Многие компании, с которыми я работал, тряслись от ужаса при вопросе о DoD – позор им, позор! Часть работы команды, разрабатывающей ПО, включая тестировщиков и разработчиков – это определить набор критериев, позволяющих оценить готовность всех процессов, которые мы считаем необходимыми. Уверен, вас не удивит, если я скажу, что многие убеждены в готовности продукта еще до того, как его впервые увидит тестировщик или тест-инструмент. Эти компании страдают, порядочно страдают.

E2e – жизненно важная часть DoD, и если вы цените качество своей работы, ваша цель сделать его как можно более прозрачным: все задействованные стороны, даже вне технической части, ясно понимают, почему работа считается завершенной. Заметать что-то под ковер «слишком технического, вам не понять» – это демонстрация слабости.

Чем e2e тесты не являются, чего они не должны делать?

Они не должны исчерпывающе тестировать всю функциональность

Ставлю свою карьеру на то, что основная причина нестабильных тестов, помимо нажимающих на клавиши органических полуавтоматов (например, создателей), в том, что люди стараются засунуть в них все на свете. Я видел тесты, проверяющие разметку, путь, видимость кнопки, видимость результата, и т. д., и т. п. Получается свалка, а не e2e тест – тест переполнен чересчур большим количеством действий и в итоге теряет концентрацию и направление. Большинство этих тестов имеет смысл, задачу и причину, но не относится к e2e:

• Тесты разметки и отображения/скрытия элементов можно легко провести в рамках компонентных тестов фреймворка фронтэнда.
• Тестирование потоков и переходов между страницами – часть функционального тестирования.

E2e должны проверять только прямое, похоже на пользовательское, взаимодействие с продуктом.

Они – не оправдание для игнорирования всех прочих видов тестирования (юнит, низкоуровневая интеграция, нефункциональные, функциональные, исследовательские тесты)

То, что люди склонны складывать в e2e все на свете, приводит к еще одному побочному эффекту – они убеждены, что им больше не нужны штуки вроде юнит-тестов, интеграционного или функционального тестирования – у них же все это (или нечто похожее) уже есть, в e2e тестах. Это не так по ряду причин:

1. Если смешивать разные типы тестирования, каждый из них утратит фокус.
2. Если смешивать юнит/интеграционные и функциональные тесты, теряется возможность поэтапного тестирования, создающего ворота качества – это значит, что если отказывают ваши юнит/интеграционные/функциональные тесты, до e2e еще даже дело не дошло.
3. Возрастают затраты на тестирование – легче, быстрее и приятнее прогонять низкоуровневые тесты, отлавливая баги.

Их недостаточно

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

Они не предназначены для тестирования парафункциональных аспектов – производительности, безопасности, совместимости (с браузерами, носителями, окружениями), устанавливаемости, и т. д.

Это практическое, а не принципиальное замечание – e2e тесты предназначены для тестирования с точки зрения пользователя и только пользователя.

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

Они не оправдание для проведение несложного подтверждающего тестирования просто потому, что «мы это автоматизировали»

Это какая-то болезнь в нашей отрасли – создание тестов, которые не тестируют, а просто подтверждают, демонстрируют, что продукт на месте и работает. E2e тесты созданы как сценарии счастливого пути, и из-за их природы легко удариться в создание несложных подтверждающих проверок. Грань тут тонка, будьте осторожны! Мой вам совет:

• Старайтесь, чтобы ваши тесты были максимально детерминированы
• Добавляйте релевантные и значимые для контекста проверки. Столько, сколько сможете добавить и поддерживать.
• Не полагайтесь на «мягкие ассерты» вроде ожиданий – да, ожидание обвалит тест, но нам нужен детерминированный способ понимания, почему он упал. Падение теста из-за обнаружения бага – это хорошо; плохо, если тест упал, а почему – вы не знаете.

Вот мой краткий список того, как надо и как не надо обращаться с e2e-тестированием – я иронично назвал его «Манифестом E2E-тестирования», но этого недостаточно. Будем продолжать открытый диалог – что думаете вы, какие примеры и антипримеры знаете? Дайте мне знать.