Один из самых парадоксальных моментов в работе тестировщика — это когда всё работает, а ты знаешь, что баг где-то рядом.
Кнопка нажимается, форма отправляется, письмо приходит. Всё по чек-листу.
Но если вы немного задержались в профессии, то знаете:
🔍 настоящие баги живут за пределами «ожидаемого поведения».
Почему "всё работает" — не значит "всё в порядке"?
Тестировщик проверяет функциональность.
А пользователь проверяет продукт жизнью.
Причём жизнью странной: с разной скоростью интернета, копипастой из Excel, телефоном в руках и капучино в другой.
Вот и появляются ошибки, которых никто не ждал:
— неверный формат даты в Firefox
— двойное нажатие, отправившее заказ дважды
— апостроф в фамилии, сломавший аватарку
— пустое поле, которое визуально не пустое
Именно поэтому одна из самых важных компетенций в тестировании — умение мыслить нестандартно.
Что помогает находить такие баги:
🧩 Думать, как пользователь, которому всё мешает.
Отключить интернет, ввести странные символы, перезагрузить на середине шага, скопировать из Word.
🧩 Искать граничные случаи.
Что произойдёт при максимуме символов? Что, если поле оставить пустым, но нажать кнопку?
🧩 Знать слабые места продукта.
Формы, авторизация, интеграции с внешними сервисами, всё, что связано с данными — баги любят именно это.
Кейс из практики:
На одном проекте пользователь не получал SMS с кодом.
Ошибка не воспроизводилась. Всё выглядело нормально.
Оказалось, что дизайнер поставил маску номера без плюса, и часть пользователей вводили "8" вместо "+7".
Сервер принимал, не ругался — и просто не отправлял сообщение.
На тестах — ОК. В проде — массовый отвал авторизаций.
Вывод:
🛠️ Настоящее тестирование начинается не с чек-листа, а с вопроса: “А что будет, если…”
Если у вас есть чутьё, логика и желание «подкрутить винтики», — вы уже на пути к сильному QA.
