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

[Guriy]

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

Либо необходим большой отрезок времени для проверки - как пример - репликация данных.

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

[Kaluga]

Парень! (или девушка?)
Есть только один способ реальной оценки производительности - это субъективные ощущения начальника, то есть тебя. Потому как все это кол-во багов и т.п. - полная туфта для дядек в аппер менеджменте. Потому как они тока за слова "это хороший тестировщик" премию не дадут, а вот за "он нашел NNN багов" - очень может быть. =)
В реальности же все эти погони за цифрами тока вредять процессу, т.к. люди начинают работать не для того, чтобы сделать работу хорошо, а для того, чтобы занести как можно больше багов в трек систем. Что не тождественно равно.
Мой совет - сразу забей на методики такого типа. Просто смотри, если человек делает назначеные ему задачи четко и в срок - он молодец. А если сроки провалены, и еще в ответ ты получаешь всякую муру, типа "оч. трудный участок"... то... ну сам понимаешь. Но начинать в этом случае опять же надо не с него, а с себя. Ты как манагер обязан его так сказать "мотивировать". =)
P.S. Честно скажу, что все таки бывают невменяемые (немотивируемые) товарищи... во всяком случае для меня. =) но их сразу видно. И без подсчета багов.

[barancev]

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

[Case]

Если нужны цифры - можно играть с количеством пройденный тестовых сценариев, а не с количеством найдённых там ошибок. Если у тестера задачи - вот этот чек-лист на вот этих 3-ёх окружениях - то это уже реально осязаемый кусок работы. Это если нужно оценить для командования.

А балбесов видно невооружённым взглядом.

[Case]

Подниму тему заново, так как появились мысли на этот счёт.

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

Пояснюсь: имеем после двух месяцев работы тестировщика 2000 ошибок в трекере от всего тима к примру из 5 человек - примерно по 400 на брата. Рассматриваемый тестер нашёл как и все штук 400 - ок. Смотрим по приоритетам и типам ошибок:
Всего по системе зарегистрировано 200 критических ошибок (тут и далее цифры потолочные), всемибыло найдено по 45 (4*45 = 180) и нашим рассматриваемым товарищем - 20. Тут уже можно делать какие-то выводы. То есть на общем фоне количество ошибок вроде бы ок, но по сравнению с другими тестерами исследуемый нашёл меньше критических ошибок - то есть менее глубоко вникал?


Оценка конечно не формальная, но если от человека вышло определённое количество багов, как и от всех, а половина потом была закрыта "as designed", а вторая половина моет быть отнесена к изыскам тестирововчной мысли (ключики в реестре поудалять и посмотреть "а что будет?") - то можно делать определённые выводы.

[Undi]

То есть на общем фоне количество ошибок вроде бы ок, но по сравнению с другими тестерами исследуемый нашёл меньше критических ошибок - то есть менее глубоко вникал?


Оценка конечно не формальная, но если от человека вышло определённое количество багов, как и от всех, а половина потом была закрыта "as designed", а вторая половина моет быть отнесена к изыскам тестирововчной мысли (ключики в реестре поудалять и посмотреть "а что будет?") - то можно делать определённые выводы.

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

[Undi]

Оценка конечно не формальная, но если от человека вышло определённое количество багов, как и от всех, а половина потом была закрыта "as designed", а вторая половина моет быть отнесена к изыскам тестирововчной мысли (ключики в реестре поудалять и посмотреть "а что будет?") - то можно делать определённые выводы.

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

я всегда стараюсь учитывать, так сказать, категорию конечных пользователей. Например, если тестируется какое-то приложение для банков, то 99,9% что в реестре меняться ничего не будет. Если для "менеджеров среднего звена", например, строительной компании, то можно предположить наличие у них свободного времени и фантазии :D , т.е. имеет смысл проверить "что будет если..." (реестр, произвольно выбранные схемы и шрифты в windows, и т.д.). Если что-то пишется для гос. структуры, можно предположить, что там стоят 486-ые :D . А если в ТЗ указано Р100, на нем может оказаться 24МБ оперативной памяти и т.д....

[Case]

Творчество приветсвуется, когда оно дополняет обязательную часть, верно?
А если только творчество?

[Undi]

Творчество приветсвуется, когда оно дополняет обязательную часть, верно?
А если только творчество?

Если не выполнена обязательная часть, соответственно, не выполнена поставленная задача.
Если я поняла правильно, то не ясно зачем в таком случае дополнительные поиски оценки эффективности. Есть поставленная задача. Если она не выполнена - тестировщику минус. Если тестировщик регулярно не выполняет поставленные задачи, все и так ясно, без анализа количества и качества багов:)

[Case]

Что значит выполнена обязательная часть?
Человек рапортует о прохождении по заданному количеству тестовых окружений. Он работу выполнил. Нужно оценить - насколько верно: вот и придумывается как оценить.

[external]

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

[Viktor]

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

[Undi]

Что значит выполнена обязательная часть?
Человек рапортует о прохождении по заданному количеству тестовых окружений. Он работу выполнил. Нужно оценить - насколько верно: вот и придумывается как оценить.

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