7 ошибок новичков в тестировании и как их не совершать

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

1. Проверять только то, что должно работать

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

Как иначе: после каждого позитивного сценария задавайте вопрос «а что, если наоборот». Отправить пустым, отправить дважды, уйти со страницы посередине, вернуться кнопкой «назад».

2. Писать «не работает» вместо симптома

Репорт «корзина не работает» стоит команде переписки на два дня. Разработчик не знает, что вы делали, на каком стенде и что именно увидели.

Как иначе: место, симптом, условие. «Корзина: после перезагрузки страницы остаётся только последний товар». Полная структура — в шаблоне баг-репорта.

3. Молчать о том, что не успел проверить

Самая опасная ошибка из списка. На вопрос «всё проверил?» новичок отвечает «да», потому что боится выглядеть медленным. Команда выпускает релиз, считая, что покрытие полное.

Как иначе: отчёт всегда состоит из двух частей — что проверено и что нет. «Основной сценарий и оплата картой проверены, СБП и мобильную версию не успел». Это не признание слабости, а информация для решения.

Непроверенное, о котором знают, — это риск. Непроверенное, о котором молчат, — это сюрприз в проде.

4. Додумывать требования вместо вопросов

В описании не сказано, что происходит при отмене оплаченного заказа. Новичок решает, что «наверное, деньги возвращаются», проверяет по своей догадке и закрывает задачу.

Как иначе: каждое «наверное» — это вопрос аналитику или продакту. Половина хороших дефектов находится на этом этапе, до написания кода. И вопрос стоит команде минуту, а дефект в проде — гораздо дороже.

5. Спорить с разработчиком, а не с требованием

«Так и задумано» — фраза, на которой новичок либо сдаётся, либо начинает спорить о вкусах. Оба варианта плохи.

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

6. Проверять только через интерфейс

Заказ оформился, на экране «Спасибо за покупку» — значит, всё хорошо. А в базе сумма записалась без скидки, письмо не ушло, статус остался «новый».

Как иначе: смотреть на слой ниже. Запрос во вкладке Network, запись в базе через SELECT, ответ API. Минимальный набор — SQL для тестировщика и вкладка Network.

7. Прокликивать одно и то же, не думая о покрытии

Проверить возраст 25, потом 26, потом 27 — это три проверки одного и того же класса значений. Времени потрачено втрое больше, покрытие не изменилось, а 17 и 18 остались непроверенными.

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

8. Бояться задавать «глупые» вопросы

Новичок молчит, чтобы не выглядеть некомпетентным, и час разбирается в том, что коллега объяснил бы за две минуты. Через месяц выясняется, что всё это время он проверял не тот стенд.

Как иначе: вопрос про устройство продукта или процесса — это не признак слабости, а часть работы. Правило, которое стоит завести: если застряли больше чем на двадцать минут, идите спрашивать. И формулируйте не «у меня не работает», а «я пытаюсь сделать X, сделал Y, ожидал Z, получил W» — так отвечают быстро и по делу.

Три ошибки поменьше, которые тоже стоят дорого

• Проверять на своих данных и забывать про чужие. У вас в тестовом аккаунте два заказа и короткое имя. У реального пользователя их триста, а имя длиной в строку. Половина дефектов вёрстки и производительности живёт именно там.
• Не фиксировать окружение. «У меня воспроизвелось» без указания стенда, сборки и браузера превращает разбор в гадание. Версия сборки — первая строчка любого репорта.
• Закрывать дефект после слов «я починил». Ретест делает тестировщик, а не разработчик. Пока вы не воспроизвели исходные шаги заново, дефект не проверен.

Что объединяет все семь

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