Фирма

«Инрэко ЛАН»

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

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

Первое, что приходит на ум, – по количеству найденных дефектов. И именно этот показатель я сходу пытался ввести в «Инрэко ЛАН». Однако сразу же возникла бурная дискуссия, которая и подтолкнула меня к анализу данного критерия. На эту тему я и хочу порассуждать в этой статье.

Количество найденных дефектов - крайне скользкий показатель. Об этом же твердят и все ресурсы в сети, обсуждающие данную проблему (http://www.software-testing.ru/, blogs.msdn.com/imtesty, it4business.ru, sqadotby.blogspot.com, blogs.msdn.com/larryosterman, sql.ru, http://www.testingperspective.com/ и много-много других). Проанализировав собственный опыт и эти ресурсы, я пришел к следующему дереву проблем:

Дерево проблем при оценке числа найденных дефектовВо-первых, дефект дефекту – рознь. Один тестировщик может искать дефекты в расположении кнопочек в приложении, другой – копаться в логике и придумывать сложные тестовые ситуации. В большинстве случаев первый тестировщик найдет больше дефектов, потому что даже на подготовку теста у него будет уходить гораздо меньше времени, но ценность таких дефектов значительно ниже. Эта проблема легко решается введением критичности дефекта. Можно оценивать по количеству найденных дефектов в каждой из категорий. У нас, например, их 4: критичный, значительный, средний и малозначительный. Но поскольку граница определения критичности не совсем четкая, хотя у нас и есть формальные признаки критичности, то можно пойти двумя более надежными путями. Первый - определенная часть найденных дефектов за выделенный период должна быть не малокритичными дефектами. Второй – не учитывать при оценке малозначительные дефекты. Таким образом, мы боремся с желанием тестировщика набрать как можно большее количество дефектов за счет описания мелочных изъянов, заставляя его (или чаще её) копать глубже и находить серьезные дефекты. А они всегда есть, поверьте моему опыту. Я выбрал второй вариант – отбрасывать малозначительные дефекты.

Вторая причина “скользкости” такого критерия – присутствие в системе достаточного количества дефектов, чтобы тестировщик мог их найти. Тут есть три фактора. Первый – сложность логики и технологии системы. Второй - качество кодирования. И третий – стадия проекта. Разберем по порядку эти три фактора. Сложность логики и технологии, на которой написана система, влияет на потенциальные недочеты, которые могут быть допущены. Причем зависимость здесь далеко не прямая. Если реализовывать простую логику на сложной или незнакомой платформе, то ошибки будут в основном связаны с некорректным использованием технологии реализации. Если реализовывать сложную логику на примитивной платформе, то, скорее всего, ошибки будут связаны как с самой логикой, так и со сложностью реализации такой логики на примитивном языке. То есть нужен баланс при выборе технологии реализации системы. Но часто технологию диктует заказчик или рынок, поэтому повлиять мы вряд ли можем. Значит, остается лишь учитывать этот фактор как некий коэффициент потенциального количества дефектов. Причем значение этого коэффициента, скорее всего, нужно определять экспертным путем.

Качество кодирования. Здесь мы уже точно никак повлиять не можем на разработчика. Зато мы можем: а) опять же экспертно оценить уровень разработчика и включить его как еще один коэффициент и б) постараться предотвратить появление ошибок в коде за счет модульных тестов, сделав обязательным требованием 100% покрытие кода модульными тестами.

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

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

Функция показателя эффективности работы тестировщика может выглядеть следующим образом:

, где

(1)

Defects – количество находимых дефектов,

Severity – критичность находимых дефектов,

Complexity – сложность логики системы,

Platform – платформа реализации системы,

Phase – фаза проекта,

Period – рассматриваемый период времени.

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

Учесть все факторы на данный момент пока не удается, однако совместно с нашим ведущим разработчиком Иваном Астафьевым и руководителем проектов Ириной Лагерь, мы пришли к следующей формуле, учитывающей число дефектов и их критичность:

, где

(2)

E – эффективность, определяемая по числу найденных дефектов,

DЗаказчик – число дефектов, найденных заказчиком, но которые должен был найти оцениваемый тестировщик,

DТестировщик – число дефектов, найденных тестировщиком,

k и d – поправочные коэффициенты на общее количество дефектов.

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

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

Здесь есть нюанс, связанный с общим количеством анализируемых дефектов. Естественно, чем больше статистики, тем лучше, но иногда нужно проанализировать различные этапы проекта, иногда просто требуется оценка по каждому периоду времени. И одно дело, когда за период найдено 4 дефекта и 2 из них – заказчиком, и совсем другое, когда найдено 100 дефектов, и 50 из них - заказчиком. В обоих случаях отношение числа дефектов, найденных заказчиком и тестировщиком, окажется равным 0.5, но мы-то понимаем, что в первом случае не все так плохо, а во втором пора бить в набат.

Без особого успеха попытавшись сделать строгую математическую привязку к общему количеству дефектов, мы приделали, по выражению той же Ирины Лагерь, «костыли» к этой формуле в виде интервалов, для каждого из которых определили свои коэффициенты. Интервала получилось три: для статистики от 1 до 20 дефектов, от 21 до 60 дефектов и для статистики по более чем 60 дефектам.

Кол-во дефектов

k

d

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

1-20

1,5

0,51

60%

21-60

2,5

0,54

40%

61-…

3,5

0,22

30%

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

Имеем графики следующего вида:

Черный график отражает критерий для выборки более 60 дефектов, желтый – для 21-60 дефектов, зеленый – для выборки менее 20 дефектов. Видно, что чем больше выборка, тем левее график пересекает ось X. Как уже говорилось, для оценивающего сотрудника это означает, что чем больше выборка, тем больше можно доверять этой цифре.

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

Такой метод оценки по соотношению количества найденных дефектов командой тестирования и заказчиком/пользователем/клиентом, мне кажется разумным и более-менее объективным. Правда такую оценку можно провести только после завершения проекта или, как минимум, при наличии активных внешних пользователей системы. Но что делать, если продукт еще не используется? Как в этом случае оценивать работу тестировщика?

Кроме того, такая методика оценки эффективности тестировщика порождает несколько дополнительных проблем:

1.      Один дефект начинает делиться на несколько более мелких.

·        Руководитель тестирования, заметивший такую ситуацию, должен пресекать ее уже неформальными методами.

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

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

3.      Отсутствие оценки качества находимых дефектов, поскольку единственной целью тестировщика становится количество дефектов, и, как следствие, отсутствие мотивации у тестировщика к поиску “качественных” дефектов. Все-таки нельзя приравнивать критичность и “качество” дефекта, второе является менее формализуемым понятием.

·  Здесь решающую роль должен сыграть “настрой” и тестировщика и руководителя. Только общее правильное (!) понимание значения такой количественной оценки может решить данную проблему.

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

Метки: дефекты | тестирование | управление | эффективность

Добавить комментарий