Клиент — платформа онлайн-образования: интерактивные уроки, домашние задания, личные кабинеты учеников и родителей, онлайн-оплата. Специфика бизнеса — жёсткая сезонность: сентябрь собирает максимум новых учеников, и простой платформы в первые недели учебного года означает потерю клиентов навсегда. Внутренней QA-команды не было: тестированием занимались сами разработчики между задачами, регрессия перед релизом занимала три дня и всё равно пропускала критические сценарии — оплату, запись на урок, вход в класс. Клиент пришёл после очередного инцидента, когда из-за бага в оплате школа потеряла часть собранных за лето заявок.
Выстроить процесс обеспечения качества с нуля:
тест-стратегия с приоритетами по бизнес-рискам, автоматизация ключевых сценариев, интеграция проверок в CI и нагрузочное тестирование перед пиком сентября. Ограничение — работать без остановки разработки: релизы продолжались каждую неделю, а сентябрь ждать не мог.
Мы начали не с автотестов, а с риск-анализа: какие сценарии ломаются чаще всего и где цена бага максимальна. Автоматизация шла строго по этому списку.
- Провели аудит качества: разбор багов за последние полгода, интервью с командами, карта самых болезненных сценариев — оплата, запись на урок, вход в класс, уведомления родителям.
- Написали тест-стратегию: уровни тестирования, зоны ответственности, definition of done для фич, регламенты баг-репортинга — единые для трёх команд разработки.
- Автоматизировали критичный путь: e2e-сценарии на Playwright для веб-платформы, API-тесты для бэкенда, smoke-набор перед каждым релизом.
- Встроили QA-гейты в CI: релиз невозможен без зелёного smoke-набора, полная регрессия запускается nightly, результаты видны всем командам в GitLab.
- Провели нагрузочное тестирование на k6: смоделировали трафик сентябрьского пика, нашли узкие места и вместе с backend-командой устранили их до сезона.
- Передали процесс на сторону клиента: документация, регламенты, обучение QA-инженера работе с автотестами и конвейером.
Ключевое решение — приоритизация по бизнес-рискам, а не по «красоте покрытия». Мы сознательно не гнались за стопроцентной автоматизацией: 75% покрытия критичных сценариев дали основную часть эффекта, потому что защищали именно те пути, на которых платформа зарабатывает и теряет клиентов. Остальное закрывается ручной исследовательской проверкой перед значимыми релизами.
Главный экономический эффект — сдвиг обнаружения дефектов влево: баг, найденный автотестом в CI, стоит в десятки раз меньше бага, замеченного родителем ученика в продакшене. Платформа вошла в сезон с запасом прочности, а команды получили право выпускать изменения часто, не боясь «пятничного эффекта». Отдельный бонус — доверие бизнеса: отдел продаж теперь честно обещает школам-партнёрам стабильную платформу в пик записи.
| Показатель | Результат |
|---|---|
| Критические баги в проде | 5–7 в месяц → 1–2 в квартал |
| Регрессия перед релизом | 3 дня вручную → 4 часа автотестами |
| Сентябрьский пик нагрузки | Инциденты каждый год → 0 инцидентов, без деградации |
| Момент обнаружения дефекта | Чаще всего в проде → Автотесты ловят до релиза |
Показатели перенесены из исходных материалов кейса. Период указан там, где он зафиксирован в источнике.
- критических бага в квартал (было 5–7 в месяц)
- 1–2
- регрессия автотестами (было 3 дня вручную)
- 4 ч
- ключевых сценариев покрыто автотестами
- 75%
- инцидентов в сентябрьский пик
- 0
Шкала условная: 3 дня приняты за 72 часа. Для длины полос месячный диапазон багов переведён в квартальный умножением на три; сравниваются верхние границы.
- 01Коммит
- 02Smoke-наборбез зелёного релиза нет
- 03Релизеженедельно
- 04Nightlyполная регрессия
Что мы рекомендуем платформе как следующий шаг:
- Визуальное регрессионное тестирование — автоматическая проверка вёрстки уроков, писем и личных кабинетов.
- Фабрика тестовых данных — генерация реалистичных учеников, групп и платежей под каждый прогон.
- QA в проде — feature flags и канареечные релизы для постепенного включения новых функций.
Мы перестали бояться релизов. Раньше каждая пятница могла обернуться разбором жалоб, теперь выпуск в прод — рутинная процедура на пятнадцать минут.
— CTO онлайн-школы