E2E-тестирование приложения: что покрывать сквозными тестами

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

4 сентября 2026 Технологии 19 мин чтения

---

Что такое сквозное тестирование и чем оно отличается от остальных проверок

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

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

• Модульный тест (его называют юнит-тестом) проверяет одну функцию в отрыве от остальных: например, расчёт итоговой суммы корзины с бонусами.
• Интеграционный тест проверяет связку двух-трёх частей: приложение обращается к серверной части и получает ответ в ожидаемом формате.
• Сквозной тест проходит весь путь через интерфейс, сеть, серверную часть, базу данных и внешние сервисы.
• Ручная проверка закрывает то, что не описано заранее: внешний вид, ощущение от анимации, странное поведение на конкретной модели телефона.

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

Что ломается, когда сквозных тестов нет

Типичная картина: каждый модуль по отдельности работает, а путь целиком — нет. Обновили платёжный модуль, форма оплаты открывается, но кнопка возврата в приложение после подтверждения перестала срабатывать на части устройств. Модульные тесты зелёные, интеграционные зелёные, а покупатель после оплаты видит пустой экран и звонит в поддержку.

Такие ошибки живут именно на стыках, и цена их находки растёт по мере приближения к выпуску:

1. Нашли при разработке. Исправление занимает часы одного человека, дальше никого не задевает.
2. Нашли при проверке перед выпуском. Сдвигается дата выпуска, команда проходит проверку заново — уже руками и целиком.
3. Нашли после публикации. К стоимости исправления добавляется ожидание проверки обновления в магазине приложений: App Store и Google Play проверяют сборку по своим правилам, RuStore и другие сторы — по своим. Пока обновление едет, ошибка работает на всех пользователях.
4. Не нашли вовсе. Ошибка приходит обратно оценками в магазине приложений и обращениями в поддержку. Оценку приложения потом поднимают месяцами.

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

Экономический смысл появляется там, где мобильный канал даёт заметную долю продаж. В кейсе Gulliver Family через приложение проходит 80% мобильного трафика, и оно приносит 50% общего дохода ритейлера. Когда половина выручки идёт через один канал, час неработающего оформления заказа — это не техническая неприятность, а вычет из дневной выручки. Как ведут себя показатели самой корзины, мы разбирали в материале о конверсии корзины интернет-магазина.

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

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

Перевёрнутая пирамида — распространённая ошибка внедрения. Логика кажется убедительной: раз сквозной тест проверяет всё сразу, покроем им всё сразу. Через несколько месяцев набор выглядит так: полный прогон идёт полтора часа, десятая часть тестов падает без изменений в коде, разбор красного прогона занимает у команды час каждое утро. Дальше происходит предсказуемое — прогон отключают «на время», и он больше не включается.

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

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

Что покрывать сквозными тестами: карта сценариев по приоритетам

Список сценариев собирается не от структуры приложения, а от денег. Каждый кандидат проверяется тремя вопросами:

1. Теряет ли компания деньги, если сценарий сломается? Оформление заказа — да. Экран «О компании» — нет.
2. Как часто им пользуются? Вход в приложение проходят все, отмену заказа — единицы.
3. Сколько систем задействовано? Чем больше стыков, тем меньше шансов, что путь проверят другие уровни тестов.

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

Приоритет 1: без этих сценариев магазин не продаёт

• Регистрация и вход — по номеру телефона с кодом из СМС, по почте, через сохранённую сессию после перезапуска приложения.
• Поиск и открытие карточки товара — поиск по названию и по артикулу, переход из категории, отображение цены и наличия.
• Корзина — добавление, изменение количества, удаление, сохранение содержимого после перезапуска.
• Оформление заказа с оплатой — картой и через систему быстрых платежей, с возвратом в приложение после подтверждения.
• Промокод и бонусы — применение, пересчёт итоговой суммы, передача этой суммы дальше в заказ.
• Заказ после оформления — появился в личном кабинете, виден его статус, ушёл в учётную систему.
• Восстановление доступа — путь, который человек проходит в состоянии раздражения, и любая ошибка здесь заканчивается уходом.

Приоритет 2: расширение после того, как первая группа стабильна

