Про метрики
«С этого дня мы оцениваем качество QA-команды по количеству заведенных дефектов»
Сказано — сделано. Дефект на каждый «чих», договорные дефекты, тестирование простых, но «плодовитых» сценариев и т.д.
ЧуднЫх метрик и KPI можно встретить сколько угодно. Откуда они берутся? Хм... Если кто-то знает волшебный «горшочек», который все никак не перестанет варить, welcome в комментарии.
Ниже несколько рекомендаций о том, какими они должны быть, с небольшим отсылом к KPI:
— Бесцельная метрика вредна. Зачем она нужна? На какой вопрос она дает ответ? Какую проблему позволяет решить? Метрика должна стать источником инсайтов по мере продвижения к цели.
— Смотрите на взаимосвязь между метриками или вводите разные метрики для оценки одного показателя. Связана ли скорость поставки с уровнем покрытия unit-тестами? Связано ли количество переоткрытых дефектов с количеством регрессионных тестов ;) ?
— Метрики должны стать источником знаний, помогать учиться. «The only way to win is to learn faster than anyone else» (с) Lean Startup
— Делите по когортам. Это крутой источник инсайтов для адаптации. В одной когорте может быть спад, в другой рост, общая картина — без перемен.
— Не верьте слепо цифрам. Если KPI команды считается по кличеству дефектов, оно будет ровно таким, каким должно быть по KPI. «Над проектом должны работать мотивированные профессионалы.». Профессионалы найдут выход :)
— Простой способ — лучший способ. Правильно поставленные вопросы и подходящие практики на совместной командной встрече позволяют очень точно определить качество, уровень технического долга, препятствия к снижению time-to-market и т.д. Через сложные метрики пытались предсказать биржевое поведение и ипотечный кризис.
— Метрики в идеале должны быть визульно понятными и human-friendly. Светофор в DevOps понятен всем (метрика — отношение красных и зеленых). Звук падающей в копилку монетки при регистрации нового клиента понятен всем. Количество строк, покрытых тестами остается количеством строк покрытых тестами (чего мы хотим? удалить непокрытый код как неиспользуемый? допокрыть весь код? зачем? надо четко понимать)
— Прозрачность (открытость) метрик. Каждому по пониманию: как считается, что считается, зачем считается и кого за это благодарить :)
— Эксперименты и непрерывное улучшение. Не подошла одна, берем другую. Подкручиваем, пробуем иначе отобразить и т.д. Нет целостной картины? Добавим, закроем белое пятно. Несколько месяцев не используем? Выбросить, на кой излишняя сложность.
И в завершение: что нельзя измерить, нельзя улучшить. Полезных метрик всем!
«С этого дня мы оцениваем качество QA-команды по количеству заведенных дефектов»
Сказано — сделано. Дефект на каждый «чих», договорные дефекты, тестирование простых, но «плодовитых» сценариев и т.д.
ЧуднЫх метрик и KPI можно встретить сколько угодно. Откуда они берутся? Хм... Если кто-то знает волшебный «горшочек», который все никак не перестанет варить, welcome в комментарии.
Ниже несколько рекомендаций о том, какими они должны быть, с небольшим отсылом к KPI:
— Бесцельная метрика вредна. Зачем она нужна? На какой вопрос она дает ответ? Какую проблему позволяет решить? Метрика должна стать источником инсайтов по мере продвижения к цели.
— Смотрите на взаимосвязь между метриками или вводите разные метрики для оценки одного показателя. Связана ли скорость поставки с уровнем покрытия unit-тестами? Связано ли количество переоткрытых дефектов с количеством регрессионных тестов ;) ?
— Метрики должны стать источником знаний, помогать учиться. «The only way to win is to learn faster than anyone else» (с) Lean Startup
— Делите по когортам. Это крутой источник инсайтов для адаптации. В одной когорте может быть спад, в другой рост, общая картина — без перемен.
— Не верьте слепо цифрам. Если KPI команды считается по кличеству дефектов, оно будет ровно таким, каким должно быть по KPI. «Над проектом должны работать мотивированные профессионалы.». Профессионалы найдут выход :)
— Простой способ — лучший способ. Правильно поставленные вопросы и подходящие практики на совместной командной встрече позволяют очень точно определить качество, уровень технического долга, препятствия к снижению time-to-market и т.д. Через сложные метрики пытались предсказать биржевое поведение и ипотечный кризис.
— Метрики в идеале должны быть визульно понятными и human-friendly. Светофор в DevOps понятен всем (метрика — отношение красных и зеленых). Звук падающей в копилку монетки при регистрации нового клиента понятен всем. Количество строк, покрытых тестами остается количеством строк покрытых тестами (чего мы хотим? удалить непокрытый код как неиспользуемый? допокрыть весь код? зачем? надо четко понимать)
— Прозрачность (открытость) метрик. Каждому по пониманию: как считается, что считается, зачем считается и кого за это благодарить :)
— Эксперименты и непрерывное улучшение. Не подошла одна, берем другую. Подкручиваем, пробуем иначе отобразить и т.д. Нет целостной картины? Добавим, закроем белое пятно. Несколько месяцев не используем? Выбросить, на кой излишняя сложность.
И в завершение: что нельзя измерить, нельзя улучшить. Полезных метрик всем!