к чему. Вот работа дева очевидна. Результат визуален (в большей степени). То есть, тестировщик видит результат работы дева и работает с этим.
Пользователи тоже. И я не про абстрактную оценку тестировщика. Трэкать время в системе, заводить баги (они могут быть не каждый день), кейсы - это все хорошо. Но отследить работу команды тестировщиков в таком случае может толком только лид. А это не всегда гуд
если конечные пользователи довольны - то все молодцы
Подумайте над метриками, самый плохой вариант время по эстимейтам и кол-во баг. Если у вас есть прод, то сравние кол-ва пропущенных баг к кол-ву найденных. Следите за кол-вом пропещенных регрессионных баг. Следите за кол-вом не дефектов. Коефициенты уже самим подбирать, ну пальцем в небо по последнему примеру не больше 10% не дефектов от всех дефектов уровня мажор+, если больше то нужно искать руткоз ( может и не куа виноваты, а плохое ТЗ или еще что-то)
Мне кажется, тут нужно рассуждать от проблемы а не от самой идеи выставлять кому-то оценки. Какую проблему требуется решить этой активностью? Есть жалобы на качество продукта? Слишком много/слишком мало сотрудников в отделе, нужно оптимизировать косты? По идее начальник отдела должен подготавливать отчет для менеджмента и коллег из других отделов о состоянии продукта. Мол вот такие-то такие-то области проверены, основные косяки на этот релиз, есть такие-то замечания и предложения, вот полный список актуальных багов (ссылка на актуальный фильтр в джире). Замечаний / вопросов по отчету от коллег нет? Всем всё понятно? Какие еще оценки тогда требуются? Внутренние дела отдела, кто плохо работает, кто хорошо - разруливает руководитель. Зачем менджменту влезать в дела конктертного стажера Васи? Если руководителя на проекте нет... Ну значит нужно его назначить, и с него же спрашивать за результат. Результат работы тестировщика - это понятный всем заинтересованным лицам отчет о состоянии продукта а не n багов в неделю.
Обсуждают сегодня