• Выбор способа доставки и адреса — курьер, пункт выдачи на карте, самовывоз из конкретного магазина.
• Оплата сохранённой картой и повтор заказа — сценарий вернувшегося покупателя, у которого другой путь и другие экраны.
• Отмена заказа и возврат — вместе с проверкой, что возврат отражается в учёте.
• Переход из push-уведомления на нужный экран по ссылке внутри приложения. Как устроена сама доставка сообщений — в описании услуги push-уведомлений и в статье о push-уведомлениях в приложении.
• Смена города или магазина — остатки, цены и сроки доставки меняются вслед за выбором.
• Путь нового пользователя целиком — от установки до первого оплаченного заказа, без единого повторного входа.

Приоритет 3: зависит от модели бизнеса

• Заказ на юридическое лицо — реквизиты, счёт, отсрочка платежа. Для оптового направления это первый приоритет, а не третий; подробности — в услуге B2B-приложений для юридических лиц.
• Сканирование штрихкода в торговом зале — сценарий магазина, где приложение работает рядом с полкой.
• Программа лояльности со статусами — переход между уровнями и пересчёт правил начисления.
• Отзывы, оценки и обращения в поддержку — пути, которые редко ломают выручку напрямую, но заметны в оценках приложения.

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

Чего сквозными тестами не проверяют

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

Отдельно про скорость: сквозные тесты и производительность — соседние, но разные темы. Тест дождётся ответа и покажет зелёный результат, даже если ответ пришёл через пять секунд. Где именно теряется плавность, мы разбирали в материале про производительность Flutter-приложения, а поведение системы в час пиковой нагрузки — в статье о высоконагруженных системах. Тему защиты платёжных данных отдельно разбирает материал о безопасности платежей в мобильном приложении.

Разбор одного сценария: оформление заказа с оплатой

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

Шаг 10 — тот, ради которого сценарий и называется сквозным. Без него тест проверяет приложение, а не продажу: заказ может красиво отобразиться на экране и не доехать до учёта. Как устроен сам обмен данными, мы разбирали в статье об автоматизации учёта товара в рознице, а формат обращений между приложением и серверной частью — в материале о проектировании REST API. Настройку самого обмена закрывает услуга интеграции с учётной системой, а связку с системой продаж — интеграция приложения с CRM.

Шаг 11 в наборах пропускают чаще всего, и именно он потом даёт «тест проходит только с первого раза». Если прогон оставляет после себя товар в корзине и неотменённый заказ, второй прогон начинается из другого состояния и падает на шаге 3.

Чем это пишется. Для приложений на Flutter путь целиком проходят встроенные интеграционные тесты — тот же код работает и на iOS, и на Android, что для единой кодовой базы означает один набор сценариев вместо двух. В нативной разработке те же задачи закрывают Espresso на Android и XCTest на iOS, но набор придётся вести дважды. Как устроена сама единая кодовая база для приложения и сайта — в описании кроссплатформенной разработки на Flutter и в услуге Flutter для e-commerce.

Стенд, тестовые данные и внешние сервисы

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

1. Отдельный стенд. Прогоны идут не на боевой системе: тест создаёт заказы, меняет остатки и отменяет то, что создал. Стенд повторяет боевую сборку по составу сервисов, а каталог на нём — уменьшенная копия настоящего.
2. Свои данные. У набора собственные пользователи, собственные товары и собственные промокоды. Общие данные с ручной проверкой приводят к тому, что тест падает, потому что кто-то менял тот же товар руками.
3. Тестовый режим оплаты. Платёжные шлюзы дают тестовые реквизиты и набор карт с заданным поведением: успешная оплата, отказ банка, недостаток средств. Настоящие деньги в прогоне не участвуют, а сценарий отказа проверяется так же, как успешный.
4. Предсказуемый вход. Код из СМС — частая причина, по которой набор не удаётся запустить автоматически. Решение стандартное: отдельный тестовый номер с фиксированным кодом, который работает только на стенде.
5. Граница заглушек. Внешние сервисы можно заменить заглушкой — упрощённым ответом вместо настоящего вызова. Заглушка убирает нестабильность, но вместе с ней убирает и смысл проверки: заглушенный платёж не докажет, что оплата работает.

По последнему пункту работает простое правило: то, ради чего сценарий назван сквозным, заглушкой не заменяется. Для оформления заказа это платёжный шлюз и учётная система — они остаются настоящими, только в тестовом режиме. Всё остальное, что мешает и не относится к сути проверки (внешняя служба рекомендаций, сервис отзывов, сторонняя аналитика), заглушается без потерь.

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

