У каждого проекта рано или поздно наступает момент, который я про себя называю «страхом пятницы». Нужно выпустить небольшое изменение: поправить расчёт скидки, добавить поле в форму, обновить библиотеку. Изменение крошечное, но никто не хочет нажимать кнопку. Потому что в прошлый раз такое же крошечное изменение сломало оформление заказа, и узнали об этом только в понедельник от разъярённых клиентов. Команда начинает выпускать обновления всё реже, каждое становится всё больше и страшнее, и проект медленно превращается в хрупкую вазу, к которой боятся прикасаться. Лекарство от этой болезни давно известно, и называется оно автоматизированное тестирование.
Почему ручное тестирование перестаёт работать
Пока система маленькая, её можно проверить руками. Открыл, кликнул, посмотрел, работает. Но каждый новый модуль, каждая новая функция добавляет сценарии, и их количество растёт не линейно, а гораздо быстрее, потому что функции начинают влиять друг на друга. В какой-то момент полная ручная проверка занимает дни, и её перестают делать полностью. Проверяют «то, что меняли». А ломается, как правило, то, что не меняли, но что было связано с изменённым невидимой ниточкой.
Есть и человеческая сторона. Тестировщик, который в сотый раз проверяет одну и ту же форму регистрации, на сто первый раз пропустит ошибку. Не потому, что он плохой специалист, а потому, что человеческий мозг не создан для монотонного повторения. Машина создана. Она проверит форму регистрации и в тысячный раз так же внимательно, как в первый, в три часа ночи, без кофе и без выходных.
Тесты как страховой полис
Мне нравится сравнивать автотесты со страховкой. Пока ничего не случилось, кажется, что это лишние расходы. Зачем платить за тесты, если система и так работает? Но страховку покупают не для того дня, когда всё хорошо. Автотесты окупаются в тот момент, когда разработчик вносит изменение, и через пять минут система сообщает ему: «Вот здесь ты сломал расчёт доставки для оптовых клиентов». Не через неделю от клиента, не через месяц в отчёте о потерянных продажах, а через пять минут, когда исправить это стоит копейки.
Хороший набор тестов превращает страх перед изменениями в рутину. А рутина, в отличие от страха, не тормозит развитие.
Именно поэтому команды с хорошим покрытием тестами выпускают обновления несколько раз в день, а команды без него раз в месяц, с совещанием и молитвой. Разница не в смелости, а в уверенности, которую дают тесты.
Уровни автоматизации
Автотесты бывают разные, и каждый уровень отвечает за своё. Я обычно объясняю это на примере автомобиля.
- Модульные тесты проверяют отдельные детали: правильно ли считается налог, корректно ли форматируется дата, верно ли работает функция скидки. Это как проверить каждую свечу зажигания на стенде. Таких тестов много, они быстрые и дешёвые.
- Интеграционные тесты проверяют, как детали работают вместе: модуль заказов правильно передаёт данные складу, склад правильно резервирует товар, оплата правильно меняет статус. Это проверка двигателя в сборе.
- Сквозные тесты имитируют действия реального пользователя в браузере: зашёл на сайт, нашёл товар, положил в корзину, оплатил, получил письмо. Это тест-драйв всей машины. Они медленные и капризные, поэтому их немного, но они ловят то, что не видно на уровне деталей.
Распространённая ошибка: начинать сразу со сквозных тестов, потому что они нагляднее. Через пару месяцев их становится сотни, они идут по часу и ломаются от любого изменения кнопки. Правильная пропорция похожа на пирамиду: широкое основание быстрых модульных тестов, средний слой интеграционных и узкая верхушка сквозных для самых важных сценариев.
Что тесты не заменят
Автотесты проверяют то, что Вы им сказали проверять. Они не скажут, что интерфейс неудобный, что текст на кнопке вводит в заблуждение, что новый сценарий вообще не нужен пользователям. Для этого по-прежнему нужен человек, который смотрит на систему глазами клиента. Хорошая стратегия качества сочетает машину для повторяющихся проверок и человека для исследовательского тестирования, где нужно думать, сомневаться и пробовать странное.
И ещё один момент: тесты это тоже код, и его тоже нужно поддерживать. Тесты, которые никто не обновляет, через полгода начинают падать без причины, команда привыкает их игнорировать, и страховка превращается в бумажку. Поэтому тесты должны быть частью процесса разработки, а не отдельным проектом, который сделали один раз.
С чего начать
Если в Вашем проекте нет автотестов, не пытайтесь покрыть всё сразу. Выпишите три-пять сценариев, поломка которых стоит дороже всего: оформление заказа, оплата, расчёт цены, вход в систему. Автоматизируйте проверку именно их. Подключите запуск тестов к каждому изменению кода, чтобы ни одно обновление не уходило на сервер без проверки. Это уже снимет большую часть страха пятницы.
В Systems тесты входят в наши проекты как обязательная часть, а не как опция «если останется бюджет». Когда система генерируется через Fractal по описанию, типовой код однороден, и проверять его гораздо проще, чем зоопарк ручных решений. А сегодня ИИ-агенты ещё и сильно удешевили написание тестов, так что отговорка «на тесты нет времени» звучит всё менее убедительно. Можно ли автоматизировать тестирование? Можно и нужно. Иначе автоматизируется только одно: страх.
