Результаты и метрики автоматизации тестирования

Результаты и метрики автоматизации тестирования

Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс

Всем привет. Каждая метрика в автоматизации тестирования должна удовлетворять следующим критериям:

  • измеримость;
  • объективность;
  • основаны на данных, которые легко доступны;
  • осмысленность;
  • простота;
  • может помочь найти направления для улучшения и совершенствования процесса автоматизации.

1) Процент автоматизируемых тестов (кейсов).
Не всё нужно и не всё возможно автоматизировать. Имея список тест кейсов, которые хотелось бы автоматизировать, – логично узнать соотношение (умножение на 100 буду упускать):

PA(%) = количество кейсов, которые могут быть автоматизированы / общее количество кейсов

2) Продвижение автоматизации.

TP = количество заавтоматизированных кейсов / промежуток времени, за которое были написаны тесты

Подходящая метрика для определения производительности и оценок сроков на тестовое покрытие. Если она резко взлетает или резко падает, стоит задаться вопросами. В первом случае — возможно и скорее всего, создаётся видимость работы как результат сильного дробления проверок, что тоже не очень хорошо. Во втором — возможно в автоматизатора упала мотивация или происходят постоянные ошибки с естимацией работ.

3) Продвижение автоматизации.

AP(%) = количество автоматизированных кейсов / количество кейсов, которые могут быть автоматизированы.

Данная метрика очень важна при рассмотрении процесса автоматизации в отрезке времени. Если с каждой новой итерацией процент продвижения падает, стоит задуматься о том, почему такое происходит — пересмотреть архитектуру, возможности, взгляды, и даже добавить при необходимости людей в команду и т.д. Конечно, здесь нужно стремится к 100%

4) Плотность дефектов (багов).

TC(%)= количество открытых багов/ общий размер приложения

Очень важная метрика, которой пренебрегают ввиду отсутствия подходящей возможности оценить, что такое размер тестируемого приложения. Есть стандартное представление о том, что в среднем на три строчки кода приходится по одному багу. По мне так это самый настоящий бред, а если это и так, то никакое тестирование такому проекту уже не поможет :) В общем, при использовании Scrum методологии можно в качестве этого самого размера приложения просуммировать все story points, — если найденных багов мало, нормируйте формулу. Это очень полезная метрика как в самой команде, так и снаружи, — особенно когда продукт на стадии релиза. А вообще Agile автоматизация — это отдельная тема. Можете почитать про неё перейдя по ссылке.

5) Покрытие.

TC(%)= количество заавтоматизированных кейсов/ количество требований

Сложная, но полезная метрика, когда речь идёт об оценке глубины покрытия. Наверное, лучше даже  брать обратную пропорцию в качестве процента… Если грамотно её использовать, например, фича-тесты в Agile методологии, то можно не только прикинуть сколько накопится тестов через несколько недель/месяцев, но и понять, что пришло время к оптимизации для сокращения времени прогона автотестов.

6) Эффективность устранения дефектов.

DRE(%)= баги, найденные во время тестирования / (баги, найденные в процессе тестирования + баги, найденные пользователями в production)

Довольно важная метрика, без которой никуда. Если в результате прогона автотестов мы имеем, допустим, 10 багов, исправляем их, а после выкатывания пользователям мы замечаем ещё 10 новых, то это печально — значит не следили за метриками выше. Получив это процентное соотношение, надо как можно быстрее поднять его до 100%. таким образом, эту метрику нужно рассматривать во времени после деплоймента. Автотесты на вновь возникшие баги должны быть написаны немедленно и должны падать, а не проходить :)

Как вывод, хочу подчеркнуть, что не нужно придумывать метрики для менеджеров и заказчиков. Они нужны в первую очередь для вас, – автоматизаторов. Старайтесь уметь объяснять не только себе, но и другим, как происходит улучшение процесса автоматизации тестирования. Показывайте и объясняйте, что дают те или иные технологии, по сравнению с другими. Формулируйте это в цифрах, понятных тем, кто не разбирается в автоматизации.

Сейчас много компании, у которых, чем хуже качество, тем лучше, потому что они живут договорами на тех-поддержку и зарабатывают большие деньги на том, что у клиентов нет никаких других альтернатив. Этим компаниям автоматизация тестирования не нужна, не нужны и сами метрики. Поэтому, эта статья направлена на все другие компании, которые в конкурентной борьбе пытаются заслужить лояльность и деньги своих заказчиков.

И запомните, даже в наше каменное постсоветском время в сфере IT,- ничто не остановит автоматизацию!

qa_testing

 

Связанные статьи