Нестабильные тесты: почему наборы забрасывают

Сквозные наборы редко умирают от того, что их не написали. Они умирают от нестабильности: тест падает без изменений в коде, команда привыкает к красному результату и перестаёт его разбирать. Восемь причин, которые встречаются чаще остальных:

1. Ожидание по таймеру вместо ожидания события. «Подождать три секунды и нажать» работает на быстрой машине и падает на загруженной. Правильное ожидание — до появления элемента или до завершения запроса, с предельным сроком.
2. Поиск элемента по видимой надписи. Маркетолог поменял «Оформить заказ» на «К оплате» — упало двадцать тестов. Устойчивый признак элемента задаётся в коде разработчиком и не зависит от текста на кнопке.
3. Общие данные между сценариями. Два теста используют одного пользователя, запускаются одновременно и мешают друг другу.
4. Зависимость от порядка запуска. Сценарий проходит только после другого сценария, который создал ему нужное состояние. При параллельном прогоне такой набор рассыпается.
5. Живой внешний сервис в сценарии, который не про него. Сторонняя служба отвечает медленно раз в сто прогонов — и этого достаточно, чтобы набор считали ненадёжным.
6. Один тест проверяет пятнадцать вещей. Упал на девятой — по отчёту непонятно, что сломалось. Сценарий должен проверять один путь, а не всё приложение.
7. Красный прогон никто не разбирает в тот же день. За неделю накапливается десяток падений, и разобрать их разом уже невозможно.
8. Прогон запускается вручную. Пока запуск зависит от человека, он пропускается ровно в те дни, когда нужен больше всего.

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

Второе правило касается порядка работ. Устойчивые признаки элементов проставляются в коде до того, как написан первый сценарий. Если этот шаг пропустить, набор пишется через поиск по надписям, а потом переписывается целиком — и в смете это выглядит как двойная оплата одной работы.

Метрики: как понять, что набор окупается

Сквозные тесты — статья расходов, которая продолжается всё время жизни продукта, поэтому её результат стоит измерять. Шесть показателей, которых достаточно для решения «продолжаем или меняем подход»:

Последняя строка — самая деловая из шести. Смысл автоматической проверки не в отчёте с зелёными галочками, а в том, что обновление выходит тогда, когда оно готово, а не тогда, когда закончилась ручная проверка. В кейсе Street Beat за пять месяцев после запуска команда закрыла 700+ задач и выпустила 7 релизов — такой темп держится только при автоматической проверке повторяющихся путей. Остальные показатели продукта и разработки разбирают материалы о 15 метриках разработки и об аналитике мобильного приложения.

Чек-лист внедрения: с чего начать

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

1. Выпишите 5–7 путей, где ломается выручка. Не функций, а путей — от входа до результата в учёте.
2. Проверьте, есть ли у элементов интерфейса устойчивые признаки. Если их нет, проставьте до написания сценариев.
3. Поднимите стенд с отдельной базой и уменьшенной копией каталога.
4. Договоритесь о тестовых данных — пользователи, товары, промокоды, тестовый номер с фиксированным кодом.
5. Включите тестовый режим платёжного шлюза и получите набор карт с заданным поведением.
6. Напишите первый сценарий — «нашёл, положил в корзину, оплатил, увидел заказ в учёте».
7. Поставьте прогон на автоматический запуск при каждом изменении кода, а полный набор — по расписанию раз в сутки.
8. Настройте отчёт со снимком экрана и записью происходившего в момент падения.
9. Введите правило разбора красных прогонов в тот же день и назначьте ответственного за набор.
10. Расширяйте до второй группы приоритета только после того, как первая проходит стабильно.
11. Пересматривайте список раз в квартал — сценарии, которые перестали быть про деньги, удаляйте, а не поддерживайте по инерции.

Пункт 11 в наборах игнорируют чаще всего. Набор растёт год за годом, время прогона растёт вместе с ним, а половина сценариев проверяет функции, которыми давно никто не пользуется. Удаление устаревшего теста — такая же нормальная работа, как написание нового.

Кто это делает и из чего складывается смета

