Igor K
Это для случаев командной разработки, когда таска(возвращенная) может попасть случайному человеку из команды.
Только этот KPI (если рассматривать как штраф) ещё бы помножить на степень влияния на процесс распределения задач(тасок). Иначе я бы уволился)
Ну если выделить самую важную метрику: То это максимально быстрый поиск и оформление багов, от которых пользователи максимально страдают, или которые приносят максимальные убытки иным способом.
Техподдержка, как бэкграунд, в сравнении с остальными максимально резонирует(или по навыкам, или по мотивации) с большей частью пунктов(кроме наверное последнего). А для продуктов, которые человеко-ориентированы - эти пункты и важнее всего.
То есть тут 2 процесса
1)Таска от тестировщика, который проверят и на ТЗ в случае несоответствия ТЗ проходит сначала к менеджеру, а не разработчику.
2)Менеджер сам проверяет.
Я за то что надо оба процесса одновременно, и это будет best practice из моего опыта(в котором всегда среди ролей была роль кодера(я кодер, я так вижу xD)).
Менеджер должен протыкать все кейсы? Ну по логике рулевой должен верность дороги определять, да. Но будут слепые зоны если не привлекать тестировщиков.
Я написал "могут многое". Шанс ошибки в продакшен будет всегда. Даже со всеми видами тестировщиков. Но разумеется тестировщики будут заниматься в основном проверкой качества, что будет повышать эту метрику, в том числе нахождение ошибок. Особенно это важно, где код один, а платформ много - разные типы браузеров, версии операционных систем. Разработчик не будет запускать везде.
Вообще моя боль души скорее в том, что тестировщики находят, а чинит зачастую не тот кто проектировал(для распространения знаний, и заменимости людей). И ошибки могут чиниться и "создаваться" по кругу, порой повторно. Просто затыкать дырку людьми, и не видеть такую экономию от лишней работы я видел часто. А всего то нужно повысить ответственность разработчиков, но тут свои риски, и нужно знать когда что перевешивается.
Кроме написания автотестов, нужно их ещё читать и поддерживать и понимать в чём ошибка, что затратно если один тест не позволяет за счёт параметров покрыть много кейсов. Да и бывшим кодерам лишь бы покодить. Правда некоторые могут архитектуру тестов похлеще самого проекта замутить. Чтобы минимизировать эти затраты пишут автотесты, которые на одной кодовой базе с проектом, но их пишут практически всегда кодеры с проекта, что время, а также такие тесты могут мешать изменениям проекта или сборки.
Забыли только написать, что некоторые разработчики на проектах где это возможно могут многое и без тестировщиков. Потому что понимают что делают, и при запуске проверяют самые рисковые места, и могут даже место ошибки узнать. И тестировщики остаются для подстраховки и проверки на соответствие ТЗ. Но это зачастую аутсорсерам не нужно, потому что быстрей быстрей, и деньги за открытие и закрытие тасков.
В мифах и легендах древней Греции есть такие титаны, которые держали небосвод. Они его держали, потому что больше никто не мог. И не помню, но кажется им даже ещё проблем за это добавляли. У меня сложилось впечатление, что если чинить там, где очень много ошибок - то, они там скоро опять появятся, да и никто из принимающих системные решения(и сидящий на кормушке) не оценит, так как иначе этих ошибок бы уже не было. Всё упирается в процессы в компании. Реально сделать мир лучше и себе в удовольствие получится, если идти туда, где часть ошибок систематически правят до тестировщиков, а также уже есть тестировщики. Но такие места хороши при расширении штата. Если же текучка кадров - это тоже вызывает вопросы.