Выдели одно качество, которое мешает тебе в работе как тестировщику

Самостоятельная переоценка серьезности дефектов

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

Почему это может мешать

В теории и на практике Severity (серьезность) дефекта — это объективная характеристика, показывающая степень его влияния на систему. Однако в момент обнаружения бага тестировщик обладает лишь частью картины. Слишком строгая внутренняя оценка может привести к следующим проблемам:

• Потеря оперативности. Вместо того чтобы быстро оформить даже сырой, но потенциально важный баг, я могу потратить время на дополнительные проверки: «А воспроизводится ли это на другой конфигурации?», «А это точно не связано с тестовыми данными?», «Может, я что-то упустил?». В условиях agile-спринта каждая минута на счету.
• Ненужная самоцензура. Может возникнуть мысля: «Это, наверное, мелочь, не стоит засорять баг-трекер / отвлекать разработчика». В результате дефект, который мог бы быть легко исправлен «по пути», рискует остаться не зафиксированным и вылезти позже, когда правка станет дороже.
• Нарушение процесса. Окончательную оценку серьезности (Severity) и приоритета (Priority) должен выставлять не тестировщик в одиночку, а команда (часто — совместно с тимлидом, продакт-менеджером и разработчиком). Предвосхищая их решение, я невольно беру на себя не свою роль.

Практический пример и как с этим бороться

Допустим, в веб-приложении на определенном экране падает скрипт, но только при использовании кириллицы в одном из полей и после трех конкретных действий. Внутренний монолог, который мешает:

«Специфичные данные, сложный сценарий... Это, наверное, низкий приоритет (Priority). Мало кто так сделает. Сначала изучу все кейсы с кодировками, проверю логи...»

Правильный подход, который я для себя выработал, выглядит иначе:

1. Быстрая фиксация. Немедленно создаю дефект с четкими шагами воспроизведения, даже если сценарий выглядит надуманным.
2. Объективное описание. В описании указываю только факты: что делал, что ожидал, что получил. Оценку серьезности на этом этапе либо выставляю «по максимуму» (например, S2 – Major для падения скрипта), либо вовсе оставляю поле пустым, если процесс позволяет.
3. Четкое разделение в шаблонах. Я использую в описании бага отдельные блоки для фактов и для своей предварительной оценки:

**Шаги:**
1. Открыть страницу /create-order
2. В поле "Комментарий" ввести "Тестйцук"
3. ...

**Фактический результат:**
В консоли браузера ошибка "Uncaught SyntaxError", скрипт формы не выполняется.

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

<!-- Примечание для команды: Ошибка критична для функционала, но требует специфичных данных. Требуется оценка приоритета. -->

1. Передача контекста команде. На стендапе или в комментарии к задаче коротко озвучиваю суть: «Нашел падение скрипта при вводе кириллицы в поле X. Завел баг. Сценарий сложный, но последствия поломки функционала. Нужна ваша оценка приоритета».

Вывод

Таким образом, качество, которое необходимо постоянно в себе контролировать — это стремление взять на себя окончательное право ранжирования дефектов. Ключевой навык senior-тестировщика — не только находить сложные баги, но и эффективно встраивать информацию о них в рабочий процесс команды, делегируя решение о важности и срочности. Борьба с этим заключается в доверии к процессу и коллегам: моя главная задача — быть беспристрастным «сенсором» продукта и четко докладывать о всех аномалиях, а решение о том, что важнее, команда принимает совместно. Этот баланс между глубоким анализом и оперативностью коммуникации является одной из самых тонких и важных граней в работе опытного QA-инженера.