Надёжное тестирование продукта кибербез-опасности: опыт оптимизации
Процесс автоматизации тестирования находился в критическом состоянии:
-
87% автотестов падало из-за неактуальности и нестабильности;
-
полный регресс занимал более 12 часов;
-
ручная перепроверка каждого упавшего теста затягивала цикл поставки.
Фактически автоматизация не работала, создавая ложное чувство контроля качества. Наш SDET-лид пересобрал процесс:
-
актуализировал тест-кейсы;
-
стабилизировал инфраструктуру и выстроил командные процессы, таким образом, что: Pass Rate (процент успешных результатов) взлетел с 13% до 98–100%, время регресса сократилось вдвое.
Задача
Бизнес-задачи
-
Снизить риск пропуска критических дефектов в продукте кибербезопасности, где цена ошибки — уязвимость в защите клиентов и репутационный ущерб.
-
Вернуть рентабельность инвестициям в автоматизацию, которая на старте не приносила отдачи: 87% тестов падало и требовало ручной перепроверки.
-
Ускорить скорость поставки релизов, ликвидировав «бутылочное горлышко» — ручную перепроверку упавших автотестов.
Задача в контексте разработки
Превратить «мёртвый» набор автотестов (Pass Rate 13%) в стабильный и предсказуемый инструмент контроля качества.
Восстановить инженерную дисциплину:
-
устранить хаос в код-ревью (проверке кода);
-
выстроить прозрачный пайплайн поставки изменений.
Решение
Что планировали сделать
Два параллельных трека.
Инженерный:
-
аудит инфраструктуры;
-
стабилизация тестов и настройка CI/CD.
Процессный:
-
ребалансировка нагрузки в команде;
-
внедрение практик, позволяющих наращивать покрытие без потери качества.
Гипотезы
Ключевая причина низкого Pass Rate — не столько поломанная логика тестов, сколько их неактуальность и нестабильность окружения. Если сначала актуализировать тест-кейсы и стабилизировать инфраструктуру, а затем заняться рефакторингом — можно быстро поднять процент успешных прогонов и высвободить время команды на развитие.
Почему решали именно так.
Фронтальная атака «написать 200 новых тестов» была бы провальной — они бы падали в той же нестабильной среде. Поэтому первым шагом стал «ремонт фундамента», вторым — методичное наведение порядка в процессах и коде.
Этапы и числовые показатели
1. Аудит и стабилизация инфраструктуры (1–2 недели):
-
настройка автоматической сборки продукта в GitLab CI;
-
выявление и устранение корневых причин падений на уровне окружения (Docker, Virtual Machine).
2. Актуализация и рефакторинг тестов (3–4 недели):
-
разбор и переписывание неактуальных тест-кейсов;
-
приведение в соответствие с текущим функционалом.
-
Pass Rate начал расти с 13% до 60–70%.
3. Отладка процессов и выход на плато (1–2 месяца):
-
ребалансировка code review (выверки кода) — распределение между несколькими инженерами;
-
ликвидация «зависших» мерж-реквест (merge request — процесс слияние изменений из одной ветки кода в другую);
-
внедрение дежурств и поддержки нескольких версий продукта одновременно;
-
доведение скорости разработки до 1 UI E2E автотеста в день.
4. Финализация и передача:
-
стабилизация Pass Rate на уровне 98–100%;
-
достижение автоматизации 70% тест-кейсов (цель — 80%);
-
документирование процесса
Результат
-
Pass Rate автотестов вырос с 13% до 98–100% — ложные падения практически исключены.
-
Время регрессионного прогона сокращено с >12 часов до 5 часов 15 минут (экономия ~55% времени, или 7 часов на каждом прогоне).
-
Скорость разработки новых автотестов доведена до 1 UI E2E автотеста в день.
-
Автоматизировано 70% всех актуальных тест-кейсов (цель — 80%).
-
Полностью ликвидированы «зависшие» мерж-реквесты (запросы на слияние кода), время код-ревью сокращено за счёт равномерного распределения нагрузки между инженерами.
Бизнес-эффект
-
Продукт кибербезопасности получил надёжный автоматический барьер качества: риск выпуска версии с регрессионными дефектами критически снижен.
-
Ускорена скорость поставки: ручная перепроверка 87% упавших тестов исключена из релизного цикла.
Команда автоматизации перешла от режима «тушения пожаров» к плановой работе по наращиванию покрытия. -
Прямая экономия: 7 человеко-часов на каждом регрессионном прогоне. При регулярных запусках это десятки высвобожденных часов в месяц.
Трудности
Технический долг и демотивация команды
Стопор: многомесячный хаос в тестах привёл к «усталости» инженеров и неверию в возможность стабилизации.
Решение: быстрые победы (первые 20–30% роста Pass Rate за 2 недели) и прозрачная дорожная карта.
Сопротивление изменениям в код-ревью
Стопор: перераспределение зон ответственности требовало пересмотра устоявшихся привычек.
Решение: введение SLA (соглашение об уровне предоставления услуги) на ревью и ежедневные стендапы по заблокированным MR (запросы на слияние кода).
Технологии
Python, Pytest, Playwright, Docker, Virtual Machine, GitLab CI.
