Расскажу про два бага из практики. Их объединяет одно: пока они жили в проде, все привычные сигналы были зелёными. Билд собирался, тесты проходили, форма отвечала «принято». А продукт при этом не работал. Молча, без единой ошибки в логах.
Я опытный ручной тестировщик, в свободное время осваиваю автоматизацию на Python и ковыряю свои небольшие проекты. Один баг я налажал сам как разработчик и поймал на себе, второй поймал как QA на работе. И тот и другой прошли мимо автотестов. Вот про это и поговорим.
Главная мысль вперёд: зелёный отчёт говорит ровно одно, «то, что я проверил, работает». Про то, что ты не проверил, он молчит. А баги живут именно там.
Баг первый: honeypot, который съел мои заявки
Начну со своего, самого обидного. Поставил honeypot на форму обратной связи в одном своём проекте.
Антиспам на формах, больная тема. Боты дёргают форму, почта забивается мусором. Классическое лёгкое решение, honeypot, ловушка. Добавляешь в форму скрытое поле. Человек его не видит и не заполняет, а бот, который тупо заливает все поля подряд, в него попадается. Поле заполнено, значит бот, заявку отбрасываем.
Выглядит примерно так:
<input name="name" />
<input name="contact" />
#<!-- ловушка: спрятана от людей, видна боту в разметке -->
<input name="company" style="display:none" />if (formData.get("company")) {
#// поле-ловушка заполнено, это бот, тихо игнорируем
return { ok: true }; #// отвечаем «принято», чтобы бот не понял, что попался
}Обрати внимание на последнюю строку. Honeypot специально отвечает «принято» даже отброшенной заявке, чтобы бот не понял, что попался, и не начал обходить ловушку. Логично против ботов. И именно это потом выстрелило мне в ногу.
Форму я прикрыл простым автотестом. Я ручной QA, автоматизацию только осваиваю, но написать базовый E2E на Python уже получалось. Вышло примерно так:
from playwright.sync_api import Page, expect
def test_форма_отправляет_заявку(page: Page):
page.goto("https://example.com/contact")
page.fill("input[name='name']", "Тест Тестов")
page.fill("input[name='contact']", "test@example.com")
page.click("button[type='submit']")
expect(page.get_by_text("Заявка принята")).to_be_visible()Тест зелёный. Открыл страницу, заполнил поля, отправил, увидел «Заявка принята». Деплой прошёл, тест прошёл, всё хорошо. Так я думал.
А потом полез проверять формы руками, по привычке после деплоя. Заполнил заявку вручную, письмо пришло. Заполнил ещё раз, но через автозаполнение браузера, выбрал свои данные из выпадашки. Форма написала «заявка принята».
Письмо не пришло.
Первая мысль, форма отвалилась. Стал проверять, а она работает. Руками приходит, автозаполнением нет. Один и тот же код, одна форма, разница только в способе ввода. И никакой ошибки, интерфейс в обоих случаях радостно рапортует «принято».
Тут до меня дошло, что это не «форма сломалась». Это хуже.
Браузерное автозаполнение и менеджеры паролей не смотрят, видимое поле или скрытое. Они идут по атрибутам, name, type, autocomplete, и заполняют всё, что подходит по смыслу. Поле company, спрятанное через display:none, для автозаполнения такое же поле, как остальные. Браузер видит «компания» и услужливо вписывает туда данные пользователя.
Дальше по моей же логике: поле-ловушка заполнено, значит бот, тихо отбрасываем, отвечаем «принято».
То есть реальный человек с включённым автозаполнением выглядел для сервера как бот. Его заявка улетала в никуда, а он видел «спасибо, заявка принята» и уходил довольный. Я без заявки, он без ответа, и ни ошибки, ни записи, ни сигнала. А автозаполнением пользуется огромная часть людей, так что терял я не иногда, а системно, целый сегмент.
Теперь главное про автотест. Он всё это время был зелёным и остался бы зелёным навсегда. Потому что делал ровно то, что я в первый, разработческий заход: заполнял видимые поля руками, не автозаполнением, и проверял текст на экране, «принято», а не пришло ли письмо. Обе дыры, в которые провалился баг, сидели прямо в моём собственном тесте. Я написал проверку, которая физически не могла поймать эту ошибку, и спокойно смотрел на зелёную галочку.
Почему я вообще это пропустил
Сейчас кто-то скажет: опытный QA, а такую дырку у себя проворонил. Справедливо. Но в этом и суть.
В разработке роли разделяют не просто так: автор кода худший тестировщик своей работы. И дело не в квалификации. Дело в том, что ты проверяешь продукт так, как его задумал, по тому же сценарию, что держал в голове, когда делал.
Мой honeypot стоял на допущении «скрытое поле заполняют только боты». Это допущение и было багом. Из кресла разработчика я не мог его заметить, для меня оно было не гипотезой, а очевидностью. Нужен был кто-то, кто эту очевидность не разделяет.
В нормальной команде это отдельный тестировщик. Но проект я веду один. И вот тут главное для всех, кто тоже один или в маленькой команде без тестирования: не можешь привести второго человека, приведи второй взгляд. Сознательно вылези из роли автора. Перестань быть тем, кто это написал, и стань тем, кто пришёл это сломать, без твоих допущений в голове. Баг я поймал ровно тогда, когда перестал проверять «как делал» и начал «как пользователь, который про мои хитрости не знает».
Это не про то, что у опытного тестировщика не бывает багов. Бывает. Опыт в другом: ты ловишь тихие баги, те, что не кричат об ошибке, и понимаешь, почему они происходят. Этот баг не сложный, он коварный, а это разные вещи: сложный трудно починить, коварный трудно заметить.
Баг второй: заявка на отпуск, которая удваивалась
Этот уже с работы. И что важно, форма была покрыта автотестами, их писал коллега-автоматизатор.
Прилетел баг-репорт от HR: руководителям приходит по две заявки на отпуск от одного сотрудника. Пошёл проверять.
Первым делом спросил коллегу, что там с автотестами на эту форму. Зелёные, говорит, все проходят. Заполнил заявку руками сам, отправилось, одна заявка, одно письмо. Ещё раз, то же самое. По всем признакам работает: и автотесты зелёные, и руками чисто.
Полез в логи того сотрудника, на которого жаловались, а там две заявки. И тут я завис: человек нажал «отправить» один раз, ответ получил один. Откуда вторая?
Разгадка, медленный интернет. Сотрудник нажал «отправить», запрос ушёл, но ответ из-за тормозящей сети задержался. На экране ничего: кнопка не заблокировалась, лоадера нет, тишина. Человек решил, что не нажалось, и кликнул ещё раз. Ушло два запроса. Сервер послушно создал две заявки. А пользователь был уверен, что отправил одну, потому что между кликами ему ничего не показали.
Следствие: руководители недовольны, в графике путаница, разбирайся, какой отпуск настоящий.
Починили просто: блокируем кнопку после первого клика плюс защита от дублей на бэке.
Почему же это пропустили и автотесты, и я руками? Тест на форму был, выглядел он примерно так:
def test_заявка_на_отпуск_отправляется(page: Page):
page.goto("https://hr.example.com/vacation")
page.fill("input[name='dates']", "01.07–14.07")
page.click("button[type='submit']")
expect(page.get_by_text("Заявка отправлена")).to_be_visible()Он кликает один раз, на быстрой стабильной сети, и проверяет, что появилось «заявка отправлена». Ни медленного интернета, ни нетерпеливого человека, который жмёт второй раз, у него не бывает. И я руками проверял ровно так же, на идеальном сценарии. Баг жил в том, чего не делали ни тест, ни я: в реальных условиях реального пользователя. Увидел я его не в форме, а в логах.
Что общего у этих двух багов
Тут легко скатиться в банальность из учебника: «проверяйте граничные данные», «не тестируйте только happy path». Это и так все знают, и я не про это.
Интереснее другое. Оба бага прошли не одну проверку, а сразу две: автотест и ручную проверку на happy path. То есть дело не в том, что «теста не было» или «тестировщик поленился». Дело в том, что и автомат, и человек гоняли один и тот же идеальный сценарий, который кто-то заранее придумал.
Автотест воспроизводит то, что в него заложил автор. Ручная проверка по чек-листу воспроизводит то, что придумал тестировщик. И там, и там сценарий рождается в голове того, кто уже знает, как система задумана. А баг сидит ровно в том, чего никто не задумывал: автозаполнение лезет в скрытое поле, человек на тормозящей сети жмёт кнопку дважды.
Вывод неуютный: добавить ещё тестов того же сорта не помогает. Хоть автоматических, хоть ручных, если все они гоняют идеальный сценарий, баг в неидеальном так и останется невидимым. Нужны не «ещё проверки», а проверки в реальных условиях и взгляд того, кто не разделяет твоих допущений.
Вывод
Зелёный отчёт это не финиш, а старт. Любая проверка, автотест или ручная, честно говорит ровно одно: «то, что я проверил, работает». Но баг почти всегда сидит в том, чего ты не предусмотрел.
Что вынес лично я:
Воспроизводи реальные условия, а не идеальные. Автозаполнение, менеджер паролей, медленный интернет, двойной клик. Баг живёт в сценарии, который ты по привычке пропускаешь.
Проверяй результат, а не ответ интерфейса. «Принято» на экране это просто текст. Реальная проверка, это письмо в почте, запись в базе, одна заявка вместо двух.
Приведи взгляд, который не разделяет твоих допущений. Не можешь привести второго человека, хотя бы сознательно выйди из роли автора.
И отдельно для тех, кто отвечает за продукт, а не пишет тесты. Звучит очевидно, но на практике постоянно выбирают что-то одно: или «у нас всё закрыто автотестами», или «у нас живой тестировщик всё проверит». Эти два бага показывают, что одно другое не заменяет. Автотесты держат регресс и рутину, человек ловит неожиданное и думает «а что если». Если вы правда хотите, чтобы продукт работал, а не чтобы билд был зелёный, нужны оба. Это не «перестраховка ради галочки», это два разных вида слепоты, которые закрывают друг друга.
Зелёный отчёт говорит только про то, что ты проверил. Про то, что ты не проверил, он молчит. А клиенты, как правило, приходят именно оттуда.