Home

Автор: Роб Ламберт (Rob Lambert)

Оригинал статьи: http://thesocialtester.co.uk/how-do-you-measure-the-effectiveness-of-a-tester-the-only-calculation-you-need/

Перевод: Ольга Алифанова

Меня регулярно спрашивают, как измеряется эффективность тестировщика. Обычно я отвечаю "Зачем это вам? Чтобы что?" Мой ответ вызван желанием понять мотивы менеджмента: почему измерение эффективности конкретного человека так важно для них? Обычно этот вопрос задают именно менеджеры.

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

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

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

Как правило, они пытаются измерять две вещи. Во-первых, одинаково ли ценны тестировщик А и тестировщик Б? Можем ли мы поменять их местами и продолжать достигать своих целей? Может, один из них лучше другого?

Во-вторых, они пытаются измерить, приносят ли тестировщик А и тестировщик Б вообще какую-то ценность (что произойдет, если мы от них избавимся?).

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

Звучит бредово, но встречается достаточно часто! Менеджеры любят простые метрики для принятия информированных решений.

Я могу их понять. Причина такого поведения очевиднее некуда – управлять людьми очень сложно!

Управление людьми, понимание ценности, которую они приносят, занимает кучу времени, и (по крайней мере в разработке ПО) не может быть выражено одним числом (вне зависимости от того, во что там верят менеджеры).

Управление людьми требует терпения и выстраивания отношений. Это трудно. Попытка наладить хороший менеджмент может рассказать о вас, как о менеджере, много неприятной правды.

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

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

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

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

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

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

· Как насчет результатов всей команды?

· Как насчет бизнес-ценности, которую приносит ваш продукт?

· Как насчет доходов, генерируемых им?

· Как насчет способности команды решать проблемы?

· Как насчет циклического времени работы?

· Как насчет обратной связи от пользователя?

· Как насчет способности человека к росту и развитию?

· Как насчет того, что чувствуют и думают другие люди об этом человеке?

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

Итак, внимание! Самая лучшая метрика для измерения эффективности тестировщика! Все прочие метрики по сравнению с ней – ничто!

Доверьтесь мне, используйте эту метрику, и вы получите число.

Это верное число!

Это самое важное число.

Это единственное число, которое вам нужно.

Это наиболее всеобъемлющее из всех возможных чисел. Всем числам число.

Эффективность команды разработки или отдельного человека = (количество багов, найденных в течение спринта Х количество багов в коде) / сумма возрастов всех членов команды Х количество ручек в коробке, содержащей 24 ручки).

Придется прокомментировать эту метрику дополнительно.

ПОЖАЛУЙСТА, ради всего святого не используйте ее для принятия решения о чьей-то карьере.

Делайте свою работу. Выстраивайте отношения. Пытайтесь понять своего сотрудника.

Управляйте людьми, а не числами.

Обсудить в форуме