Стратегия тестирования при внедрении ИИ в разработку ПО
1. Старт без автотестов и развитие покрытия
До первой задачи должен существовать достаточный способ проверить её результат, в том числе временный. Развитие остального тестового покрытия может идти позже; средство проверки, необходимое первой задаче, нельзя откладывать под видом общего плана автоматизации. Как определить эту границу.
Наличие готовых автотестов не является условием старта внедрения. Развитие поддерживаемого автоматизированного тестирования — ключевое условие устойчивого эффекта от агента. Оно позволяет повторять проверки без постоянного написания и отладки новых средств проверки.
Без готового набора агенты выполняют аналог «ручного» тестирования: исследуют поведение, вызывают API, работают с UI и создают временные скрипты. Для первых задач это допустимо. Но если каждую следующую задачу проверять заново написанными скриптами, снова расходуются время, инференс и участие людей, а защита от повторных дефектов не накапливается.
Проверка временным скриптом может быть автоматической по способу выполнения, но ещё не является поддерживаемым регрессионным тестом. Для этого её нужно сохранить, проверить, обеспечить повторяемый запуск и включить в регулярный набор.
Наличие тестов само по себе не гарантирует успеха. Важно, чтобы они проверяли нужное поведение, обнаруживали ошибки и использовались на актуальном результате. Основания завершения Пилота остаются указанными в процессе внедрения: целевые метрики либо поддержанный командой план их достижения.
2. Какие тесты должны появиться в проекте
В целевом наборе предусматриваются unit-тесты, API-автотесты и UI-автотесты для применимых частей продукта. Кроме них рассматриваются интеграционные и контрактные проверки. Для каждого применимого вида фиксируется, что уже есть, чего не хватает и когда закрывается пробел. Отсутствие UI или API — обоснованная неприменимость соответствующего вида, а не требование создавать искусственные проверки.
Термины описывают разные стороны теста: unit и интеграционный — границу проверки, API и UI — интерфейс взаимодействия, E2E — сквозной охват. Например, API-тест может быть интеграционным или сквозным. В реестре это одна проверка с несколькими признаками, а не несколько тестов.
| Вид | Что проверяет | Где и с чем запускается | Что предусмотреть |
|---|---|---|---|
| Unit | Небольшие единицы логики: расчёты, правила, переходы состояния | Без развёрнутого стенда, в процессе тестового раннера; зависимости изолированы | Быстрый запуск, граничные случаи, фиксация исправленных ошибок |
| Компонентные и интеграционные | Работу компонента и взаимодействия с БД, очередью, файловым хранилищем или другим модулем | В тестовом окружении с нужными зависимостями; полный DEV-стенд часто не нужен | Подготовка и очистка состояния, миграции, реальные особенности используемых зависимостей |
| Контрактные | Совместимость запросов, ответов и сообщений между потребителем и поставщиком | Отдельными проверками сторон контракта; обычно без полного сквозного стенда | Проверяемые ожидания и версии контрактов; проверка стороны поставщика, а не только собственного мока |
| API-автотесты | Поведение через API: бизнес-сценарии, валидацию, доступ, ошибки | Для проверок развёрнутого приложения — DEV с заданными данными и зависимостями; для компонента возможен отдельный тестовый запуск | Положительные, отрицательные и граничные сценарии, состояние после операции |
| UI-автотесты | Поведение пользовательского интерфейса: действия, отображение, взаимодействие элементов | Компонент UI можно проверить изолированно; браузерные проверки приложения — на DEV с управляемыми данными | Основные пользовательские маршруты и риски UI, устойчивый способ обращения к элементам |
| Сквозные E2E | Полный бизнес-сценарий через несколько частей системы | На подготовленном стенде; реальные зависимости и заменённые моками явно перечислены | Набор критичных маршрутов; сложная среда не должна быть единственным способом проверить простое правило |
Быстрые локальные проверки и проверки взаимодействий дополняют сквозные сценарии; распределение зависит от архитектуры, универсальное соотношение количества тестов не задаётся. Описание уровней и практики тестовой пирамиды.
Контрактные проверки помогают обнаруживать несовместимость взаимодействующих сторон. Тест только на собственном моке не доказывает, что реальный поставщик соблюдает ожидания. Описание подхода в документации Pact. Использование именно Pact не требуется.
Unit-тесты и другие проверки без стенда
«Без стенда» означает, что для прогона не требуется деплой приложения на DEV или UAT. Тесты могут выполняться в специальном контейнерном образе с нужными библиотеками и инструментами. Образ запуска и версии зависимостей фиксируются.
Для части проверок может понадобиться отдельная тестовая БД, контейнер БД или временная схема. По принятой здесь терминологии проверка реального взаимодействия с такой БД относится к интеграционным тестам, даже если у клиента весь набор называется unit. Это не мешает запускать их вместе в CI; важно понимать зависимости и стоимость запуска.
Для тестовой БД задаются изоляция параллельных прогонов, начальные данные, миграции и очистка. Её состояние не зависит от текущей занятости DEV/UAT. Если используется упрощённая замена БД, отдельно отмечается, какие особенности реальной БД таким прогоном не проверяются.
3. Назначение проверок: что ещё нужно учесть
Это не дополнительные взаимоисключающие уровни. Smoke и регрессия могут состоять из API-, UI- и других тестов; проверки отказов также могут выполняться на разных уровнях.
| Назначение | Содержание | Применение в методологии |
|---|---|---|
| Smoke | Короткая проверка готовности и основных функций | После деплоя артефакта из хранилища на выбранный стенд; на старте допустим явный проверяемый сценарий, далее — поддерживаемый автоматический набор |
| Регрессия | Сохранность ранее работавшего поведения | Затронутые проверки — по задаче; более широкий набор — по согласованному расписанию или перед выпуском |
| Отказы и восстановление | Ошибки, тайм-ауты, повторы, недоступность зависимости, восстановление и целостность данных | Управляемые моки и тестовые данные для значимых сценариев; не только проверка появления сообщения об ошибке |
| Регулярные операции и время | Сроки, расписания, таймеры, повторные и пропущенные срабатывания | Виртуальное время или управление заданиями по гайду инфраструктуры; проверяются результат и побочные эффекты |
| Данные и миграции | Изменения схемы, преобразование и сохранность данных | При соответствующих изменениях; воспроизводимый набор исходных данных и проверка результата миграции |
| Нагрузка и производительность | Поведение при выбранном профиле нагрузки, росте объёма данных и длительности работы | По рискам и согласованным требованиям; отдельный план условий, измерений и ресурсов |
| Устойчивость / chaos | Поведение системы при управляемом нарушении работы компонентов или сети | Контролируемый эксперимент с гипотезой, наблюдением и восстановлением; применяется там, где оправдан рисками |
| Безопасность | Права доступа, изоляция данных, значимые негативные сценарии; проверки зависимостей и кода | Обязательные правила клиента сохраняются; объём специальных проверок согласуется для продукта |
| Совместимость и доступность UI | Поддерживаемые браузеры и устройства, работа с клавиатурой и другие требования доступности | Если эти свойства значимы для выбранного интерфейса |
| Исследовательское тестирование и UAT | Новые риски, удобство, смысл бизнес-поведения и продуктовая приёмка | Люди сохраняют эти функции; агенты и автотесты помогают, но не подменяют решение принимающего |
Статический анализ, линтеры, проверка типов и анализ зависимостей также входят в проверки качества, но не заменяют выполнение тестов поведения.
Нагрузочные проверки
Выбирается конкретная цель: обычная ожидаемая нагрузка, повышенная нагрузка (stress), резкий всплеск (spike) или длительная работа (soak). Эти виды отвечают на разные вопросы; перечень и профиль определяются рисками проекта. Описание типов нагрузки в документации k6.
Для прогона фиксируются артефакт из хранилища, конфигурация и ресурсы стенда, объём данных, нагрузочный профиль и измеряемые показатели: например, задержки, доля ошибок и пропускная способность. Пороговые значения задаёт команда по требованиям, а не по результату уже выполненного прогона.
Нагрузку выполняют на выделенном контуре или в согласованном окне с достаточной изоляцией. Влияние генератора нагрузки, общих ресурсов и моков учитывают при интерпретации. Ускорение бизнес-времени не заменяет длительный прогон для поиска утечек ресурсов или деградации. Без репрезентативных условий выводы о производительности ограничены.
Проверки отказов и chaos
Детерминированный ответ мока «ошибка», после которого проверяется повторная попытка, — проверка обработки отказа. Chaos-эксперимент рассматривает поведение системы при управляемом воздействии: например, остановке экземпляра сервиса или нарушении сетевого взаимодействия. Его основа — гипотеза о наблюдаемом поведении и попытка её проверить. Principles of Chaos Engineering.
В рамках внедрения такой эксперимент планируется на согласованном тестовом контуре: задаются воздействие, границы, ожидаемое поведение, измерения, условия остановки и восстановление. Эксперимент не должен нарушать чужие задачи или текущую приёмку.
Связь с границами внедрения
В базовый поток по-прежнему входят функциональные задачи, выбранные для PoC и Пилота. Описанные виды проверки нужны для качества этих задач и развития тестового набора. Это не означает автоматического включения самостоятельного потока реализации нефункциональных требований.
Существующие обязательные проверки клиента сохраняются. Новая программа нагрузки, chaos или других специализированных проверок включается по применимости и риску с отдельными ресурсами и планом. Если такой проверки нет, а она нужна для текущей задачи, пробел фиксируется вместе со способом его закрытия; неподтверждённое свойство не объявляется проверенным.
4. Как развивать тесты по этапам
| Этап | Что делаем |
|---|---|
| Подготовка | Инвентаризируем существующие тесты, команды запуска и зависимости. Для выбранного потока определяем применимые виды, пробелы, ответственных и план. Отсутствие готового набора не блокирует старт само по себе |
| PoC, фаза 1 — неделя 1: онбординг | Настраиваем команды и навыки проверок; подтверждаем минимальный проход QA-07/QA-11 и FLOW-11 на небольшой задаче. Используем имеющиеся проверки либо явный временный способ; сохраняем результаты |
| PoC, фаза 2 — неделя 2: простые задачи | Закрепляем повторяющиеся проверки в репозитории: unit для затронутой логики, API и UI по применимости. Готовим данные и запуск без повторного изобретения инструмента |
| PoC, фаза 3 — недели 3–4: целевые задачи | Проверяем типичные задачи будущего Пилота, включая нужные интеграции, время и отказы. Определяем рабочий smoke и регрессионный набор; незакрытые пробелы включаем в план |
| Пилот | Каждую неделю планируем улучшения тестов вместе с задачами продукта, разбираем дефекты, временные скрипты и нестабильные проверки. Расширяем полезное покрытие, измеряем повторное использование и эффект |
Полный набор всех видов к началу Пилота не требуется. Однако для каждой выполняемой задачи должен быть согласован достаточный способ проверки результата. Отсутствие готовых автотестов не означает отсутствие тестирования и не отменяет обязательных проверок клиента.
Приоритет автоматизации: повторяющиеся критичные сценарии, проверки изменяемой логики, случаи уже найденных дефектов и проверки, которые отнимают заметное время на повторную подготовку. Процент покрытия кода и число тестов не используются как единственные цели.
5. Когда временный скрипт становится поддерживаемым тестом
Повторяющаяся проверка включается в план автоматизации. Готовность подтверждается следующим:
- Тест сохранён в репозитории и связан с проверяемым требованием, сценарием или дефектом.
- Ожидаемый результат определён по требованиям; тестировщик или разработчик проверил, что тест способен обнаружить нужную ошибку.
- Есть постоянная команда запуска, зафиксированные зависимости, подготовка и очистка данных.
- Параллельные прогоны не меняют состояние друг друга.
- Тест запускается регулярно в CI или другом согласованном процессе, а его отказ виден ответственному.
- Результаты содержат ревизию тестов, проверяемую ревизию кода, условия и доказательства; для стендовых проверок — идентификатор артефакта и запись деплоя.
- Назначен владелец поддержки и порядок изменения теста вместе с продуктом.
Агент может писать и поддерживать тесты. Разработчик рассматривает техническую корректность, тестировщик — смысл сценариев и достаточность проверок; роли могут совмещаться. Подробный маршрут описан в регламенте ревью.
Нестабильный тест разбирают как проблему: сохраняют все результаты повторных запусков, назначают исправление, явно отмечают исключения. Повтор до первого зелёного результата или ослабление утверждений не подтверждают качество.
6. Запуск и доказательства
Без стенда: тестовый раннер проверяет точную ревизию кода в заданном окружении; отдельно поднимаются необходимые временные зависимости. Это не деплой приложения в DEV/UAT.
На стенде: приложение собирается, артефакт публикуется в хранилище, затем выполняется деплой выбранного артефакта на целевой стенд. Тесты фиксируют именно этот артефакт, конфигурацию, данные, сценарии моков и настройки времени. UAT используется по правилам приёмки клиента; агент имеет доступ для разбора замечаний, а автоматические операции выполняет в согласованных пределах.
Проверки для каждой задачи выбираются по изменению и риску. Быстрые проверки запускаются при изменении кода, smoke — после деплоя, затронутая регрессия — после исправлений, более широкие и дорогие прогоны — по установленным событиям или расписанию. Конкретные команды и порядок входят в профиль проекта.
7. Реестр тестов и план развития
Это детализация тестовой части общего реестра артефактов проекта. Требования, спецификации и тест-кейсы учитываются там по основным источникам; здесь описываются виды проверок и запуск. Оба реестра ссылаются на одни задачи развития, без дублирования планов. Ожидания тестов связываются с согласованными правилами по гайду требований.
| Вид / назначение | Применимость и сценарии | Что уже есть и где хранится | Как и где запускается | Пробел или временный способ | Что добавляем, кто отвечает и срок | Как подтвердим результат |
|---|---|---|---|---|---|---|
| Unit | … | … | Без стенда; образ и команда | … | … | … |
| Интеграционные / контрактные | … | … | Зависимости, БД, контракт | … | … | … |
| API | … | … | Стенд или компонент; команда | … | … | … |
| UI / E2E | … | … | Браузер, стенд, данные | … | … | … |
| Smoke / регрессия | … | … | Состав набора и событие запуска | … | … | … |
| Время / отказы / миграции | … | … | Инструменты, сценарии | … | … | … |
| Нагрузка / chaos / другие специальные проверки | … | … | Контур, условия, ресурсы | … | … | … |
Один тест может входить в несколько наборов; его сопровождение и трудозатраты не учитываются повторно.
На еженедельном разборе Пилота фиксируются:
- Какие значимые сценарии теперь проверяются повторяемым набором и какие остаются непокрытыми.
- Где агенты снова писали временные скрипты, сколько это стоило и что решено сохранить.
- Затраты на создание, поддержку и запуск тестов; время прогонов и ожидания.
- Нестабильные тесты, пропуски и дефекты, не обнаруженные текущими проверками.
- Изменение трудозатрат и времени задач с учётом качества.
Это диагностика причин эффекта, а не новый личный рейтинг или дополнительное основание завершения Пилота. Привязка к учёту — в метриках, планирование — в недельном журнале.