Сквозной набор ведут три роли. QA-инженер по автоматизации пишет и сопровождает сценарии. Разработчик проставляет в коде устойчивые признаки элементов и правит то, что тесты нашли. DevOps-инженер настраивает стенд и автоматический запуск при каждом изменении кода. На небольшом проекте эти роли совмещаются, но пропустить нельзя ни одну: набор без стенда не запускается, а без признаков элементов — не пишется.

Смета складывается из четырёх частей, и первая обычно недооценивается:

1. Подготовка — стенд, тестовые данные, тестовый режим оплаты, признаки элементов в коде. Разовая работа, но заметная по объёму.
2. Написание сценариев — считается по количеству путей и числу задействованных систем, а не по количеству экранов.
3. Настройка автоматического запуска и отчётов — тоже разовая часть.
4. Сопровождение — регулярная ежемесячная работа: каждое изменение интерфейса и каждый новый модуль требуют правки сценариев.

Как это устроено у нас. FITTIN — модульная Flutter-платформа: приложение и сайт интернет-магазина собираются из готовых модулей (каталог, поиск, корзина, оплата, лояльность, push, интеграции с 1С и маркетплейсами), а уникальные сценарии дописываются на исходном коде. Для сквозных проверок это означает конкретную вещь: базовые пути каталога, корзины и оплаты уже реализованы и проверены внутри модулей, поэтому под проект пишутся сценарии на брендовые отличия и на интеграции конкретного клиента, а не весь путь покупателя с нуля. QA-инженер входит в закреплённую за проектом команду вместе с аналитиком, дизайнером, Flutter- и бэкенд-разработчиками и руководителем проекта — проверка идёт параллельно разработке, а не отдельным этапом после неё.

Модель оплаты состоит из трёх частей. Первая — единоразовая интеграция платформы под ваш бренд, до 30 рабочих дней. Вторая — ежемесячные лицензионные платежи, в которые уже включены затраты на техническую поддержку команды FITTIN: мониторинг, обновления модулей и обновления безопасности, поэтому собственная команда разработки для базового сопровождения не требуется. Третья — новый функционал и доработки отдельно, по Time & Materials, с оценкой задачи в часах перед стартом. Расширение сквозного набора под уникальные сценарии относится к третьей части. Действующие пакеты и суммы — на странице тарифов, порядок бюджета под задачу считает калькулятор стоимости.

Что можно взять по частям: тестирование и QA мобильных приложений — на постановку процесса целиком; аутстаффинг QA-инженеров, Flutter-разработчиков и DevOps-инженеров — на усиление своей команды; аудит мобильного приложения, аудит кода и комплексный аудит интернет-магазина — на обследование существующего продукта; техническую поддержку приложений — на постоянное сопровождение, в том числе продуктов, сделанных другими подрядчиками. Требования к проверкам полезно зафиксировать письменно до старта работ — этим занимается разработка технического задания.

Серверная часть у нас делается на Python: разработка на Django для крупных каталогов и админок, разработка на FastAPI — для программных интерфейсов с высокой долей одновременных обращений. Устройство самой платформы описано в статье о модульной платформе для e-commerce, а состав работ по проекту целиком — в услуге комплексной разработки интернет-магазина. Готовые решения для торговли — мобильные приложения для e-commerce и сайты интернет-магазинов.

Кейсы: где сквозные проверки были частью задачи

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

Ещё два среза. В кейсе «Европа Маркет» (149 839 пользователей) покупатель пользуется приложением, стоя у полки: сканирует штрихкод, ищет товар, смотрит скидку по карте лояльности — такой сценарий проверяется целиком, потому что человек ждёт ответ здесь и сейчас. В кейсе DAISYKNIT приложение переезжало с коробочного решения на Flutter с сохранностью клиентской базы 100%: при переезде сквозные пути проходятся дважды — на старых данных и на перенесённых. Как ведёт себя онлайн-ритейл по сезонам и каналам, регулярно разбирает Data Insight. Остальные проекты — в разделе кейсов.

Итог: сквозное тестирование на одной странице

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

