Когда автотесты не нужны — и чем их заменить

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

Константин Боковиков

Chapter QA Lead онлайн-кинотеатра KION

Почему все так любят автотесты?

Обучающие площадки пишут, что тестирование и в частности автотесты — самый простой путь «войти в айти», работать на удалёнке, зарабатывать много денег. При этом ты их один раз напишешь, и они станут делать за тебя всю работу.

На самом деле всё не так. Автотесты надо поддерживать на протяжении всего жизненного цикла, время от времени проводить аудит: это не такая уж простая работа. Кроме того, нужно понимать, когда они действительно эффективны, а когда — только навредят.

Автотесты нужны, когда есть сформированная команда QA: ручные тестировщики уже разобрали все требования, написали тест-кейсы и по ним регулярно проводят проверки. То есть цикл работ повторяется, объём ручных тест-сценариев разросся, и тестирование начинает превращаться в рутину.

В каких случаях эти условия не соблюдаются?

• продукт быстро меняется: необходимо адаптироваться к обновлениям, проводить исследовательское тестирование, анализировать требования и писать на это всё сценарии;
• продукт временный: например, он вышел на три месяца в прод, выполнил свою функцию и его убрали;
• нет большого объёма задач: релизы проходят раз в несколько месяцев, сценарии описаны, и гораздо выгоднее проверять всё руками.

Когда автотесты не нужны: рассматриваем кейсы

Главная задача автотестов — уменьшить time to market и сэкономить ресурсы команды. Разбираем сценарии, при которых это не происходит.

Пример 1. Много работы и мало времени

Возьмём какой-нибудь легаси-монолит, где работает небольшое количество тестировщиков. Есть техдолг по тестам, близится релиз, сроки поджимают, бюджет ограничен.

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

У кого-то здесь может возникнуть желание всё автоматизировать. Но ручные тестировщики всегда в несколько раз дешевле автоматизаторов и универсалов. Поэтому проще взять их на аутсорсе, чтобы те пробежали и вычистили продукт к релизу.

Пример 2. UI-тестирование

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

Допустим, появился новый раздел со схожими названиями элементов: например, строки таблицы `row`, а в новом разделе также есть таблица, и каждый элемент таблицы обретает префикс, указывающий на его логическую связь, — `content-row`, `offer-row`, `media-row`. Если команда предусмотрела такой кейс на этапе груминга, то тестировщики заранее переименовали элементы привязки либо использовали regexp для «упрочнения» тестов. Но чаще встречается ситуация, когда фичу погрумили и разработчик принимает такое решение самостоятельно, тем самым ломая автотесты. Тестировщик узнает об этом, когда тесты упадут при очередном прогоне — хорошо, если падение обнаружится утром и будет время всё исправить; гораздо хуже, когда ломается регрессионный набор, проверяющий релиз.

Поэтому проще описать сценарии и быстро пробежаться по ним руками.

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

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

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

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

Например, те же аппараты по поддержанию жизни. Да, можно на каком-нибудь изолированном стенде попробовать всё автоматизировать, но когда в аппарат заливается прошивка, без ручного тестировщика в лаборатории никак не обойтись.

Был случай при разработке финтех-продукта, когда технический пользователь, созданный для тестирования, при запуске миграции для перехода на ночную смену «увидел» изменения в базе и запустил прогон тестов на «боевой» базе, создав высокую интенсивность открытия долгосрочных вкладов. В итоге ставка по вкладам снизилась: для алгоритмов приложения всё выглядело так, что слишком много людей вложили деньги. И это нанесло реальный вред бизнесу. Когда «пепел» улёгся, админский доступ в БД забрали у 90% техперсонала. Для тестирования создали обезличенную и маштабированную копии «боевой» базы, добавили окружение pre production.

Это как раз случай, когда автоматизация становится не просто неудобной или дорогой, а несёт риски.

Пример 4. Развивающийся продукт

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

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

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

Пример 5. Редкие сценарии пользовательского поведения

Этот вид тестирования иногда называют monkey testing — когда мы тыкаем во всё подряд и пытаемся создать абстрактную модель поведения пользователя. Вероятно, менее 1% людей будут себя в продукте так вести, но при этом иногда вскрываются какие-то критические сценарии, которые могут систему пошатнуть.

Такой тест актуален для любых сайтов и приложений, где можно вводить данные. Поля для ввода данных уязвимы для атак типа SQL-Injection. Кроме того, многие системы не предусматривают сценариев на случай ввода в поле отрицательных, дробных, непрописных символов — в итоге сервис, обеспечивающий обработку бизнес-логики, может запросто зависнуть.

В 2015 году я занимался тестированием крупной интернет-площадки. В обычную строку для поиска типовой заглавной страницы был помещён текст `DROP Table USERS`— и в результате все существующие пользователи были удалены. Строка поиска товара формировала запрос напрямую в базу и не была экранирована. После этой ситуации пользователей восстановили, разослали письма с извинениями, а в структуру добавили слой, проверяющий запрос на адекватность перед передачей в базу данных.

Автоматизировать monkey testing возможно, но для этого нужен немалый труд: по факту, придётся написать ещё одно приложение, которое будет генерировать абсурдные сценарии. Проще и удобнее всё заменить одним человеком, который знает и понимает практики тест-дизайна.

Почему автотесты не станут панацеей

Автотесты полезны и удобны на определённых участках работы, но не универсальны. Это как с пресловутым ChatGPT, который сам создаёт код, который в итоге надо приводить к нормальному состоянию — что по трудозатратам равно написанию с нуля.

Когда погружаешься в автотестирование, понимаешь, что нет-нет, а надо, чтобы твою спину прикрыл ручной тестировщик. Как бы ни хотелось, чтобы процент тестов выглядел 70 автоматизированных на 30 ручных, золотая середина — 50 на 50 либо 60 на 40.

При этом у ручных тестировщиков, которые практически первыми встречаются с требованиями бизнеса, как правило, формируется более широкий взгляд на систему. Они тестируют свой участок, но могут помочь соседней команде с интеграцией.

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

Повторим: когда автотесты не нужны

• сроки и бюджет проекта ограничены: проверить руками получается дешевле экономически;
• речь идёт о развивающемся продукте с большим количеством изменений;
• тестируются продукты, где действия пользователя в системе могут принести значимый негативный эффект (здоровье, финансы, безопасность и так далее);
• тестируется фронтенд, элементы в котором могут динамически меняться;
• проверяются редкие пользовательские сценарии;
• команда не сформирована — мало тестировщиков, много разработчиков;
• автотесты не ревьювятся (код сомнительного качества), как результат — околонулевая эффективность;
• недостаточная погружённость в продукт, например, когда на проекте новый тестировщик;
• не выстроен процесс тестирования — нет понимания, что делать с автотестами дальше;
• отсутствует инфраструктура — не настроен CI/CD, автотесты запускаются руками;
• очень долгий прогон тестов с низкой результативностью (наследие предыдущего тестировщика);
• нет автоматической обработки результатов, из-за чего результаты тестов неинформативны;
• сервис или приложение написаны на редком языке, например, Cobol;
• продукт — десктопное приложение, здесь на первых порах проще делать тесты руками.