Метрики тестирования

Мы все утопаем в океане данных, но при этом,

очень редко можем получить необходимую информацию.

(С) Э. Голдратт
10-го июня прошел очередной онлайн тренинг по метрикам тестирования программного обеспечения. Это один из модулей большого  тренинга «Ключевые процессы, метрики и артефакты тестирования».  Материал достаточно сложный. И вопрос даже не столько в опыте участников сколько в знакомстве с теорией ограничений.

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

Для этого попробуйте или решить задачу из книги Голдратта «Синдром стога сена» (книга очень полезна в частности там объясняется разница между данными и информацией и поднимается проблема информационного шума), или возьмите задачу попроще про заборостроителей. Или если хотите пример из нашей индустрии, то объясните, почему диаграмма роста стоимости исправления дефекта в зависимости от стадии разработки неверно. Да, да, несмотря на то, что это диаграмма до сих пор кочует  из статьи статью, из книги в книгу она является неверной.  Если вы прекрасно разбирайтесь в теории ограничений, то сможете дать ответ практически мгновенно. Проверьте ваши силы!

costtofixbug.gif

Картинка из книги 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. Лайфхак. Сначала надо определить метрики процесса разработки ПО в целом и только затем выявлять метрики отдельных процессов. Если этого не сделать будет вот так:
3.PNG
На мыслесхеме в архиве этого не сделано, и это очень серьезная ошибка.
metrics.zip

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.