Сообщений в теме: 53

[natalka]

Здраствуйте!
Мне необходимо составить критерии для оценки работы тестировщиков. У нас на фирме пытаються ввести новый способ оплаты труда. Каждый месяц надо будет оценить работу тестирования.
Есть процедура тестирования, но эти критерии слишком общие. Нужно реальные критерии по которым можно оценить работу, не зависимо от внешних факторов (не сдали во время версию, плохая документация и т.д.).
Задание не из легких. Поэтому прошу вашей помощи.

[Darkus]

Здравствуй.
Начните с того, что узнайте какие критерии оценки программистов есть и есть ли они вообще. Может стоит уточнить чего хочет начальство от программистов и от тестировщиков? Это была бы лучшая оценка.
...
Относительно оценки работы тестировщиков можно использовать диаграмму тесты\ошибки.
Можно делать срез допустим каждые 2 недели и смотреть увеличивается ли количество тестов и уменьшается ли при этом показатель ошибок. (до момента "насыщения", т.е. когда тесты дальше уже не целесообразно писать, чтобы они не были лишними).
Возможно понадобится человек, который бы проверял уже оттестированные программы. Если возникают ошибки и эти ошибки можно было бы найти самому тестировщику, то это плохой показатель. Если ошибки "плавающие" или трудновоспроизводимые, то это уже не настолько критично. Допустим тестировщик сдаёт отчёт об найденных ошибках и о количестве прошедших тестов. (Можно посмотреть, что некоторые ошибки были тяжеловоспроизводимые и тем не менее тестировщик нашёл их...)
У программистов оценка их работы - это готовый код (который, кстати, должен быть тоже не "дырявый", что везде валится.)
У тестировщиков оценка их работы - это насколько довольные пользователи программой и насколько мало от них приходит сообщений об ошибках. А если и приходят, то мог ли тестировщик поймать сам такие ошибки.
Я пока не знаю такой конкретной системы универсальной системы, но наверное пытался бы делать так, как написал выше.

[Vasiliy]

Добрый день.
Могу только посоветовать, чтобы не пытались считать количество найденных багов. Имхо, это плохо сказывается на работе тестера.

[I_G]

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

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

[Green]

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

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

[van]

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

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

У нас таких причины две:
1. малое количество тестеров
2. недостаточное время на тестирование

[Green]

to van

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

И даже динамические показатели не отражают реальной ситуации. Но нужно отдать им должное - все же, динамические показатели описывают ее точнее.

Сейчас моя команда работает над созданием УПРАВЛЯЕМОГО процесса юнит тестирования в департаменте разработки. Что бы процесс был контролируемым и управляемым его нужно измерять, т.е. он должен иметь ОБЪКТИВНЫЕ измеряемые показатели. Для начала мы выбрали самый простой - степень покрытие кода юнит тестами. Необходим четкий критерий неудовлетворительной работы. Пока думаем остановиться на 70%. Такой же подход должен быть и в тестировании.

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

Вторым этапом можно мерить качество покрытия требований. Это означает, что наиболее критичные требования должны быть протестированы набором тестов с различными входными значениями.

Из выше изложенного можно сделать два вывода.
1. Оценить работу тестировщика можно только при наличие задокументированных требований к разрабатываемой системе или описанной модели с высокой степенью детализации.
2. Нужно писать тест кейсы и создавать базу входных тестовых данных.

Ну, и, конечно, составлять отчеты о проделанной работе.
B)

[Натали]

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

И у меня вопрос к мэтрам - а объясните на пальцах, чем плоха оценкам по багам (их количеству и качеству)?

[Green]

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

Я постараюсь изложить все "подводные камни" оценки работы тестировщика в отдельной статье, которая будет размещена на сервере тестировщиков.

[Натали]

Этот вопрос уже частично затрагивался на форуме

Да, я помню этот достаточно длинный тред. Но у меня после него не сложилось четкого обоснования "почему плохо".
То есть я понимать - понимаю, а начальству обоснованно возразить - не могу.

И поскольку мне это совершенно не срочно, то я буду ждать Вашей статьи. :)

[van]

Для Натали.

Плюсом к статье Сергея может послужить книга уважаемого госпдина Канера (по - моему главы 5 и 6). В этих главах приводится очень много доводов против проведения статистики по количеству ошибок. Он очень правильно об этом пишет, что основная цель нахождения ошибок, их документирования и далее составления всякого рода отчетов - это исправление ошибок и улучшение качества разрабатываемого ПО, а не оценка тестировщиков. Хотя, я понимаю, что реально очень часто все происходит иначе.

