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