Представьте команду, которая выпускает обновление каждую неделю. В понедельник добавили промокоды, в среду поправили доставку, в пятницу собрали новую версию. И каждый раз перед выпуском кто-то должен заново пройти то, что работало вчера: положить товар в корзину, оплатить, убедиться, что заказ появился в списке. К третьей неделе это перестаёт быть работой и становится ритуалом — те же экраны, те же нажатия, тот же ожидаемый результат.
Ровно здесь и возникает вопрос: пусть это делает машина. Когда сценарий проходит человек — это ручное тестирование. Когда тот же сценарий описан программой, которая проходит его сама, — это автоматизированное тестирование. Разница между ними не в скорости, а в том, что каждый из двоих способен заметить. Дальше — из чего состоит автотест, почему он краснеет на исправном приложении и что на самом деле доказывает зелёный прогон. Пример на всю статью один: оформление заказа в интернет-магазине.
Автотест повторяет ровно то, что в него записали, — быстро и сколько угодно раз. Человек видит то, чего в списке нет; а если элемент переехал, красным становится исправное приложение.
Что на самом деле делает человек, когда проверяет руками
Со стороны ручное тестирование выглядит как прокликивание экранов по списку. Если бы это было так, машина заменила бы человека ещё лет двадцать назад. На деле тестировщик делает три вещи сразу: придумывает проверку, выполняет её и решает, баг это или так и задумано.
Самое ценное — третье. Человек кладёт товар в корзину, меняет количество на ноль, возвращается назад кнопкой браузера, обновляет страницу прямо на шаге оплаты — половины этих шагов нет ни в одном списке, они рождаются по ходу, потому что предыдущий экран повёл себя подозрительно. И «это баг» он говорит про вещи, о которых никто заранее не договаривался: итог посчитан верно, но подпись съехала на соседнюю строку; сообщение об ошибке формально правильное, только покупатель по нему не поймёт, что делать.
Предел у этого способа арифметический. Набор из шестидесяти проверок на оформление заказа — это примерно рабочий день на один полный проход: каждый сценарий надо подготовить (нужный товар, нужный пользователь, нужный остаток на складе), пройти и записать результат. А сборок за неделю три-четыре. Дело даже не в том, что долго: к концу такого дня внимание падает, и пропускают обычно не редкий сценарий, а самый привычный — тот, который проходили сорок раз и заранее знают, что там всё хорошо.
Из чего состоит автотест
Слово «автотест» звучит загадочно, пока не увидишь, что внутри. А внутри — короткая программа из трёх частей.
Первая — шаги: открыть страницу товара, нажать «В корзину», перейти к оплате, нажать «Оплатить». Вторая — ожидаемый результат, записанный заранее и очень конкретно: в корзине один товар, итог равен 1000, статус заказа после оплаты — paid. Третья — сравнение: программа выполняет шаги, берёт фактическое значение и сверяет с записанным. Сошлось — «прошло», не сошлось — «упало», и в отчёте появляется строка «ожидали 1000, получили 1200».
Дальше важно, где эта программа живёт. Автотест лежит в репозитории рядом с кодом приложения, и запускает его не тестировщик со своего ноутбука, а сервер сборки: на каждое изменение кода и отдельно ночью, на всём наборе. Утром команда приходит к готовому отчёту — «812 проверок прошли, 4 упали». Вот откуда берётся «можно гонять сколько угодно раз»: человека в этом цикле нет, он подключается только к разбору упавших.
И ещё одно, что меняет картину. Автотест — не обязательно робот, который водит мышкой по экрану. Через интерфейс проверяется меньшая часть: большинство автопроверок обращается прямо к серверу запросами (проверки API) или проверяет отдельные функции внутри кода. Такие проверки идут секунды вместо минут и почти не ломаются — у них нет ни кнопок, ни вёрстки, чтобы сломаться. Почему проверок без экрана обычно больше — в статье про уровни тестирования.
Почему тест краснеет, когда приложение исправно
Автотест не видит страницу так, как видит её человек. Чтобы нажать кнопку, он должен её найти — по примете: по надписи «Оплатить», по имени элемента в вёрстке, по месту в структуре страницы. Такая примета называется локатором.
Дальше происходит обычное: дизайнер переименовал кнопку в «К оплате». Для покупателя не изменилось ничего, оплата работает. А автотест ищет «Оплатить», не находит и падает. Прогон красный — приложение исправно. То же даёт переезд кнопки в соседний блок.
Вторая причина красного — данные: тестовый пользователь заблокирован, товар из сценария кончился на складе, заказ от вчерашнего прогона мешает создать новый. Третья — время: приложение отвечает не мгновенно, и сегодня сервер ответил за полсекунды, а завтра за три — тест не дождался и пошёл дальше по несуществующему ещё экрану. Такой тест падает через раз без всякой связи с кодом; его называют плавающим (flaky), и он хуже отсутствующего: команда привыкает, что «этот всегда красный», и перестаёт читать отчёт целиком.
Отсюда главное про деньги. Автотест пишут один раз, а чинят постоянно — просто потому, что продукт меняется. Поэтому проверка, которую сделают один раз, не окупится никогда, а та, которую повторят двести раз, окупится быстро. Подробная арифметика — в статье как устроена автоматизация.
Что означает зелёный прогон
Зелёный прогон говорит ровно одно: всё, что записали в ожидания, сошлось. Не «приложение работает» и не «можно выпускать».
Вернёмся к заказу. Цена отрисовалась как «1000₽» вместо «1 000 ₽», а рекламный баннер наехал на нижнюю половину кнопки оплаты — на телефоне в неё теперь не попасть пальцем. Автотест нашёл кнопку по локатору, нажал её напрямую, получил статус paid и честно отчитался «прошло»: ни разделителя разрядов, ни баннера в списке ожиданий не было, значит, для него их не существует.
Бывает и хуже. В тесте записано: кнопка «Оплатить» есть на странице. Она есть, тест зелёный — а по нажатию ничего не происходит: проверяли наличие кнопки, а важен был результат нажатия. Зелёный прогон, который ничего не доказывает, потому что проверили не то свойство, называют ложным зелёным.
Поэтому на проекте с автотестами у тестировщика есть ежедневная работа — разобрать красное. У упавшего теста четыре объяснения: в приложении баг; тест устарел; протухли данные; тест плавающий. До разбора красный не значит ничего, и заводить по нему баг рано. А то, чего в списке ожиданий нет по определению, ищет человек — исследовательским тестированием (exploratory), когда проверки придумываются на ходу, по тому, что только что увидел на экране.
Что чем проверяют: рабочее правило
Из двух предыдущих разделов правило выводится само: автоматизируем то, что повторится много раз и меняется редко; руками проверяем новое, редкое и «на глаз».
Первая половина — это прежде всего регресс: прогнать заново то, что уже работало, чтобы убедиться, что новое ничего не сломало. Сценарии регресса неделями одни и те же, а гонять их надо на каждой сборке — работа ровно для машины. Туда же расчёты скидок и доставки, перебор десятков вариантов данных, проверки без интерфейса.
Вторая половина остаётся человеку: только что сделанная функция, которую ещё трижды переделают (автотест пришлось бы переписывать вместе с ней), внешний вид и удобство, редкие сценарии, где написать проверку дороже, чем один раз пройти руками.
Почему в профессию входят через ручное
Автоматизация — это программирование, и соблазн начать сразу с неё понятен. Мешает то, что код теста — вторая задача, а первая — знать, что проверять: какие у продукта сценарии, где обычно прячутся баги, что важно, а что нет. Это даёт ручная работа с продуктом.
Вторая причина осязаемее. Без знания продукта автотесты пишут на то, что и так не ломается: открылась ли главная, есть ли на ней логотип. Проверок становится больше, отчёт длиннее, а баги продолжают уезжать к покупателям — просто в тех местах, куда никто не посмотрел.
Кто в итоге пишет автотесты, зависит от команды: где-то отдельный человек, занятый только ими; где-то сами разработчики рядом со своим кодом; где-то тестировщик, начавший с ручной работы. Поэтому «начинайте с ручного» — не запрет, а маршрут; про сам переход — в статье куда расти дальше.
Здесь же честно про миф «ручное умирает». Доля однообразного прокликивания действительно сокращается — её и должна была забрать машина. А решений становится больше: что проверять, какой ожидаемый результат записать, что означает сегодняшний красный прогон. Это смена содержания работы, а не исчезновение профессии: автотест проверяет только заранее записанное, и записывает его человек.
Где это применяется
На проекте оба подхода работают одновременно и в разное время суток. Ночью сервер сборки прогоняет регресс; утром тестировщик разбирает упавшее и отделяет баги от устаревших тестов; днём руками проверяет сделанное вчера и ходит по продукту без плана. Понимание, что чем проверять, экономит больше всего сил: не гонять руками то, что давно стоило отдать машине, и не автоматизировать одноразовое.
Где спотыкаются начинающие:
- Читают зелёный прогон как «всё работает». Зелёный означает только, что сошлись записанные ожидания; всё остальное не проверено вообще.
- Заводят баг по красному тесту, не разобравшись. Сначала смотрим, не устарел ли сам тест и не протухли ли данные, — иначе задача вернётся, а доверие к отчётам упадёт.
- Думают, что автоматизация заменит ручное. Заменяется повторяющаяся часть, а не работа целиком.
- Рвутся автоматизировать, не научившись тестировать. Получаются проверки на то, что и так не ломается.
- Проходят руками то, что стоило автоматизировать — один и тот же длинный регресс на каждой сборке. Это выматывает и приводит к пропускам в привычных местах.
Коротко
- Автотест — это записанные заранее ожидания плюс сравнение факта с ними; чего не записали, того он не проверяет.
- Живёт он в репозитории, а запускает его сервер сборки — на каждое изменение и ночью, без участия человека.
- Большая часть автопроверок идёт без интерфейса, запросами к серверу, — потому они быстрые и редко ломаются.
- Красный прогон не равен багу: тест мог устареть, данные протухнуть, а сам тест оказаться плавающим.
- Зелёный прогон не равен «работает»: съехавшую вёрстку и нечитаемое сообщение об ошибке видит только человек.
- Автоматизация окупается числом повторов: одноразовую проверку автоматизировать дороже, чем пройти.
- В профессию входят через ручное, потому что решение, что проверять и что означает красное, принимает человек.
Что почитать дальше
- Жизненный цикл разработки и тестирования — в какой момент в цикле вообще появляется место для проверок.
- Исследовательское тестирование — как ищут то, чего нет ни в одном списке ожиданий.
- Как устроена автоматизация — экономика автотестов и лестница подходов, от записи действий до сценариев на языке бизнеса.
- Уровни тестирования — почему проверок без экрана на проекте больше, чем через экран.