Новости

От теории к практике: Как выбор фреймворка для автоматизации определил успех тестирования социального проекта

2025-08-11 08:21
Всем привет!

Я Александр Соловьев и работаю в тестировщиком в компании SaveLink. Совсем недавно я защитил диплом в университете, и хочу поделиться с вами не просто результатами, а настоящим полевым опытом. В своей выпускной работе я исследовал автоматизацию тестирования на реальном проекте системы «Социализация», предназначенной для адаптации детей и подростков из интернатов. Этот проект не просто код, а часть чьей-то жизненной траектории, где ошибки в логике или интерфейсе могут иметь реальное влияние на судьбы пользователей. А значит качество тут критически важно.
Архитектура и вызовы

Система «Социализация» включала пять ключевых модулей:

  • Авторизация
  • Управление профилями
  • Работа с организациями
  • Образовательный контент
  • Взаимодействие пользователей

Тестирование осложнялось несколькими факторами. Во-первых, проект находился в активной разработке, что создавало высокий риск регрессионных ошибок. Во-вторых, пользователи платформы это социально уязвимая аудитория, где промахи в интерфейсе или бизнес-логике недопустимы.

Три подхода на практике

Я сравнивал три метода:

  1. Ручное тестирование в TestIT
  2. Автоматизацию через BugBuster (ИИ-инструмент для генерации тестов из шагов на русском языке)
  3. Наш кастомный BDD-фреймворк (Playwright + Behave)

Для чистоты эксперимента я использовал одни и те же 175 тест-кейсов (без учета параметризации), которые сначала подготовил в TestIT. Это заняло примерно 22 часа, так как нужно было детально прописать шаги, предусловия и ожидаемые результаты. Затем разработанные тест-кейсы предстояло автоматизировать двумя разными подходами.

BugBuster: между волшебством и хаосом

Когда я перешел к автоматизации в BugBuster, столкнулся с парадоксом. С одной стороны, инструмент впечатлял простотой: я буквально копировал шаги из TestIT на русском языке ("Ввести логин", "Нажать кнопку Войти"), и система сама генерировала тесты без использования каких-либо локаторов. Инструмент хорошо анализировал контент на странице, например, ожидаемый результат "Вижу форму авторизации" выдавал детальную аналитику от лица обычного пользователя, благодаря VLM технологиям. За 18 часов удалось автоматизировать 60% сценариев. На этом плюсы закончились.

Проблемы BugBuster:

  1. Тесты работали непредсказуемо. Например, при проверке валидации email инструмент мог ввести данные не в те поля, но тест все равно проходил (ложное срабатывание)
  2. На мелкие визуальные элементы (подчеркивание ошибок) система реагировала с ошибкой 30% случаев
  3. Самое критичное — отсутствие инструментов для управления данными. Мне пришлось вручную прописывать постусловия для удаления тестовых пользователей, что нарушало изоляцию тестов
  4. Долгое время выполнения для простейшего теста в среднем составляло около 3 минут. Это затягивало отладку, а также не позволило внедрить автотесты в CI/CD процессы команды.

BDD-фреймворк: предсказуемость и контроль

Переходя к BDD-подходу, я использовал те же тест-кейсы из TestIT, но процесс кардинально отличался. Вот ключевые этапы:

  1. Преобразование кейсов в Gherkin-сценарии. Я перевел шаги в формат "Given/When/Then": Это заняло время, но дало неожиданный бонус — аналитики позже использовали эти сценарии как документацию.
  2. Магия API-предусловий. Здесь скрывалось главное преимущество. Вместо ручных подготовок данных я добавлял данные на бэке с использованием предусловий. Это позволило сократить время выполнения тестов и решить проблему "грязных данных".
  3. Интеграция с Playwright. Для UI-шагов использовались CSS-селекторы. Хотелось добавить data-test атрибуты в фронтенд (как мы делаем в наших проектах), но у студентов не было на это времени. Несмотря на это, стабильность тестов была несопоставимо выше, чем у BugBuster и стремилась к 100%.

Сравнительная аналитика

Тут цифры, которые говорят сами за себя. После 52 тестовых прогонов (имитация годовой разработки с еженедельными релизами) результаты ошеломили:

BugBuster:
  • 18 часов на автоматизацию ручных тестов (без учета поддержки)
  • 5.5 часов на прогон
  • 13 ложных срабатываний
  • Годовые затраты: 151 351 ₽ (с учетом лицензии)
Наш фреймворк:
  • 22 часа на автоматизацию ручных тестов (без учета поддержки)
  • 16 минут на прогон
  • 1 ложное срабатывание (из-за скриншот-теста)
  • Годовые затраты: 34 128 ₽

Экономия в 120 000 ₽ — не просто цифра. Для социального проекта с ограниченным бюджетом это возможность направить средства на развитие функционала.

Что я вынес для себя и наших проектов в SaveLink

  1. API > UI для подготовки данных. Те предусловия, которые я добавил, сократили время тестов на 67%. В наших проектах мы развиваем эту практику, создавая библиотеку готовых предусловий.
  2. Скорость прогона против скорости разработки. BugBuster позволял быстро создать первые тесты, но их поддержка превратилась в кошмар. Наш подход требует чуть больше времени и технических знаний на старте, но экономит сотни часов в долгосрочной перспективе.
  3. Скрытые преимущества BDD. Когда я показывал Gherkin-сценарии остальным стейкхолдерам "Социализации", они без проблем поняли логику тестов без погружения в код. Это неожиданно ускорило исправление багов.

Заключение

Этот опыт подтвердил, что фреймворк, разработанный нашей командой тестирования это не дань моде, а стратегическое решение. Для проектов вроде «Социализации», где каждая ошибка может повлиять на реальных людей, нужна предсказуемость, а не «магия ИИ».
P.S. Для дальнейшего развития проекта я оставил инструкцию по улучшению фреймворка: добавить параллельные прогоны и отказаться от скриншот-проверок.