Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно я разговаривал с моим непосредственным руководителем про 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-тестирования", но этого недостаточно. Будем продолжать открытый диалог – что думаете вы, какие примеры и антипримеры знаете? Дайте мне знать.

Обсудить в форуме