Попросите три команды автоматизировать тесты — получите оценки, отличающиеся в десять раз. Не потому, что кто-то нечестен, а потому что под этим названием продаются четыре разные работы.

Четыре работы с одним названием

Дымовой набор. Пять-шесть путей: вход, главный сценарий, оплата. Дни, а не недели. Ловит катастрофы вроде «сайт не открывается у целого класса пользователей» и ничего тоньше.

Критичные пути. Двенадцать–двадцать сценариев вместе с тем, как они ломаются: отклонённая карта, протухшая сессия, уведомление, пришедшее дважды. Две-три недели. Именно этот размер меняет то, как команда выпускает релизы, потому что покрывает пути, по которым идут деньги.

Полная регрессия. Все экраны, все состояния, сотни тестов. Месяцы и постоянная стоимость поддержки. Оправдано там, где есть регуляторные обязательства или десять лет накопленного поведения. Разорительно для продукта, который ещё меняет форму.

Отдел QA. Люди, а не только код: исследовательское тестирование, управление релизами, план тестирования на каждую фичу. Совсем другая покупка и другие деньги.

Большинству нужен второй вариант. Большинство оценок пишут по третьему, а делают первый.

Почему дешёвая оценка часто самая дорогая

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

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

Что должно входить в поставку

Сравнивайте предложения не по количеству тестов, а по этим пунктам.

  • Список сценариев, согласованный до начала работ. Не «оформление заказа», а двенадцать названных путей, у каждого — какие отказы он включает.
  • Тесты, которые создают свои данные. Сьют, зависящий от базы, которую кто-то однажды наполнил, сломается при первом же восстановлении, и никто не поймёт почему.
  • Артефакты падения. Видео и трассировка на каждый красный тест. Без них каждое падение стоит разработчику часа на воспроизведение до начала починки.
  • Подключение к пайплайну. Папка со скриптами, которые кто-то должен не забыть запустить, — это не поставка.
  • Владение. Сьют в вашем репозитории, обычным кодом, без агента и подписки, которая перестаёт работать вместе со счетами.

Ориентир по деньгам

Для работающего продукта набор из двенадцати–пятнадцати критичных путей — это примерно две недели работы опытной пары. У нас это от 150 000 ₽ с фиксированным объёмом. Заметно ниже — что-то из списка выше тихо выпало. Заметно выше — вам продают регрессию или отдел QA; это может быть правильным решением, но должно быть решением, а не сюрпризом в счёте.

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

Нанять тестировщика или заказать сьют

В России этот вопрос стоит первым, и не случайно: тестирование здесь привыкли

закрывать наймом. Ответ зависит от того, разовая это работа или постоянная.

Наём оправдан, когда релизы идут несколько раз в неделю, рядом с

автоматическими нужны ручные проверки, а знание продукта должно накапливаться

годами. Штатный инженер видит то, чего не видит внешняя команда: странности,

о которых никто не написал в задаче.

Чего наём не делает — он не начинается в понедельник. Поиск опытного

инженера по автоматизации занимает от полутора до трёх месяцев, а первый набор

тестов всё равно кому-то писать с нуля. Человек, пришедший на пустой репозиторий,

первые месяцы будет делать ровно ту работу, которую можно купить готовой.

Обычный разумный порядок такой: сначала сьют на критичные пути, потом человек,

который приходит уже на код, показывающий, как здесь принято, и дальше растит

покрытие сам. В обратном порядке дороже: вы платите зарплату за то время, пока

инженер делает стартовую работу вместо развития.

Кто поддерживает тесты потом и сколько это стоит

Сьют — не картина, его нельзя повесить и забыть. Продукт меняется, и тесты

меняются вместе с ним; вопрос только в том, кто это делает.

Здоровая цифра — до десятой части времени команды на поддержку сьюта. Если

уходит больше, дело обычно не в тестах, а в том, как они написаны: привязка к

вёрстке вместо смысла, общие данные на все тесты, ожидания по таймеру вместо

ожидания события. Такой сьют переписывается быстрее, чем чинится.

Проверка, которую стоит устроить подрядчику через три месяца после сдачи:

есть ли в репозитории тесты, которые он не писал? Если ваша команда за

квартал не добавила ни одного — сьют построили не для вас, и через полгода его

выключат.

Когда автотесты вам ещё рано

Скажем прямо, теряя заказ. Автоматизация окупается на продукте, который уже

работает и уже меняется. Она не окупается, если:

  • продукт — прототип, и форма экранов меняется каждую неделю: тесты будут

переписываться быстрее, чем выполняться;

  • релиз бывает раз в квартал, и ручной проверки на день хватает;
  • никто на вашей стороне не станет владельцем сьюта после передачи;
  • нужен не сьют, а человек, который будет думать, что ещё может сломаться, —

это исследовательское тестирование, и оно другое.

Первые два случая честнее закрыть коротким дымовым набором

на два дня, чем полноценным пакетом. Мы так и предлагаем, когда видим их.

Чем мы сами это подтверждаем

Наш маркетплейс несёт 173 сквозных теста в 24 сьютах, приложение к нему гоняют 30 сценариев на живом устройстве, а операционная платформа держит 2053 проверки в трёх репозиториях. Эти числа посчитаны в репозиториях, а не оценены на глаз, и их можно проверить в разборах наших работ.

Если у вас уже есть тесты и есть ощущение, что толку от них нет, — расскажите, что происходит на релизе. Обычно за полчаса видно, лечится ли это точечно или дешевле написать пятнадцать тестов, которым будут верить.