Как оценивать труд тестеров
Содержание
Ларри Остерман начинает свою статью словами: «Вероятно, эта статья покажется немного спорной». Я с ним не согласен. Мне эта статья совершенно не кажется спорной: она абсолютно и полностью правдива относительно того, что любые попытки измерить качество или производительность тестеров по тестовым метрикам обречены на неудачу. Просто большинство людей об этом не знает. Пока.
В сущности, этот принцип также относится к разработчикам, руководителям и вообще почти всем, кто занимается интеллектуальной работой. В тот момент, когда вы попытаетесь измерить качество тестера или разработчика по любой метрике, которая только придет вам в голову, тестеру или разработчику потребуется всего несколько минут, чтобы оптимизировать свою работу по этой метрике - то есть обхитрить систему для получения высоких показателей с одновременным сокращением их истинной производительности.
Нам часто кажется, что метрики можно слегка подстроить, чтобы заставить людей работать лучше. Опыт показывает, что это не так. Подгонка метрик приводит к подгонке итоговых показателей, но реально вы ничего не добиваетесь. Не работает сама базовая идея измерения.
В своих продуктах я хорошо сознаю справедливость этого утверждения. Спроектированная мной программа отслеживания ошибок FogBugz не включает метрики производительности и не дает возможности легко определять их. В своих маркетинговых материалах мы указываем, что при любых попытках наказывать программистов за ошибки в коде можно быть уверенным лишь в одном: что рано или поздно количество «ошибок» в базе данных уменьшится до нуля, тогда как количество ошибок в программе останется прежним. Мы не хотим, чтобы система FogBugz превратилась в дубину для службы персонала. Всего неделю назад я общался по телефону с клиентом, которому нужна была любая система отслеживания ошибок, позволяющая собирать статистику относительно того, «сколько времени у программистов уходит на исправление ошибок». Я объяснил, почему в нашей системе эта возможность отсутствует, и скорее всего, никогда не появится в будущем, даже если из-за этого мы потеряем клиента. Я предпочитаю потерять клиента, чем видеть, как нашу программу обвиняют в чужих управленческих ошибках. И знаете что? Ничего страшного не произойдет. Руководители все равно знают своих лучших тестеров и разработчиков. Это те люди, о которых говорит Пол Грэхем в своей статье «Великие хакеры». Чтобы понять, кто не справляется со своей долей работы, вполне достаточно обычных мыслительных способностей, заложенных в ваш мозг при рождении. Никакие искусственные метрики, которые так легко обходятся, для этого не нужны.
Вероятно, эта статья покажется немного спорной :).
Среди руководителей групп тестирования встречается нездоровая тенденция измерять производительность своих подчиненных по количеству ошибок, о которых они сообщают. Насколько мне удалось разобраться, их логика выглядит примерно так.
Руководитель 1. Так, нам нужны конкретные метрики для оценки производительности работы наших тестеров. Какие будут предложения?
Руководитель 2. Лучший тестер - тот, кто находит больше всего ошибок, верно?
Руководитель 1. Логично. Давайте оценивать их работу по количеству представленных ими ошибок!
Руководитель 2. Хмм. Но ведь тестеры могут обойти систему - они будут сообщать о десятках выдуманных ошибок, чтобы накрутить свои счетчики…
Руководитель 1. Верно. Как бы это предотвратить? … Я знаю, давайте оценивать их по количеству ошибок, помеченных как «исправленные» - ошибки с пометками «не поддается исправлению», «обусловлено архитектурой» или «не удается воспроизвести», не будут учитываться в метрике.
Руководитель 2. Вроде бы должно сработать; сейчас я разошлю сообщения среди наших тестеров.
Звучит неплохо, не правда ли? Работа тестеров будет оцениваться по абсолютной величине, вычисленной по количеству найденных ими реальных ошибок - не фиктивных, а настоящих ошибок, требующих внесения изменений в продукт.
Проблема в том, что на практике эта идея не работает.
Тестеры получают мощный стимул для мелких придирок - вместо того, чтобы искать значительные ошибки в продукте, они пытаются выявлять ошибки для увеличения своих счетчиков. И это создает конфликты с разработчиками, если последние посмеют отнести найденные ошибки к любой категории, кроме «исправлено».
Давайте посмотрим, как это происходит, на следующем простом примере.
В моем приложении вызывается диалоговое окно следующего вида:
Не оценивайте труд тестеров по тестовым метрикам
Без введения специальных метрик большинство тестеров зафиксируют «Множественные ошибки в диалоговом окне ввода пароля»; под этим понятием подразумеваются орфографическая ошибка и неточное выравнивание подписи к тестовому полю.
Возможно, они также зафиксируют отдельную ошибку локализации, так как подпись отделена от текстового поля слишком малым промежутком (отдельную, потому что эта ошибка относится к другой категории).
Но если производительность труда тестера будет оцениваться по количеству найденных им ошибок, у него появляется стимул сообщать о как можно большем количестве ошибок. Так одна ошибка превращается в две - опечатка и неверное выравнивание.
В этом варианте проблема абсолютно ничтожна; для меня исправить одну ошибку ничуть не сложнее, чем две.
Но что произойдет, если проблема не является настоящей ошибкой - вспомните, ошибки типов «не поддается исправлению» или «обусловлено архитектурой», не включаются в метрику, чтобы тестеры не заполняли базу данных вымышленными ошибками с целью искусственной накрутки своих счетчиков.
ТЕСТЕР. Если создать файл, войдя в систему в качестве администратора, то поле владельца в дескрипторе безопасности файла устанавливается равным BUILTIN\Administrators вместо текущего пользователя.
Я. Да, так и должно быть, поэтому я отношу ошибку к категории «обусловлено архитектурой». Дело в том, что Microsoft® Windows NT® считает всех администраторов взаимозаменяемыми, поэтому при создании файла участником BUILTIN\Administrators в качестве владельца указывается группа, чтобы любой администратор мог изменить DACL для файла.
Обычно дискуссия на этом заканчивается. Но если производительность тестера оценивается по количеству выявленных им ошибок, у него появляется стимул оспаривать любую классификацию ошибок, кроме «исправленных». Поэтому разговор продолжается:
ТЕСТЕР. Архитектура тут ни при чем. Покажи, где в спецификации указано, что в качестве владельца файла должна быть указана учетная запись BUILTIN\Administrators.
Я. В спецификации этого нет. Так работает NT; это особенность системы.
ТЕСТЕР. Тогда я списываю ошибку на твою спецификацию, потому что в ней этот момент не документирован.
Я. Погоди - моя спецификация не должна объяснять все тонкости инфраструктуры безопасности операционной системы. Если у тебя возникли проблемы, обращайся к авторам документации NT.
ТЕСТЕР. Нет, это ТВОЯ проблема - спецификация написана плохо, так что исправляй ее. Я приму «архитектурную» классификацию только в том случае, если ты мне покажешь спецификацию NT, в которой описано это поведение.
Я. (вздыхая). Ладно, записывай ошибку на спецификацию, а я посмотрю, что можно сделать.
Дальше возможны два пути: либо я должен документировать все тонкости внутреннего поведения (а в области безопасности таких тонкостей очень много, особенно в отношении наследования ACL), либо я должен преследовать разработчиков NT, сообщать о неточности и заставлять вносить ее в спецификации. Ни один из этих путей не приблизит меня к сдаче продукта. Возможно, это будет способствовать улучшению документации NT, но к МОЕЙ задаче это не относится.
Кроме того, выясняется, что показатель «наибольшего количества выявленных ошибок» изначально ущербен. Тестеры, регистрирующие наибольшее количество ошибок, не всегда обеспечивают наилучшую проверку продукта. Часто наибольшую пользу для группы приносит тот тестер, который готов потратить дополнительное время на анализ внутренних причин, и вместе с перечнем ошибок приводит подробную информацию об их возможных причинах. Но такие тестеры не могут похвастаться наибольшей плодовитостью, потому что им приходится расходовать дополнительное время на проверку четкой воспроизводимости ошибки и сбор информации о происходящем. Время, которое можно было бы потратить на поиск всяких мелочей, тратится на проверку «качественности» ошибок - иначе говоря, ошибок, способных помешать выпуску окончательной версии продукта, а не придирок типа «подпись смещена на полмиллиметра».
Я не хочу сказать, что метрики - это плохо. Вовсе нет. Однако оценка производительности людей на основе этих метрик - верный путь к катастрофе. В команде Windows NT 3.1 был один тестер, помешанный на проблемах целостности данных, и неустанно выискивавший эти ошибки. Правда, он нашел их не очень много. Зато каждая обнаруженная ошибка была абсолютно критична для успеха продукта. Если бы его работа оценивалась по метрике «количества найденных ошибок», результат был бы просто жутким, потому что его показатели были относительно низкими по сравнению с другими тестерами в этой организации. Однако его ценность для организации была ничуть не меньшей, а то и большей, чем ценность любого другого тестера. Тем не менее, абсолютная метрика не признала бы его вклад в создание продукта.
Небольшое дополнение: уже после написания исходной версии этой статьи я обсудил ее с парой разработчиков за обедом. По словам одного из моих собеседников, я забыл упомянуть о том, что оценка производительности должна складываться из двух этапов:
- Измерение: дайте мне число, представляющее качество работы, выполняемой данным пользователем.
- Оценка: насколько хорошо справляется работник со своим делом с учетом этой оценки? Иначе говоря, метрике требуется присвоить определенный весовой коэффициент - насколько она важна для общей производительности?
Далее мы перешли к обсуждению того факта, что любая метрика абсолютно бесполезна, если только она не подвергается постоянной переоценке для определения ее релевантности - метрика полезна лишь в той степени, в какой она действительна.
Также мои собеседники отметили, что абсолютное количество ошибок не может использоваться для оценки тестера. Тестер, который потратил две недели на отыскание четырех ошибок переполнения буфера, скорее всего, принесет больше пользы, чем тестер, потративший те же две недели на выявление 20 тривиальных ошибок. В качестве метрики было предложено использовать значение поля «серьезности» ошибки, но мой коллега отметил, что это имеет смысл только в том случае, если значение этого поля имеет реальный смысл, а это часто не так (объективно определить относительную серьезность ошибки может быть очень трудно, и заполнение этого поля часто поручается самому тестеру - такая стратегия открывает широкие возможности для злоупотреблений, если только все ошибки не проходят внешнюю классификацию, а этого часто не происходит).
К концу дискуссии мы согласились на том, что количество ошибок может быть интересной, но никак не единственной метрикой.
