Метрики тестирования
(Из ленты 255 ступеней)
10-го июня прошел очередной онлайн тренинг по метрикам тестирования программного обеспечения. Это один из модулей большого тренинга «Ключевые процессы, метрики и артефакты тестирования». Материал достаточно сложный. И вопрос даже не столько в опыте участников сколько в знакомстве с теорией ограничений.
И перед тем как вы приступите к чтению статьи, предлагаю оценить свои знания в теории ограничений.
Для этого попробуйте или решить задачу из книги Голдратта «синдром стога сена» (книга очень полезна в частности там объясняется разница между данными и информацией и поднимается проблема информационного шума), или возьмите задачу попроще про заборостроителей. Или если хотите пример из нашей индустрии, то объясните, почему диаграмма роста стоимости исправления дефекта в зависимости от стадии разработки неверно. Да, да, несмотря на то, что это диаграмма до сих пор кочует из статьи статью, из книги в книгу она является неверной. Если вы прекрасно разбирайтесь в теории ограничений, то сможете дать ответ практически мгновенно. Проверьте ваши силы!
Картинка из книги Lee Copeland
Подсказка. Решение дается в книге «Цель», эпизод с посещением Ионой завода Алекса.
В начале семинара участники накидали список метрик, которые в принципе можно измерять. Как было показано дальше, это путь в никуда. А вот и сам список (список писался в режиме генерации идей мозгового штурма, так что не удивляйтесь «потоку сознания».):
1. Количество найденных багов
— В целом
— По времени
— На пользователя
— Только критичные для функциональности ПО
2. Количество репортов от заказчика / клиента
3. Время, затрачиваемое на тестирование очередной поставки
4. Количество тестов которые прошли успешно или не успешно
5. Проценты покрытия кода ( “Что можно получить от отслеживания данного показателя?”)
6. Процент покрытия требований тестами
7. Количество найденных тестировщиком багов
— за единицу времени
— за N срок кода
8. Количество отказов ПО за период времени
9. Количество элементов, которые тестировщик поклацал (покрыл ручным тестированием) 
10. Количество повторно открытых задач на тестирование
10.1. “Это не бага, а фича”
Тезисы тренинга:
- Метрик тестирования, точно также как и метрик финансового состояния фирмы мало.Если у вас много метрик, то вы просто утоните в информационном шуме и будете неспособны принимать правильные управленческие решения (смотри «Синдром стога сена»). Метрик должно быть мало (полагаю, до полудюжины). Если вы измеряете много метрик – вы ошиблись в логических построениях.
- Метрики должны быть оттрассированы на финансовые показатели. Все, что не оттрассировано на финнпоказатели – информационный шлак.
- При выведении набора метрик нужно начинать с цели фирмы. Попытки начать с самих метрик это как запрягать лошадь позади телеги – путь в никуда. Последовательность создания мыслекарты (мыслесхемы) лучше всего изучать по книге «Цель» Годратта. Вообще, без понимания теории ограничений эти метрики определить очень сложно, если вообще возможно.
- Для всех проектов по созданию ПО метрики тестирования одинаковы. Если у вас получилось, что они неодинаковы, вы где-то ошиблись в выкладках. Так же эти метрики одинаковы как для ручного, так и для автоматизированного тестирования. Так же эти метрики одинаковы для REST автоматизации тестирования, для Unit тестирования, для автоматизации тестирования при помощи Selenium, Appium, Testcomplete и т.д. и т.п. Если вы получили разные метрики – вы ошиблись в логических построениях.
- Когда вы считаете ROI для изменения процесса, любого процесса, в том числе и перехода от ручного тестирования к автоматизированному вы должны измерять ровно те же самые метрики. И, внезапно! автоматизацию процессов рабочего центра тестирования не надо начинать с автоматизации процесса поиска дефектов. И уж тем более не надо начинать с автоматизации регрессионного тестирования. Когда у вас будет хороший набор метрик, этот тезис станет достаточно очевиден.
В ходе вебинара участники познакомились с лучшим инструментом для построения мыслесхем FlyingLogic. И поскольку это был именно тренинг, а не доклад, мыслесхему участники строили сами. Я могу нарисовать правильную схему. Но тогда она не ляжет «на кончики пальцев» у участников. Схема недоделана. Она неполна, кое-где классы указаны неверно, есть дубликаты, группировка сделана плохо. Схему еще пилить и пилить. Так что если кто-то хочет попробовать свои силы – ставьте FlyingLogic, распаковывайте архив и вперед, «Через тернии к звездам». Да пребудет с вами сила!
Для тех, кто хочет просто посмотреть результат, сделан экспорт в png.
PS. Перед загрузкой мыслесхемы не забудьте загрузить домен: Главное меню -> Domain -> Import Domain -> выбрать и загрузить Flying Logic Domain.
PSS. Лайфхак. Сначала надо определить метрики процесса разработки ПО в целом и только затем выявлять метрики отдельных процессов. Если этого не сделать будет вот так:
На мыслесхеме в архиве этого не сделано, и это очень серьезная ошибка.
metrics.zip