5 вопросов про e2е-тестирование

Для запуска большой системы может быть недостаточно функционального и интеграционного тестирования. За обилием технических моментов можно упустить важный для бизнеса аспект, который может заставить отложить запуск вроде бы готового продукта (услуги, предложения). Мы говорим про тестирование бизнес-процесса (end-to-end-тестирование или просто e2e). Рекомендуем проводить его целиком, не фрагментируя на спринты и релизы систем, пройти от и до на тестовой среде без риска для пользователей и инфраструктуры.

О том, как подготовиться к такому тестированию, расскажем в этой статье. Владельцам продукта (product owner, далее — PO) и QA будет полезно узнать о возможных ошибках при планировании и способах оптимального распределения ресурсов на реализацию задачи для нескольких команд.

У PO и QA есть инструменты, которые позволяют понимать состояние продукта и процессов. Они тестируют, снимают метрики, планируют и автоматизируют независимую поставку изменений пользователю, чтобы сократить time-to-market и быть готовыми реализовать любые потребности бизнеса.

Рассмотрим поставку бизнес-ценностей на примере Scaled Agile Framework, где взаимодействует много внутренних и внешних систем и сервисов, есть вендоры, разный технологический стек, состав команд, функциональность, а значит и субъективный взгляд на бизнес-ценности, когда каждая команда всё видит «со своей колокольни».

Зачастую бизнес-ценность не укладывается в компетенцию одной команды и даже одной системы. Назовем такую ценность capability (высокоуровневое функциональное решение, которое реализуется за один цикл). Кто отвечает за реализацию capability в нескольких системах и командах? Чтобы это не стало общей ответственностью, у capability должна быть ведущая команда. И ей требуется новый инструмент — end-to-end-тестирование (e2e), которое обеспечит поставку ценности.

E2e проверяет работу бизнес-процесса, проходящего через разные системы, например, от регистрации клиента до закрытия сделки. Кажется, всё просто: определили системы, команды и срок запуска, запланировали и провели. Но давайте разберемся, так ли это.

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

И вот QA-специалистов просят оценить задачу «на тестирование» capability, которое реализуется, например, в течение четырех спринтов в трех командах и четырех системах. При этом оценить нужно свою часть тестирования, учитывая имеющиеся ресурсы. Хорошо, если оценивает QA-лид, который имеет опыт тестирования разных систем. При этом PO и аналитики уже проработали зависимости и знают, кто будет участвовать в e2e. Хорошо, если у всех есть опыт е2е-тестирования, всё учтено, и бизнес знает, чего хочет или всегда готов к диалогу. К сожалению, так бывает не всегда.

Рассмотрим ситуацию, когда команда системы «Г», которая поддержала зависимость по capability, проводит подготовку к квартальному планированию. Так может выглядеть диалог PO и QA:

QA думает: «Боже, я каждый день на тесте закрываю сделок на 10 млн рублей и на 12 в тенге. Тут что-то не так», – а сам спрашивает:

Дальше всё будет так, как бывает, когда нет тест-плана: забыли включить в тестирование одну из систем, начали е2е до того, как исправили баги и не закрыли сделки. В итоге, в системе «Б» весь спринт проходился раз за разом один и тот же сценарий. В следующем спринте тестирование завершили. Об успешном «сквозном» тестировании сообщили на демо.

Что сделали не так?

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

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

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

В результате такое е2е-тестирование не только тратит ресурсы нескольких команд, но и не достигает цели. Затраты могут быть не оценены, как при планировании, так и в итоге. И пока неясно, по каким метрикам оценивать эффективность e2e, важно должным образом к нему подготовиться, чтобы снизить потери и риски.

В идеале подготовку к e2e при участии QA нужно начинать до планирования и оценки задач. QA могут запросить доступы к тестовым стендам смежных систем, получить тестовые устройства и настроить инструменты. Важно провести установочную встречу с QA из всех привлекаемых команд. Желательно «пройти» бизнес-процесс с аналитиком или с клиентом, который погрузит QA и даст представление о бизнес-ценности.

Главное – у QA ведущей команды должна собраться информация, которая нужна для проведения тест-дизайна и постановки цели тестирования:

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

В результате у нас вырисовывается не только покрытие и план, но и шаги по оптимизации ресурсов. Например, настройка систем и подготовка тестовых данных могут быть делегированы команде, которая разгрузит QA при необходимости.

Прекрасно, когда есть все доступы. Можно ввести данные в систему «А» и в ней же, как пользователь, видеть результат, после обработки данных в «Б» и «В». Затем взять тестовое устройство и под другой ролью в системе «Г» продолжить и завершить процесс. В итоге проверить его артефакты в «А» и «Д». Это e2e-тестирование выполняет один специалист — без потерь на коммуникации и синхронизацию между QA из разных команд.

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

Поскольку в тестировании могут участвовать вендоры и команды без QA, доступы помогают концентрировать ответственность и делать коммуникации функциональными.

Итак, мы практически подготовили тест-план, получили понимание о бизнес-процессе и представление о цели тестирования. На этом этапе есть сценарии, участники, их роли. На квартальном планировании мы расставили и обсудили зависимости, оценили задачи на разработку, e2e и настройку стендов, возможно даже запланировали «окно», когда настройки нельзя ломать. Теперь мы знаем:

Да, может быть много неизвестных и переменных. Все вопросы стоит фиксировать в плане. Важно получить ответы до спринта, когда запланировано e2e, чтобы участники могли переоценить свои задачи на тестирование.

Исходя из количества неизвестных можно определить критерии завершенности e2e. Например, не обязательно всем участникам проводить ретест по некритичным дефектам или тестировать доработки одной из систем, необходимость которых выявил e2e. Всё это важно обсудить с участниками, зафиксировать в плане. Тогда e2e не станет черной дырой для ресурсов.

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

Своевременное подключение QA позволит не потерять бизнес-ценность в ходе e2e-тестирования.

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

Погружение QA в бизнес-процесс позволит запланировать e2e оптимальным образом:

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

На уровне команд: ресурс одной не будет тратиться на тестирования функциональности в другой, так как разграничены степень участия и определены критерии начала (готовности). Прописанные критерии завершенности (Definition of Done, DoD) позволят понять, в какой момент общая задача готова и начинаются доработки и исправления в отдельной команде.

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

Больше интересных кейсов — на нашем сайте.