Всем привет!
Я Александр Соловьев и работаю в тестировщиком в компании SaveLink. Совсем недавно я защитил диплом в университете, и хочу поделиться с вами не просто результатами, а настоящим полевым опытом. В своей выпускной работе я исследовал автоматизацию тестирования на реальном проекте системы «Социализация», предназначенной для адаптации детей и подростков из интернатов. Этот проект не просто код, а часть чьей-то жизненной траектории, где ошибки в логике или интерфейсе могут иметь реальное влияние на судьбы пользователей. А значит качество тут критически важно.
Я Александр Соловьев и работаю в тестировщиком в компании SaveLink. Совсем недавно я защитил диплом в университете, и хочу поделиться с вами не просто результатами, а настоящим полевым опытом. В своей выпускной работе я исследовал автоматизацию тестирования на реальном проекте системы «Социализация», предназначенной для адаптации детей и подростков из интернатов. Этот проект не просто код, а часть чьей-то жизненной траектории, где ошибки в логике или интерфейсе могут иметь реальное влияние на судьбы пользователей. А значит качество тут критически важно.
Архитектура и вызовы
Система «Социализация» включала пять ключевых модулей:
Тестирование осложнялось несколькими факторами. Во-первых, проект находился в активной разработке, что создавало высокий риск регрессионных ошибок. Во-вторых, пользователи платформы это социально уязвимая аудитория, где промахи в интерфейсе или бизнес-логике недопустимы.
Три подхода на практике
Я сравнивал три метода:
Для чистоты эксперимента я использовал одни и те же 175 тест-кейсов (без учета параметризации), которые сначала подготовил в TestIT. Это заняло примерно 22 часа, так как нужно было детально прописать шаги, предусловия и ожидаемые результаты. Затем разработанные тест-кейсы предстояло автоматизировать двумя разными подходами.
BugBuster: между волшебством и хаосом
Когда я перешел к автоматизации в BugBuster, столкнулся с парадоксом. С одной стороны, инструмент впечатлял простотой: я буквально копировал шаги из TestIT на русском языке ("Ввести логин", "Нажать кнопку Войти"), и система сама генерировала тесты без использования каких-либо локаторов. Инструмент хорошо анализировал контент на странице, например, ожидаемый результат "Вижу форму авторизации" выдавал детальную аналитику от лица обычного пользователя, благодаря VLM технологиям. За 18 часов удалось автоматизировать 60% сценариев. На этом плюсы закончились.
Проблемы BugBuster:
BDD-фреймворк: предсказуемость и контроль
Переходя к BDD-подходу, я использовал те же тест-кейсы из TestIT, но процесс кардинально отличался. Вот ключевые этапы:
Сравнительная аналитика
Тут цифры, которые говорят сами за себя. После 52 тестовых прогонов (имитация годовой разработки с еженедельными релизами) результаты ошеломили:
BugBuster:
Экономия в 120 000 ₽ — не просто цифра. Для социального проекта с ограниченным бюджетом это возможность направить средства на развитие функционала.
Что я вынес для себя и наших проектов в SaveLink
Заключение
Этот опыт подтвердил, что фреймворк, разработанный нашей командой тестирования это не дань моде, а стратегическое решение. Для проектов вроде «Социализации», где каждая ошибка может повлиять на реальных людей, нужна предсказуемость, а не «магия ИИ».
Система «Социализация» включала пять ключевых модулей:
- Авторизация
- Управление профилями
- Работа с организациями
- Образовательный контент
- Взаимодействие пользователей
Тестирование осложнялось несколькими факторами. Во-первых, проект находился в активной разработке, что создавало высокий риск регрессионных ошибок. Во-вторых, пользователи платформы это социально уязвимая аудитория, где промахи в интерфейсе или бизнес-логике недопустимы.
Три подхода на практике
Я сравнивал три метода:
- Ручное тестирование в TestIT
- Автоматизацию через BugBuster (ИИ-инструмент для генерации тестов из шагов на русском языке)
- Наш кастомный BDD-фреймворк (Playwright + Behave)
Для чистоты эксперимента я использовал одни и те же 175 тест-кейсов (без учета параметризации), которые сначала подготовил в TestIT. Это заняло примерно 22 часа, так как нужно было детально прописать шаги, предусловия и ожидаемые результаты. Затем разработанные тест-кейсы предстояло автоматизировать двумя разными подходами.
BugBuster: между волшебством и хаосом
Когда я перешел к автоматизации в BugBuster, столкнулся с парадоксом. С одной стороны, инструмент впечатлял простотой: я буквально копировал шаги из TestIT на русском языке ("Ввести логин", "Нажать кнопку Войти"), и система сама генерировала тесты без использования каких-либо локаторов. Инструмент хорошо анализировал контент на странице, например, ожидаемый результат "Вижу форму авторизации" выдавал детальную аналитику от лица обычного пользователя, благодаря VLM технологиям. За 18 часов удалось автоматизировать 60% сценариев. На этом плюсы закончились.
Проблемы BugBuster:
- Тесты работали непредсказуемо. Например, при проверке валидации email инструмент мог ввести данные не в те поля, но тест все равно проходил (ложное срабатывание)
- На мелкие визуальные элементы (подчеркивание ошибок) система реагировала с ошибкой 30% случаев
- Самое критичное — отсутствие инструментов для управления данными. Мне пришлось вручную прописывать постусловия для удаления тестовых пользователей, что нарушало изоляцию тестов
- Долгое время выполнения для простейшего теста в среднем составляло около 3 минут. Это затягивало отладку, а также не позволило внедрить автотесты в CI/CD процессы команды.
BDD-фреймворк: предсказуемость и контроль
Переходя к BDD-подходу, я использовал те же тест-кейсы из TestIT, но процесс кардинально отличался. Вот ключевые этапы:
- Преобразование кейсов в Gherkin-сценарии. Я перевел шаги в формат "Given/When/Then": Это заняло время, но дало неожиданный бонус — аналитики позже использовали эти сценарии как документацию.
- Магия API-предусловий. Здесь скрывалось главное преимущество. Вместо ручных подготовок данных я добавлял данные на бэке с использованием предусловий. Это позволило сократить время выполнения тестов и решить проблему "грязных данных".
- Интеграция с Playwright. Для UI-шагов использовались CSS-селекторы. Хотелось добавить data-test атрибуты в фронтенд (как мы делаем в наших проектах), но у студентов не было на это времени. Несмотря на это, стабильность тестов была несопоставимо выше, чем у BugBuster и стремилась к 100%.
Сравнительная аналитика
Тут цифры, которые говорят сами за себя. После 52 тестовых прогонов (имитация годовой разработки с еженедельными релизами) результаты ошеломили:
BugBuster:
- 18 часов на автоматизацию ручных тестов (без учета поддержки)
- 5.5 часов на прогон
- 13 ложных срабатываний
- Годовые затраты: 151 351 ₽ (с учетом лицензии)
- 22 часа на автоматизацию ручных тестов (без учета поддержки)
- 16 минут на прогон
- 1 ложное срабатывание (из-за скриншот-теста)
- Годовые затраты: 34 128 ₽
Экономия в 120 000 ₽ — не просто цифра. Для социального проекта с ограниченным бюджетом это возможность направить средства на развитие функционала.
Что я вынес для себя и наших проектов в SaveLink
- API > UI для подготовки данных. Те предусловия, которые я добавил, сократили время тестов на 67%. В наших проектах мы развиваем эту практику, создавая библиотеку готовых предусловий.
- Скорость прогона против скорости разработки. BugBuster позволял быстро создать первые тесты, но их поддержка превратилась в кошмар. Наш подход требует чуть больше времени и технических знаний на старте, но экономит сотни часов в долгосрочной перспективе.
- Скрытые преимущества BDD. Когда я показывал Gherkin-сценарии остальным стейкхолдерам "Социализации", они без проблем поняли логику тестов без погружения в код. Это неожиданно ускорило исправление багов.
Заключение
Этот опыт подтвердил, что фреймворк, разработанный нашей командой тестирования это не дань моде, а стратегическое решение. Для проектов вроде «Социализации», где каждая ошибка может повлиять на реальных людей, нужна предсказуемость, а не «магия ИИ».
P.S. Для дальнейшего развития проекта я оставил инструкцию по улучшению фреймворка: добавить параллельные прогоны и отказаться от скриншот-проверок.