Скрипач не нужен или зачем тестировщикам багтрекер

Приветствую. В тестировании накопилось много нешатаных устоев, предлагаю исправить ситуацию.

У большинства IT специалистов в голове плотно укоренилась связка тестировщик-багтрекер. Тестировщики любят багтрекеры. Жить без них не могут.
Книжки, гуру и онлайн-конференции не переставая говорят о важности, нужности и полезности багтрекера в жизни тестировщика.

Я считаю, что багтрекер тестировщику не нужен. Он нужен программистам, менеджерам, сопровождению. А тестировщику он даже вреден.

Почему вреден?

Допустим, мы регулярно и полуавтоматически ведем такую статистику:
За, например, итерацию, был исправлен, например, 31 дефект, было найдено, например, 30 дефектов, из них клиентами, например, три.
И мудрое руководство на основании этих цифр что-нибудь про тестировщиков думает и решает. Хорошее и плохое.

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

Но из трех цифр статистики только одна понятна и относительно правдива. То, что клиенты сообщили нам о трех багах — факт. А то, что программисты исправили 31 баг, а тестировщики нашли 30 — откровенная ложь.

При тестировании таски — по крайней мере в нашем случае — баги не регистрируются, но попадают в комментарии к таске или передаются программисту голосом, и, по самым скромным меркам, тестировщик находит в 5-20 раз больше багов, чем регистрирует в трекере.

Можно сказать, что результаты работы тестировщика — это все коммиты программиста после того как он отдал код на тестирование.

То есть выводы о качестве работы тестировщиков делаются по данным из системы, в которой отражены только неудачи тестировщиков, но никак не отражается огромный объем работ, который они проделывают.

Что же попадает в багтрекер:

• баги, найденные клиентами;
• баги, найденные не тестировщиками;
• баги, которые нельзя исправить сейчас с этим разработчиком в рамках этой задачи — то есть достаточно серьезные и большие задачи на изменение кода, наверняка требующие и дополнительной аналитики.

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

В то же самое время, вся тяжесть обслуживания и поддержания багтрекера в актуальном состоянии ложится на тех, кто его не использует — тестировщиков.

Но может быть он все таки нужен? Какие там у тестировщиков цели?

Цели тестировщиков от первого к пятому уровню TMM я понимаю так: поиск дефектов, доказательство соответствия требованиям, удовлетворение потребностей заказчика, управление качеством, предупреждение дефектов.

Пользуются ли тестировщики багтрекером при поиске дефектов в новой функциональности? Я поспрашивал у коллег-тестеров, как они пользуются багтрекером. 98% времени использования — заведение дефектов. Информацию из него они получают крайне редко.
Радует ли наличие неисправленных баг клиента — «Ваша проблема нам уже известна»? Нет, его радует отсутствие такого списка.
Можно ли провести анализ типовых ошибок разработчиков, основываясь лишь на каждой 20 ошибке?

А какие есть версии?

Давайте на минуту представим, что у нас багтрекера — нет.
Тогда баги найденные не тестировщиками будут обрабатываться в системе, специально предназначенной для управления инцидентами — Service Desk. И специально обученными людьми, умеющими отличить багу от каприза клиента или неправильной настройки.

Баги которые нельзя исправить прямо сейчас — оформляются как таски разработчикам — и занимаются этим те, кто в рамках процессов имеет право отдавать задачи на вход процесса разработки. Мне кажется, или это тоже должны быть не тестировщики?

А чем же должны заниматься тестировщики?
Своей работой.

Disclaimer

Мнение, выраженное в этом тексте может не совпадать с мнением разнообразных гуру, моего руководства и моим собственным. У нас в команде BT был, есть и будет.
Но иногда стоит посмотреть и с другой стороны, не так ли?