[Натали]

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

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

А вообще - пойду перечитаю Канера, спасибо.

[dlg99]

Testing Testers: Things to Consider when Measuring Performance by James Bach

[natalka]

Спасибо всем за комментаоии.
Попробую немного разъяснить ситуацию.
У Green был вопрос, кто будет оценивать. Оценивать будет начальник отдела тестирования и начальник проекта.
Анализ по количеству багов найденным клиентом не годится, так как у нас тесты над большими проектами проводятся от 1 и до 4 месяцев. А начальство хочет оценить каждый месяц, чтобы знать заслужил ли тестировщик премиальные или наоборот.
По требованиям - звучит хорошо. Но только для тех проектов, где хорошо описаны эти требования. У нас такие проекты редко, я уже устала воевать. Поэтому проблема. Сдача версии задерживается, документация не полная. Бедный тестировщик долден бегать по всем и собирать инфо, чтобы вообще можно было написать какой-нибудь сценарий. Ну вот и как оценить он хорошо работал или плохо. Если сумел собрать информацию, значит молодец. А если плохо собрал, то клиент будет не доволен. Но это опять же не значит что тестировщик плохо выполнил свою работу. Он может очень хорошо ее выполнил, но другие напортачили. Поэтому я уже неделю мучаюсь и не могу придумать объективную оценку. Если еще учесть, что при сдаче версии на тестирование она не всегда замораживается, то вообще супер - приходиться одну и ту же функциональность по сто раз тестировать и объясни потом начальнику проекта почему не успеваем и почему до сих пор так много багов лезет.
Конечно оценка программистов тоже будет, но так сразу все не изменится, так как на всех давят сроик и не реальные сроик. В которые даже теоретически нельзя выпустить качественный продукт. А вот оценить бедных сотрудников, которые работают по ночам - требуют.
Если бы у нас были идеальные проекты, то я бы придумала критерии. Но так как они такие как есть, то даже и не знаю что придумать.
Я пыталась убедить не вводить такую систему, пока не будет порядка с документацией и сдачей версии, но это было бесполезно. Начальство думает, что народ тогда будет лучше работать.

В общем, наверное описала всю сложность ситуации.

Наталия

[Vasiliy]

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

[natalka]

Добрый день Василий. Я как раз в этом отделе и являюсь начальником. А мой начальник - это директор всей разработки, у нас только отдел тестирования отдельно выделили. Мне тоже кажется, что месяц это слишком часто. Но начальник уж очень вцепился в эту идею. И как говорится, против начальства не попрешь.

[Darkus]

Попробуйте сделайте максимально удобный для Вас и Вашего отдела план оценки. С умным видом подайте его. А дальше, как фишка ляжет :)

[van]

2 Натали: Все выходные не мог выбросить из головы Вашу проблему относительно критериев оценки, потому что я нахожусь в похожей ситуации - мне тоже необходимы критерии оценки тестировщиков. Правда, никакого давления со стороны начальства на меня нет. Это моя собственная инициатива, поскольку конструктивная оценка нужна как мне самому для понимания - кто что знает, умеет и выполняет, так и самим тестерам для обратной связи.

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

На мой взгляд для оценки тестировщиков необходимо составить перечень некоторых показателей или утверждений, для каждого из которых в дальнейшем будут выставляться оценки по 5 - ти или 10 - ти бальной шкале.

Данный перечень необходимо вормировать исходя из:
1. Служебных обязанностей (требований, предъявляемых к тестировщику вооще или в конкретной компании)
2. Общечеловеческих качеств
3. Взаимодействие с коллективом и т.п.

В ближайшие день - два постараюсь "створить" :) что - то похожее.

[natalka]

Я тоже постараюсь что-нибудь набросать.
Может общими усилиями сможем создать нормальные критерии. :)

[Натали]

Это моя собственная инициатива, поскольку конструктивная оценка нужна как мне самому для понимания - кто что знает, умеет и выполняет, так и самим тестерам для обратной связи.

Ключевые слова - для понимания и для обратной связи. То есть _регулярные_финансовые_ показатели типа премии от этой оценки зависят как минимум не напрямую, если вообще зависят. Я правильно понимаю?