В борьбе за качество никак не обойтись без оценки...
Сейчас мы находимся в стадии определения метрик.
Метрики планируется снимать после каждого релиза.
Примерный перечень метрик:
- общее кол-во релизных задач
- общее кол-во автотестов
- кол-во TоDo автотестов (которые запланированы с прошлых релизов, но из-за нехватки времени не реализованы)
- кол-во новых реализованных автотестов
- качество тестового покрытия
- глубина тестового покрытия
- кол-во тестов failed
- кол-во тестовых документов
- кол-во новых тестовых документов
- баги на демо (+критичность)
- пропущенные баги - которые всплыли после релиза (+критичность)
- кол-во хотфиксов
- кол-во открытых багов в текущем релизе (+критичность)
- кол-во закрытых багов в текущем релизе
- общее кол-во открытых багов
- качество новой функциональности на момент первичного тестирования
Столкнулись с массой проблем...
Если с тестами и тестовой документацией как -то более или менее все понятно, то вот с остальным придется повозиться..
Проблемы следующие:
- несколько проектов, с разрозненным выпуском релизов, зачастую релиз выпускается позже обозначенного срока (в багтрекере об этом нет информации)
- Про баги на демо можно узнавать несколькими путями:
- попросить ПМ-а сообщать о багах
- попросить тестировщика сообщать о багах (менее интересный вариант)
- посещать демо и отмечать самостоятельно(отнимает массу времени, да и хочется как то автоматизировать этот процесс)
- знать точную дату демо и мониторить ошибки созданные ПМ-ом (заранее договориться что эти баги будет создавать только он и к тому же в отдельных подзадачах - ошибках)
Последний вариант наиболее приемлим, но требует изменения некоторых устояшихся процессов - Про пропущенные баги - аналогично - нужно договориться что заводит их только ПМ и привязывает к задаче с которой они связаны. Так же ввести дополнительный тип задачи - пропущенный баг
- Качество новой функциональности на момент первичного тестирования будет определять тестировщик по 5(10) бальной шкале. Нужно стремиться к тому чтобы на тестирование попадала задача хотя бы без блокировок, чтоб ускорить и облегчить процесс тестирования
- Качество и глубину тестового покрытия будет оценивать руководитель группы тестирования - показатель будет относительный (например если провели оптимизацию ставим к качеству+10), если увеличили кол-во тестовых сценариев ставим +20 к глубине. Текущее качество и глубину оценивать не вижу смысла. На данном этапе возможно ввести такой показатель как достаточность или недостаточность тестового сценария
- С fail-овыми тестами вообще отдельная тема для статьи. Нужно постоянно анализировать причины fail-ов, и по возможности оптимизировать.
- Ну и наконец как собирать всю эту информацию?? Источники абсолютно разные, а хотелось бы получать сразу готовую табличку, а еще лучше бы графики, диаграммы...
- Организация баг-треккинга немножко отличается между проектами - например а некоторых проектах просто -напросто все баги падают в папку багз, а в другой создаются в текущей релизной версии
- Метрики хочется снимать именно раз в релиз (релизы ориентировочно раз в 2 недели) т.к. хочется проводить сравнительный анализ по покрытию новых задач тестовой документацией и автотестами.
В качестве результатов хотелось бы видеть следующие графики:
- график багов по резолюциям
- график соотношения отрытых багов к общему кол-ву
- график соотношения закрытых багов в общему кол-ву
- график распределения багов по критичности
Еще особое внимание хочется уделить багам которые ПМ/тестировщик обнаружил, занес в багтрекер, но по каким -либо причинам они не были исправлены.
Зачастую такие баги приходят в фидбеке
