Каждый уровень тестирования играет определённую роль в разработке программного обеспечения и отвечает на отдельный вопрос:
Unit-тесты - «Изменилась ли функция, которая должна была остаться прежней?» Они тестируют мельчайшие изолированные фрагменты кода (отдельные функции или методы) независимо от остальной системы. (Подробный разбор unit-тестов приведён в отдельной статье блога.)
Интеграционные тесты - «Продолжают ли компоненты правильно работать вместе после изменения?» Они тестируют реальные связи между модулями (например, база данных + сервисный слой + API), а не только изолированные функции. Они выявляют сценарии, в которых отдельные части проходят проверку по отдельности, но ломаются в комбинации.
E2E-тесты (End-to-End) - «Работает ли система так, как её увидит реальный пользователь?» Они имитируют полные пользовательские сценарии (вход → действие → результат) через настоящий UI или API. Они ловят регрессии, которые не могут обнаружить ни unit-, ни интеграционные тесты, потому что такие проблемы проявляются только в реальном сценарии.
(Существуют, конечно, и другие виды тестирования, например *Smoke-тесты**, нагрузочное или тестирование безопасности, но они выходят за рамки этой статьи.)*
У всех уровней автоматизированного тестирования есть общая цель: убедиться, что функциональность не сломалась за пределами объёма задачи, над которой сейчас идёт работа. Задача может быть выполнена идеально по спецификации и всё же сломать что-то другое как непреднамеренный побочный эффект. Без уровня тестирования, выходящего за рамки конкретного изменения, никто не заметит этого, пока пользователь не сообщит о проблеме в продакшене.
Незаменимая роль ручного тестирования
Несмотря на продвинутую автоматизацию и интеграцию AI, ручное тестирование сохраняет свою незаменимую и первостепенную роль. Живой тестировщик привносит настоящее суждение, интуицию и способность замечать тонкие нюансы или неожиданное поведение UI, которые автоматические скрипты легко упускают. Ручная проверка была, есть и всегда будет тем, что даёт команде разработки 100% уверенность в том, что приложение готово для реальных пользователей.
Разработка с помощью AI и компенсация «слепоты»
В эпоху разработки с помощью AI слой автоматизированного тестирования ещё важнее. AI-агент не может воспринимать всю систему целиком, поэтому побочные эффекты у него вероятнее, чем у разработчика-человека, который хранит в голове весь контекст и историю прошлых решений. Тесты служат механизмом, который систематически компенсирует эту слепоту системы до того, как код дойдёт до финального одобрения человеком.
Практическое влияние: сложности E2E-тестирования с AI
Создавать E2E-тесты для AI особенно сложно. Дело не только в написании самого тестового скрипта, но прежде всего в подготовке подходящих тестовых данных, чтобы программа могла ими пользоваться (часто лишь для небольшой части теста). Подготовка этих данных очень трудоёмка.
Возьмём кажущееся простым действие: щёлкнуть по выпадающему списку и выбрать параметр (например, тип документа Счёт-фактура). Если тест падает или не завершается, критически важно определить точную первопричину. Могли произойти самые разные ситуации:
- AI заблудился и не смог найти элемент выпадающего списка в UI (хотя он там есть).
- Тест столкнулся с более ранней ошибкой на пути и не смог восстановиться.
- Выпадающий список существует, но не содержит ожидаемых данных для выбора.
- AI прибегнул к JavaScript (невидимый обходной путь), успешно установив значение программно, но оставив его невидимым для настоящего пользователя.
Вокруг одного выпадающего списка может возникнуть множество проблем. Главное - способен ли AI (или система оценки) отличить настоящую ошибку от каскадного сбоя, вызванного чем-то другим. Одно лишь успешное сохранение данных не гарантирует, что всё работает правильно.
Поведенческий подход и покрытие тестами
Поэтому тесты всегда должны быть сосредоточены на поведенческом аспекте системы, проверяя то, что мы на самом деле ожидаем:
Happy Path (~90% случаев): основное внимание уделяется тому, что пользователи будут делать подавляющее большинство времени.
Критические граничные случаи: предельные условия, которые возникают нечасто, но жизненно важны для целостности системы.
Другие, менее вероятные комбинации заранее не тестируются. Если они возникают в продакшене, их исправляют на ходу или предотвращают программными ограничениями и валидацией (например, блокировкой перехода дальше, пока ввод не станет корректным).
E2E-тестирование в AITM
В AITM E2E-тестирование - это явная и обязательная фаза pipeline для задач, затрагивающих UI (определяется по типу/намерению задачи). Это не необязательное дополнение, которое можно пропустить при поджимающих сроках - pipeline нельзя отметить завершённым без него.
Если E2E-теста нет или среда недоступна, сборка по умолчанию падает (с редкими исключениями, когда допускается продолжение при неудачном E2E). Кроме того, каждый запуск E2E сохраняет скриншоты, которые видны в результатах задачи.
Как E2E работает сейчас:
- Перед запуском тестов гарантируется успешная сборка, которая выполняется в собственном изолированном worktree.
- Состояние базы данных подготавливается с конкретными тестовыми данными вместе с записями по умолчанию.
- Тестирование строго сосредоточено на Happy Path (не покрывает все возможные сценарии).
План развития E2E:
- Flow Maps - система строит карту путей к заданным элементам, напрямую связанным с бизнес-логикой (уже интегрировано в AITM).
- Автономная навигация - тесты читают актуальную карту путей и точно знают, куда нажимать, что вводить и что проверять (сейчас проходит тестирование).
- Сравнение состояний (Visual Diffing) - каждый шаг записывается скриншотами до и после изменений кода, чтобы подтвердить, что ожидаемые элементы и данные соответствуют ожиданиям по БД или UI.
- Проверка бизнес-логики - автоматическая проверка ожидаемых выходных данных (например, проверенные итоги счетов - сейчас в разработке).
- Ночные интеграционные прогоны - сквозные интеграционные тесты будут генерироваться автоматически из состояний шагов и требований к программе и запускаться ночью. Любые сбои будут порождать задачи или запрашивать проверку человеком (поскольку AI может ошибаться и нуждается в подтверждении человеком).
- Расширенные сценарии - будущие релизы добавят внедрение некорректных параметров, тестирование многоэкземплярной параллельной работы и симуляцию граничных случаев.
Итоги: основные принципы E2E
Суть эффективного E2E-тестирования опирается на управление картами и связями между сущностями данных. Для 90% программного обеспечения всё сводится к стандартному жизненному циклу:
#AITM #Data Input Validation #E2E #Integration test #AI TESTING