1. Сценарии отбираются по деньгам, а не по структуре приложения. Три вопроса: теряется ли выручка, часто ли этим пользуются, сколько систем задействовано.
2. Начинайте с одного пути — «нашёл, положил в корзину, оплатил, увидел заказ в учёте». Он задевает больше стыков, чем любой другой.
3. Держите пирамиду. Комбинации данных и граничные значения — на модульном уровне, сквозной уровень остаётся узким.
4. Не заглушайте то, ради чего сценарий сквозной. Платёжный шлюз и учётная система остаются настоящими, но в тестовом режиме.
5. Устойчивость важнее охвата. Нестабильный тест чинится в тот же день или выносится из основного прогона с задачей на исправление.
6. Запуск — автоматический, при каждом изменении кода, с записью происходившего в момент падения.
7. Раз в квартал чистите набор — устаревший сценарий удаляют, а не поддерживают по инерции.

Что делать дальше:

• Поставить процесс проверок целиком — тестирование и QA мобильных приложений; понять состояние существующего продукта — аудит мобильного приложения или аудит кода.
• Проверить смежные слои — нагрузочное тестирование на поведение под нагрузкой, аудит UX/UI на удобство сценариев, A/B-тестирование на выбор варианта интерфейса.
• Усилить команду — QA-инженеры, Flutter-разработчики, DevOps-инженеры; передать сопровождение — техническая поддержка приложений.
• Зафиксировать требования до старта работ — разработка технического задания; посчитать порядок бюджета — калькулятор стоимости; описать задачу — контакты.

Вопросы и ответы

Чем сквозной тест отличается от интеграционного?

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

Сколько сквозных тестов нужно интернет-магазину?

Считать стоит не тесты, а пути. Обязательный минимум — семь путей приоритета 1: вход, поиск и карточка товара, корзина, оформление с оплатой, промокод и бонусы, заказ в личном кабинете и в учёте, восстановление доступа. Дальше добавляется вторая группа: доставка и пункт выдачи, повтор заказа, отмена и возврат, переход из push-уведомления, смена города. По нашему опыту набор у интернет-магазина редко выходит за несколько десятков сценариев — дальше растёт время прогона, а прирост найденных ошибок останавливается.

Можно ли автотестами заменить ручную проверку?

Полностью — нет, и такой цели не ставят. Автоматика сильна в повторении: она без устали проходит одни и те же пути перед каждым выпуском и снимает с людей рутину регрессии. Человек сильнее в другом — замечает то, что никто не описал заранее: съехавшую вёрстку на узком экране, неудобный порядок шагов, странное поведение после входящего звонка. Рабочее распределение выглядит так: повторяющиеся денежные пути закрывает автоматика, новую функциональность и внешний вид проверяет человек.

Сколько времени занимает написание одного сценария?

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

Тесты падают через раз — это нормально?

Нет, и это состояние опаснее, чем отсутствие тестов: команда привыкает к красному результату и перестаёт отличать обычное падение от настоящей ошибки. Типичные причины — ожидание по таймеру вместо ожидания события, поиск элемента по надписи на кнопке, общие данные между сценариями и живой внешний сервис там, где сценарий не про него. Лечится это правилом: нестабильный тест чинится в тот же день либо выносится из основного прогона с заведённой задачей и сроком. Разобраться в причинах на существующем проекте помогает аудит кода и истории прогонов.

Нужны ли сквозные тесты, если приложение собрано из готовых модулей платформы?

Нужны, но объём работы меньше. Базовые пути каталога, корзины и оплаты уже реализованы и проверены внутри модулей платформы, поэтому под проект пишутся сценарии на то, что отличает конкретный магазин: интеграцию с его учётной системой, его правила лояльности и промокодов, его способы доставки и оплаты, кастомные доработки под бренд. Именно эти места и ломаются чаще всего, потому что они уникальны для проекта и нигде больше не проверялись.

Как проверять оплату, не тратя настоящие деньги?

Платёжные шлюзы дают тестовый режим: отдельные реквизиты магазина и набор карт с заданным поведением — успешная оплата, отказ банка, недостаток средств, истёкший срок карты. Прогон идёт по тем же экранам, что и настоящая покупка, но деньги не списываются. Сценарии отказа проверяются наравне с успешным: приложение должно вернуть покупателя на понятный экран с объяснением, а не оставить его в браузере. Отдельно стоит убедиться, что тестовый режим включён только на стенде и не может оказаться в сборке для магазина приложений.

Что делать, если в приложении нет устойчивых признаков у элементов?

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

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.