Метрики. Часть 3.
Метрики выполнения тестов.
На мой взгляд самые простые #метрики, которые реально помогают понять ситуацию с качеством приложения и качеством самих тестов.
1. Количество пройденных тестов/ отношение к общему количеству тестов (#Pass#rate)
Я обычно пользуюсь именно относительной величиной, потому что количество само по себе в отрыве дает меньше информации. Можно и даже нужно использовать в #автоматизации тестирования, то есть для авто тестов.
В целом эта метрика уже давно стала золотым стандартом метрик: узнать качество сборки - pass rate, проверить состояние приложения - pass rate, проверить стабильность энвов после переезда на новый клауд - #passrate. А на исторических данных можно понимать какие изменения и к чему привели. Выкатили новую фичу с новыми тестам и pass rate упал на 10% - толи фича "сыровата", толи сломали смежную функциональность. Увеличился pass rate после спринта стабилизации (#Stabilization #sprint) - команда отработала хорошо по багфиксу да и тесты мы сами подлатали.
2. Количество проваленных тестов/ отношение к общему количеству.
По сути та же метрика, что и в пункте 1, только в реверсивном или негативном(хз как правильно) отображении, то есть наоборот. Используется так же, показывает тоже, только анализ идет от обратного, как и выводы.
3. Среднее время выполнения теста (#average #speed)
Вот эту годноту использую почти всегда. Из нее обычно можно вывести 2 вещи: неоптимальность написанных тестов, то есть простор для улучшения, избавление от лишнего, запутанное описание степов и т.п., а также скорость работы. Вы можете спросить "чья скорость работы?" и будете правы. Таких объектов или субъектов (расскажите, кто шарит как правильно в комментариях) несколько:
a. Скорость работы автотестов - тут все просто, чем быстрее проходят, тем лучше + больше денег экономим на тестировщиках.
б. Скорость работы приложения - вкорячили очень долгий запутанный кол с кучей вызовов под капотом - позор разработчикам и архитекторам.
в. Скорость работы окружения - переехали в новый клауд, открыли новый энв, запилили новую реализацию балансировщика - наши клиенты.
г. Скорость работы каждого отдельно взятого тестировщика - самый спорный пункт, я предпочитаю мерить общими задачами в бэклоге, хотя можно и по этой метрике, но тут будет куча погрешностей из-за пунктов выше + часто #тестировщик не только "прогоняет" #тесты, но и улучшает, и обновляет их в процессе, что очень сильно затрудняет качественную оценку по этой метрике.
October 11, 2024 292 3
