Как оценить работу тестировщика?

Всем привет, меня зовут Света Филиппова ( ex 1бит, ex aliexpress, ex sberdevices). Так же являюсь лидом и ментором тестирования на платформе практики Pointpulse.

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

Именно тестировщики не знают как посчитать свой труд. С разработкой более или менее понятно, а с тестированием не понятно. “Я тестировал, я помогал разработчикам, я ходил на дейлики, написал 80 автотестов, 400 тест-кейсов и завел миллион баг-репортов”. Говорят ли эти цифры о хорошей работе? А о плохой? А нужны ли были эти автотесты? С другой стороны к лидам регулярно приходит начальство и говорит, что надо бы померять тестирование, понять нужно ли оно вообще.

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

Бизнесу не важно сколько заведено баг-репортов или написано кейсов, бизнесу важно, чтобы продукт приносил прибыль и не простаивал. Поэтому самый первый слой метрик будет денежные метрики.

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

Для этого можно взять пул метрик, связанный со сбоями в продукте:

— компенсации и возвраты

— рост нагрузки на поддержку

— переработки инженеров и ночные выезды

— простои сервисов и недополученная выручка

— репутационные потери (хуже конверсия, рейтинг приложения, отток).

Если мы не можем подсчитать сколько денег уходит на простои, то всегда можно договорится о каких-то усредненных показателях: час работы поддержки стоит 1000 рублей или простой этого сервиса обходится в 1000 рублей/ час. Это нужно для того, чтобы потом, в будущем вы могли сравнить результаты с того момента как вы начали считать с текущими.

Можно уточнить и перейти к обсчету основных сценариев, тогда он будет выглядеть так:— доля ошибок/инцидентов именно на ключевых путях

— время восстановления (MTTR) по критичным путям

— частота hotfix/rollback из-за поломок в ключевых сценариях

Этими метриками хорошо мерять релизы, тогда становится понятно, принес релиз пользу или вред, что было с тестированием и знали ли мы о таких рисках.Если бизнесовые метрики отвечают на вопрос “нам больно или нет”, то командные отвечают на вопрос “где именно больно и что чинить”. Для этого нам надо спуститься на уровень ниже и посчитать во-первых наш базовый набор:— число инцидентов по severity

— частота ошибок/крашей

— SLO/SLA нарушения

— дефекты, найденные пользователями (escaped defects)

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