Автоматизация тестирования и разработка автотестов

• UI-автотесты веб-приложений.
  Пользовательские сценарии в браузере: авторизация, формы, оплаты, личный кабинет. Playwright или Selenium — выбираем под ваш стек, а не под свою привычку.
• API-автотесты.
  Самый выгодный уровень: быстрые, стабильные, дешёвые в поддержке. Проверяем контракты, коды ответов, авторизацию и граничные данные. Если API ещё предстоит собрать — этим занимается та же команда.
• Автотесты мобильных приложений.
  iOS и Android на реальных устройствах и эмуляторах через Appium. Часто в связке с нашей мобильной разработкой.
• Интеграционные и сквозные сценарии.
  Проверка цепочек через несколько систем: заказ дошёл до учётной системы, платёж отразился, статус вернулся в кабинет.
• Регресс в CI/CD.
  Прогон набора на каждый коммит или по расписанию, отчёт в Allure, уведомление команде. Настройку самого пайплайна при необходимости берут на себя DevOps-инженеры.

Проверку системы под пиковой нагрузкой выносим отдельно — это нагрузочное тестирование. Ручное функциональное QA и аудит качества — тестирование ПО.

Правильный ответ почти всегда «и то, и другое»: автотесты держат регресс, человек проверяет новое. Ручное QA у нас — отдельная услуга тестирование ПО, команда общая.

Порог в 40 000 ₽ ниже привычного для ниши, и это осознанная модель входа, а не урезанное качество: пилот рассчитан на один критичный путь продукта — 10 UI-сценариев или 25 API-проверок, — чтобы вы увидели работающий набор в своём CI до входа в большой бюджет. Полный регресс крупной системы стоит других денег, и мы называем их после пилота, когда объём известен, а не на глаз.

На цену влияют: число сценариев, наличие тестового окружения и данных, стабильность интерфейсов и готовность CI/CD.

Как считать окупаемость автотестов

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

1. Сколько сейчас стоит один полный регресс. Человеко-часы всех, кто в нём участвует, умноженные на стоимость часа. Считайте не только тестировщиков: сюда же уходят разработчики, которых дёргают на воспроизведение, и время релиз-менеджера.
2. Сколько раз в год этот регресс прогоняется. Плановые релизы плюс хотфиксы и повторные прогоны после правок — второй множитель обычно выше, чем кажется на старте.
3. Годовая стоимость ручного регресса — произведение первых двух пунктов. Это то, что вы платите сегодня, просто не отдельной строкой в бюджете.
4. Что из этого закрывают автотесты. Автоматизируется повторяемая часть, а не весь объём: исследовательское и приёмочное тестирование остаются за человеком. Реалистичная доля определяется на разборе продукта, а не берётся коэффициентом из статьи.
5. Что стоит автоматизация — разовая разработка набора плюс его поддержка на горизонте года. Поддержку в расчёт включать обязательно: набор без сопровождения перестаёт отражать продукт за несколько месяцев.

Разделите стоимость набора с поддержкой на годовую экономию — получите срок окупаемости в своём релизном цикле. Считается это честно только по вашим данным: при двух релизах в год автотесты могут не окупиться никогда, при еженедельных — окупятся быстро. Поэтому мы и начинаем с пилота: после него оба множителя перестают быть оценкой. Если расчёт покажет, что автоматизация вам невыгодна, — скажем об этом прямо.

Почему у нас дешевле рынка. Написание кода тестов — page objects, сами сценарии, тест-данные, отчёты и документация — мы делаем с ИИ примерно вчетверо быстрее, и эта экономия уходит в цену. Работы, где ИИ не помогает — стратегия автоматизации и выбор что покрывать, настройка CI/CD, разбор нестабильных тестов на живой инфраструктуре, девайс-ферма и приёмка, — считаются по обычной ставке. Поэтому у пилота скидка заметная, а у поддержки набора её почти нет.

1. Разбор продукта и стратегия — 3–5 дней.
   Что за продукт, какой регресс болит, что уже есть из тестов и окружений. Результат — список сценариев по приоритету и смета.
2. Каркас фреймворка.
   Структура проекта, page objects, тест-данные, конфигурации окружений — фундамент, от которого зависит цена каждого следующего теста.
3. Пилотный набор.
   Автотесты на критичные сценарии, первый прогон в вашем CI, отчётность. Здесь видно реальную скорость и стабильность.
4. Расширение покрытия.
   Наращиваем набор по приоритетам, чиним нестабильные тесты, доводим прогон до зелёного и предсказуемого.
5. Передача и развитие.
   Документация набора, обучение вашей команды, дальше — развитие по часам или сопровождение.