До сих пор можно встретить подход, при котором эффективность тестировщика оценивают по количеству заведённых дефектов. Нашёл 50 багов — молодец. Нашёл 10 — значит, работал недостаточно хорошо

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

Тестировщик — не охотник за багами.

Недавно я прочла книгу Кема Кейнера, Джеймса Баха и Брета Петтикорда «Тестирование программного обеспечения. Контекстно‑ориентированный подход». Одна из главных мыслей книги — это то, что тестирование всегда зависит от контекста: особенностей продукта, рисков, целей бизнеса и потребностей пользователей.

Однако, недавно на митапе Ozon Tech я услышала фразу от спикера о том, что «охота за багами — это хорошо». Поиск дефектов — важная составляющая работы QA‑инженера, но цель работы — не найти как можно больше дефектов, а предотвратить их возникновение. И порой для этого действительно нужно найти много дефектов, а иногда важнее приостановить разработку ещё на этапе обсуждения ТЗ и вычитки требований.

Закон Гудхарта в тестировании.
«Когда мера становится целью, она перестаёт быть хорошей мерой.»

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

Хороший QA‑инженер предотвращает баги.

Зрелость тестировщика проявляется не в способности заполнить баг‑трекер.
Сильный QA:

  • анализирует требования до начала разработки

  • замечает противоречия и пропущенные сценарии

  • задаёт вопросы о правах доступа, состояниях, ошибках и ограничениях

  • выделяет наиболее рискованные области

  • предлагает стратегию тестирования

  • проверяет интеграции и бизнес‑логику

  • локализует причины проблем, а не только описывает симптомы

  • автоматизирует проверки, когда это действительно снижает риски и экономит время

  • помогает команде принимать решения о качестве релиза.

Если тестировщик обнаружил неоднозначность в требованиях и предотвратил неправильную реализацию, баг‑репорт не появился. Если он помог разработчику продумать обработку ошибки до написания кода, баг‑репорт не появился. Если он выстроил регрессионное покрытие и проблема не вернулась в продакшен, нового баг‑репорта тоже нет.
Получается парадокс: чем лучше QA предотвращает дефекты, тем меньше у него может быть формально заведённых багов. Оценивать такого специалиста по количеству дефектов = значит наказывать его за качественную работу.

«Мало багов» не означает «плохо тестировали».
Небольшое количество найденных дефектов может означать совершенно разные вещи: Например: продукт стабилен и требования были хорошо проработаны.

То же самое относится к большому количеству дефектов. Оно может говорить как о глубоком тестировании, так и о низком качестве разработки, плохих требованиях, искусственном дроблении задач.

Как же оценивать работу QA‑инженера?

Какой‑то одной универсальной метрики тут нет. И это ОК.
Оценка должна учитывать совокупность факторов: это и качество тест‑анализы, и покрытие продуктовых рисков, участие в анализе требований, качество баг‑репортов, скорость и точность локализации, стабильность регрессионного набора, эффективность автоматизации, а также вклад в улучшения процессов, софт‑скиллы и взаимодейсвтие с командой.
Но даже эти показатели нельзя превращать в механические KPI без разбора контекста.
QA работает не с количеством объектов на конвейере. Он работает с неопределённостью, рисками и качеством сложной системы.

Какой же вывод?

Количество найденных багов — вспомогательный показатель. Хороший тестировщик — не тот, кто нашёл больше багов. Хороший тестировщик — тот, кто помог команде лучше понять риски, предотвратить проблемы и выпустить более надёжный качественный продукт.
А баги — лишь один из инструментов, а не смысл профессии.