Доклад Антона Семенченко на конференции SQA Days-19, 20-21 мая 2016 г., Санкт-Петербург

1. Anton Semenchenko
Метрики
Автоматизированного
тестирования на пальцах

2. About 
Организатор сообществ
www.COMAQA.BY и
www.CoreHard.by,
учередитель компании
www.DPI.Solutions, «хитрый»
менеджер в EPAM Systems.
Почти 15 лет опыта в IT,
основная специализация:
Автоматизированное
тестирование, разработка на
С++ и ниже, менеджмент,
продажи.

3. Agenda, part 1 (введение)
• QA и QC
• Определение понятия метрика
• Потенциальные сложности
• Где взять данные для рассчета метрик?
• Алгоритм трансформации данных в информацию
• Источники данных для рассчета метрик
• Взаимосвязь метрик
• Светофор – метрик
• Эквалайзер - метрик
• «Пожарные» метрики

4. Agenda, part 2 (основная)
• 3 вида классификации метрик
• Классификация с точки зрения тех специалистов
• Классификация с точки зрения бизнеса
• Классификация с точки зрения менеджмента на
стороне исполнителя
• Важность классификации
• Стандартные QA Риски как вариант
классификации метрик
• 2 вида проектов
• Ниболее популярные метрики АТ
• Метрики – пожарные извещатели
• Ниболее популярные метрики общие как для
Ручного, так и для Автоматизированного
тестирования
• Метрики личной эффективности

5. Agenda, part 3 (заключение)
• «Увлекательные» истории
• “Актуальность” информации
• “Источники” информации
• “Take away” points
• Что дальше?
• «Внеклассное чтение»

6. QA и QC
• Контроль качества (QC) — это измерение
параметров качества продукта
• Обеспечение качества (QA) – это измерение и
управление качеством процесса (включая
метрики), который используется для создания
качества продукта (или качественного продукта).

7. Метрика
• Метрика программного обеспечения — мера,
позволяющая получить численное значение
некоторого свойства программного
обеспечения или его спецификаций.
• Метрика – как механизм обратной связи
• Том ДеМарко, «вы не можете контролировать
то, что не можете измерить».

8. Потенциальные сложности
• Что такое качество тестирования?
• Не тривиальный вопрос, очень комплексное
понятие.
• Успеваем ли мы уложиться в проектные
ограничения?
• Дата Релиза
• Бюджет

9. Потенциальные сложности
• Как можно улучшить процесс тестирования и
разработки ПО в целом?
• Успешна ли АТ, текущий статус АТ, не
отклонились ли мы от намеченной траектории
• И многие другие

10. Где взять данные?
• Этот вопрос регулярно задают не только
молодые, но и опытные специалисты. Пример:
фактически, значимая часть панельной дискусии
на конференции CodeFest 2016, посвященная
метрикам тестирования, была сфокусирована на
вопросе «Где взять данные?»

11. Трансформация
• Трансформация:
• Данные
• =>
• Информация (фильтрация данных)
• =>
• Визуализация информации (сложение,
вычитание, деление)
• =>
• Работа с «Трендом»
• Примеры:
• Биржа
• Любой BigData проект

12. Где взять данные?
• Test Plan
• Test Reports
• Continues Integration (CI)
• Bug Tracking Systems
• Task Tracking Systems
• Test Management Systems (TMS)
• Test Strategy
• Другие источники

13. Взаимосвязь метрик

14. Светофор - метрик
• Светофор – как способ максимально быстро
получить актуальную высокоуровневую
информацию о проекте. Многие метрики можно и
нужно использовать в стиле «светофор».
• Красный – надо срочно обратить детальное
внимание
• Желтый – в зависимости от загруженности, либо
обратить поверхностное внимание лично, либо
дерелировать эту активность
• Зеленый – не требует вмешательствавнимания

15. Эквалайзер - метрик
• The power of music (Metrics )

16. «Пожарные» метрики

17. «Пожарные» метрики
• Если процесс разработки и тестирования ПО
налажен – вероятность того, что проект будет
успешно реализован приемлемо высока.
• Если же процесс разработки и тестирования ПО
не эффективен – что бы мы ни делали, какими бы
замечательными отдельные показатели не были,
проект прочти наверняка «провалится».
• «Пожарные» метрики + принцип светофора +
принцип эквалайзера – дают гарантию того, что
процесс разработки приемлемо высокого
качества.

18. Классификация (IT stuff)
• Классификация по «областям»
• Качество Продукта (Quality)
• Прогресс той или иной активности в
тестировании (Progress)
• Покрытие (Coverage)
• Цена / время (Cost / time)
• Процесс обеспечения качества и разработки в
целом (Process)

19. Классификация (Business)
• Классификация «Что должно быть
исправлено в первую очередь»
• Качество Продукта (Quality)
• Время тестирования продукта / впуска продукта
(Time)
• Стоимость тестирования продукта (Costs/efforts)
• Прозрачность тестирования продукта (Testing
visibility)
• Автоматизация тестирования (Test automation
approach)

20. К-я менеджмента
• Классификация менеджмента
• Метрики – пожарные извещатели
• Все остальные метрики

21. 3 варианта классификации?
• Классификация с точки зрения технического
специалиста / исполнителя
• Классификация с точки зрения заказчика
• Классификация с точки зрения менеджмента
• Любая классификация не идеальна и
рассматривает «поблемную» область под
определенным углом зрения
• Метрика – инструмент
• А классификация – инструмент для эффективной
работы с инструментом-метрикой

22. Важность классификации

23. 2 вида проектов?
• Outsourcing
• Own product development

24. Метрики АТ
• Процент тестов, поддающихся автоматизации
(ППА)
• Прогресс автоматизации (ПА)
• Процент покрытия автоматизированными
тестами (ПП АТ)
• Частота проведения регрессии (ЧР)
• Стабильность Автоматизированных Тестов (САТ)
• Колличество дефектов, на Автоматизированный
Тест (ДАТ)

25. Метрики АТ
• Окно автоматизации тестирования
• Окно анализа результатов тестирования
• Время на создание автоматизированного теста
• Время на поддержку автоматизированного теста
• Экономическая целесообразность АТ (ROI)

26. % т, поддающихся А (ППА)
• Определение
• Процент тестов, поддающихся автоматизации
= # тест кейсов которые можно
автоматизировать (ПА) / # общее количество
тест кейсов (ОТК)
• «Физический смысл»
• Отражает адаптированность приложения к
автоматизированному тестированию с точки
зрения технологий и архитектуры

27. % т, поддающихся А (ППА)
• Границы
• Для большинства относительно новых
приложений этот параметр, как правило,
превышает 90%
• Где взять информацию
• Информация получается на базе тест-плана и
экспертной оценки

28. % т, поддающихся А (ППА)
• Примеры
• Mature Data Protection Solution, new SQL Denali
plug-in, close to 100%;
• Mature Secure VPN (Russian), технологический
стек;
• Социальные сети (Facebook, Bamboo), CMS,
шаблоны для CMS - до появления средств
автоматизации визуального тестирования
процент автоматизируемых тестов был
относительно невысок;
• MS и Google;

29. % т, поддающихся А (ППА)
• Визуализация
• Более 90% - зеленый цвет
• От 70% до 90% - желтый цвет
• Менее 70% - красный цвет
• Связь с другими метриками
• Прогресс автоматизации (ПА)
• Процент покрытия автоматизированными
тестами (ПП АТ)
• Категория:
• Качество
• Автоматизация тестирования

30. Прогресс А (ПА)
• Определение
• Прогресс автоматизации (ПА) = # количество
автоматизированных на данный момент тест
кейсов (АТК) / # общее количество тест кейсов
автоматизации (ОАТК)
• «Физический смысл»
• Отражение статуса во времени для понимания
достижимости или недостижимости
поставленных целей
• Как много тест кейсов команда покрыла
Автоматизацией в течении последней
итерации (Sprint, Release)? Способ убедиться в
том, что текущий прогресс позволяет достичь
намеченных целей до Deadline-а

31. Прогресс А (ПА)
• Границы
• Границы: 0 – 100%
• Где взять информацию
• Test Plan
• Test Reports
• Continues Integration (CI)
• Test Management Systems (TMS)

32. Прогресс А (ПА)
• Примеры
• Mature Secure VPN (Russian), технологический
стек;

33. Прогресс А (ПА)
• Визуализация
• Круговая диаграмма (2 типа):
• Общее колличество запланированных для
Автоматизации тестов к уже реализованным
• Общее колличество запланированных часов к
уже использованному

34. Прогресс А (ПА)
• Связь с другими метриками
• Процент покрытия автоматизированными
тестами (ПП АТ);
• Колличество найденных дефектов на
Автоматизированный тест;
• Окно Автоматизации Тестирования;
• Окно Анализа результатов;
• Экономическая целесообразность АТ (ROI);
• Категория:
• Прогресс
• Автоматизация тестирования

35. % покрытия АТ (coverage)
• Определение
• Процент покрытия автоматизированными
тестами (ПП АТ) = Покрытие
автоматизированными тестами (ПАТ) / Общее
покрытие (ОП) (KLOC, FP, etc.)
• Метрику можно «интерпретировать» очень по-
разному

36. % покрытия АТ (ПП АТ)
• «Физический смысл»
• Данная метрика помогает выявить, насколько
«эффективна» / «разумна» автоматизация.
• Выявить, какие тесты стоит
Автоматизировать в первую очередь
(например, начать со Smoke и Regression, если
эти тест кейсы достаточно формализованы) и
сравнить с текущим покрытием
(подразумевается что АТ запускаются
регулярно и выявляют дефекты).
• Удостовериться, в том, что
Автоматизированные тесты проверяют
именно то, что должны проверять.

37. % покрытия АТ (ПП АТ)
• Границы
• Границы: 0 – 100%
• Где взять информацию
• Test Reports
• Continues Integration (CI)
• Test Management Systems (TMS)

38. % покрытия АТ (ПП АТ)
• Примеры
• Mature Data Protection Solution, new SQL Denali
plug-in, close to 100%;
• MS and Windows Millennium
• Data Protection Giant and Automation

39. % покрытия АТ (ПП АТ)
• Визуализация
• Термин test coverage matrix и traceability matrix
взаимозаменяемы в большинстве случаев
• Karen Johnson's использовать trace matrix как
индикатор test coverage.
• Связь с другими метриками
• Процент покрытия автоматизированными
тестами (ПП АТ);
• Прогресс Автоматизации
• Категория:
• Покрытие
• Автоматизация тестирования

40. Частота регрессии (ЧР)
• Определение
• Частота проведения регрессии (ЧР) = Как
часто проводится автоматизированная
регрессия?
• «Физический смысл»
• Чем выше частота использования продукта,
тем выше его ценность. Это касается и
автоматизированных тестов, чем выше
частота регрессии, а соответственно и
частота прогонов автотестов, тем выше их
ценность для заказчика. Таким образом данная
метрика является одной из ключевых при
оценке ROI автоматизации тестирования.

41. Частота регрессии (ЧР)
• Границы
• Широкораспространенные границы /
рекомендации:
o smoke - каждую ночь
o full-regression - каждые выходные
• Где взять информацию
• Automation reports
• Continuous Integration (CI)

42. Частота регрессии (ЧР)
• Примеры
• ЧР и Экономическая целесообразность АТ (ROI);
• Facebook и Bamboo
• Kanban, ЧР, опыт WG
• Доведенные до «абсолюта» «рекоммендации»
• «Окно commit-а»

43. Частота регрессии (ЧР)
• Визуализация
• Не реже чем 1 раз в неделю - зеленый цвет
• Не реже чем 1 раз в 2 недели - желтый цвет
• Реже чем 1 раз в месяц - красный цвет
• Чаще чем раз в день - красный цвет
• Связь с другими метриками
• Экономическая целесообразность АТ (ROI);
• Окно автоматизации тестирования;
• Окно анализа результатов тестирования;
• “Окно commit-а“
• Категория:
• Качество
• Автоматизация тестирования

44. Стабильность АТ
• Определение
• Стабильность Автоматизированных тестов =
процент тестов, которые либо успешно
проходят либо падают, по причине нахождения
дефекта
• «Физический смысл»
• Отражает качество автотестов и
соответствие их текущему состоянию
тестируемой системы

45. Стабильность АТ
• Границы
• Цель – процент «случайных» падений не
превышает 5%
• Где взять информацию
• Test Reports

46. Стабильность АТ
• Примеры
• Множество проектов;
• Стандартная «проблема» при работе с middle+
специалистами по Автоматизированному
тестированию «старой формации»

47. Стабильность АТ
• Визуализация
• Более 95% - зеленый цвет
• Более 90%, менее 95% - желтый цвет
• Менее 90% - красный цвет
• Связь с другими метриками
• Колличество дефектов на
Автоматизированный тест
• Категория:
• Качество / Процесс
• Автоматизация тестирования

48. # дефектов на АТ
• Определение
• Колличество дефектов на
Автоматизированный Тест = ведется подсчет
дефектов, как Автоматизированных, так и
Ручных;
• Если Автоматизированное тестирование не
находит дефектов или лишь незначительное
колличество дефектов, то:
• Выделить области Автоматизации для
улучшения;
• Репреоретизировать усилия в Автоматизации;
• Отказаться от Автоматизации;

49. # дефектов на АТ
• «Физический смысл»
• Отражает эффективность автотестов с
точки зрения нахождения дефектов
• Границы
• Отсутствие найденных дефектов может
являться индикатором неудачного фокуса
автотестов
• Где взять информацию
• Test Reports

50. # дефектов на АТ
• Примеры
• Множество проектов;
• Стандартная «проблема» Автоматизации ради
Автоматизации
• Стандартная «проблема» получения прибыли
исполнителем в ущерб заказчику

51. # дефектов на АТ
• Визуализация
• Более 5% (минимальный процент зависит от
фазы и деталей проекта) - зеленый цвет
• От 1 до 5% - желтый цвет
• Менее 1% - красный цвет
• Связь с другими метриками
• Стабильность Автоматизированных тестов
• Категория:
• Качество / Процесс
• Автоматизация тестирования

52. «Окно» АТ
• Определение
• «Окно» Автоматизированного тестирования –
как много физического времени занимает
прогон Автоматизированных тестов (полное
или подмножество)
• «Окно» Автоматизированного тестирования –
как много системного «лабороторного»
времени занимает прогон
Автоматизированных тестов (полное или
подмножество)

53. «Окно» АТ
• «Физический смысл»
• Время, требуемое для прогона автотестов
необходимо учитывать при оценке
экономической эффективности
автоматизации, при анализе ROI и сравнении с
ручным тестированием. Метрика необходима
как при принятии решения о целесообразности
внедрения автоматизации, так и при оценке
текущего состояния уже реализованной
автоматизации с целью выявления узких мест.

54. «Окно» АТ
• Границы
• В зависимости от размера проекта может
занимать от нескольких до многих часов. Как
правило, Smoke после commit-а должен
занимать не более часа, полная Регрессия не
более двух дней (выходные)
• Где взять информацию
• Test Reports
• Continuous Integration (CI)

55. «Окно» АТ
• Примеры
• Социальные сети (Facebook, Bamboo), CMS,
шаблоны для CMS - до появления средств
автоматизации визуального тестирования
процент автоматизируемых тестов был
относительно невысок;
• Контр пример – физическое время
• Контр пример – машинное время (Claud)
• Технические детали: Stateless и Statefull
Автоматизация, параллельный запуск
• Технические детали: Эффективные ожидания
• Технические детали: Преждевременная
оптимизация

56. «Окно» АТ
• Визуализация
• Smoke <= 1 час, Full Regression <= 12 часов
(ночь) - зеленый цвет
• Smoke <= 2 часа, Full Regression <= 2 дня
(выходные) - желтый цвет
• Smoke > 2 часа, Full Regression > 2 дня
(выходные) - красный цвет

57. «Окно» АТ
• Связь с другими метриками
• Прогресс автоматизации
• Процент покрытия автоматизированными
тестами
• Частота проведения регрессии
• Стабильность Автоматизированных Тестов
• «Окно» анализа результатов тестирования
• Категория:
• Цена / Время
• Автоматизация тестирования

58. «Окно» анализа р-тов АТ
• Определение
• «Окно» анализа результатов
Автоматизированного Тестирования = Сколько
времени требуется чтобы проанализировать
полученные данные?
• «Физический смысл»
• Метрика показывает, насколько
исчерпывающими и читабильными являются
отчеты. При слишком большом окне анализа
меньше времени будет уделяться
фактическому написанию тестов, или анализ
будет проводиться недостаточно тщательно,
что обесценит value Автоматизации

59. «Окно» анализа р-тов АТ
• Границы
• В зависимости от размера проекта может
занимать от нескольких минут до многих часов.
Как правило, анализ результатов Smoke
тестов после commit - должен занимать
считанные минуты, анализ результатов
полной Регрессии – должен занимать
считанные часы, в идеале, меньше часа.
• Где взять информацию
• Test Reports
• Continuous Integration (CI)
• Task Tracking Systems

60. «Окно» анализа р-тов АТ
• Примеры
• Социальные сети (Facebook, Bamboo), CMS,
шаблоны для CMS - до появления средств
автоматизации визуального тестирования
процент автоматизируемых тестов был
относительно невысок;
• Mature Data Protection Solution, new SQL Denali
plug-in, close to 100%;
• Mature Secure VPN (Russian), технологический
стек;
• Контрпримеры

61. «Окно» анализа р-тов АТ
• Визуализация
• Smoke <= 10 минут, Full Regression <= 2 часа -
зеленый цвет
• Smoke <= 20 минут, Full Regression <= 4 часа -
желтый цвет
• Smoke > 20 минут, Full Regression > 4 часов -
красный цвет

62. «Окно» анализа р-тов АТ
• Связь с другими метриками
• Прогресс автоматизации
• Процент покрытия автоматизированными
тестами
• Частота проведения регрессии
• Стабильность Автоматизированных Тестов
• «Окно» анализа результатов тестирования
• Категория:
• Цена / Время
• Автоматизация тестирования

63. t разработки АТ-а
• Определение
• Среднее время разработки Автоматизированного
Теста = # всех автоматизированных тестов /
время на создание
• «Физический смысл»
• Информация о времени на разработку одного
теста помогает при расчете ROI, является
одним из важнейших стоимостных показателей
при внедрении автоматизации. Позволяет
оценить издержки и потенциальную прибыль
от введения автоматизации на проекте

64. t разработки АТ-а
• Границы
• Границы: 1-16 часов на тест, в зависимости от
сложности сценария, применяемых технологий
(как в разработке приложения, так и в
автоматизации), среднее время «по-больнице»
4 часа.
• Где взять информацию
• Task Tracking System

65. t разработки АТ-а
• Примеры
• Множество проектов
• Стандартная «проблема» при работе с middle+
специалистами по Автоматизированному
тестированию «старой формации»

66. t разработки АТ-а
• Визуализация
• Менее 4 часов- зеленый цвет
• Менее 8 часов, но более 4 часов - желтый цвет
• Более 8 часов - красный цвет
• Связь с другими метриками
• Время на поддержку автоматизированного
теста
• Экономическая целесообразность АТ (ROI)
• Категория:
• Цена / время
• Автоматизация тестирования

67. t поддержки АТ-а
• Определение
• Среднее время уделяемое поддержке
Автоматизированного Теста в течении указанного
периуда времени = # всех автоматизированных
тестов / время на поддержку.

68. t поддержки АТ-а
• «Физический смысл»
• Любой программный продукт при работе по
agile-методологиям особенно осклонен к
изменчивости, соответственно
адаптироваться под эту изменчивость должны
и автотесты. Время, необходимое на
доработку и адаптацию тестов, выделяется
за счет времени на разработку новых тестов,
а значит, чем выше этот показатель, тем
хуже, тем меньше времени астается на другие
активности. Высокий показатель данной
метрики может быть индикатором того, что в
автоматизации не были применены
оптимальные архитектурные паттерны или
вспомогательные программные инструменты.

69. t разработки АТ-а
• Границы
• Границы: от 0.5 часа на тест в год, до ... чуть
ли не бесконечности (заниматься тонкой
балансировкой Sleep-ов можно сколько угодно –
стабилизация так и не наступит) ... Безусловно
конкретные показатели зависят от множества
факторов – стабильности требований,
стабильности приложения, технологического
стека – как приложения, так и автоматизации,
но время не должно превышать 4 часов в
большиснтве случаев.
• Где взять информацию
• Task Tracking System

70. t разработки АТ-а
• Примеры
• Множество проектов
• Стандартная «проблема» при работе с middle+
специалистами по Автоматизированному
тестированию «старой формации»

71. t разработки АТ-а
• Визуализация
• Менее 0,5 часа на тест в год - зеленый цвет
• Не более 1 часа на тест в год - желтый цвет
• Более 2 часов на тест в год - красный цвет
• Связь с другими метриками
• Время на поддержку автоматизированного
теста
• Экономическая целесообразность АТ (ROI)
• Категория:
• Цена / время
• Автоматизация тестирования

72. ROI (out of scope, but )
• Определение
• Экономическая целесообразность
Автоматизированного Тестирования (ROI) =
Manual efforts – (Automation efforts + Automation
investment) / QA investment * 100%
• «Физический смысл»
• Указывает на то, имеет ли смысл внедрять
автоматизацию тестирования на данном
проекте в данный момент. Может оказаться,
что при определенных условиях автоматизация
тестирования окажется экономически
нецелесообразной, поскольку ручное
тестирование даже в долгосрочной
перспективе может оказаться дешевле.

73. ROI
• Границы
• Out of scope
• Где взять информацию
• Test Strategy
• Test Plan
• Test Management Systems (TMS)

74. ROI
• Примеры
• Множество проектов
• Стандартная «проблема» при работе с middle+
специалистами по Автоматизированному
тестированию «старой формации»

75. ROI (+ доп выгоды)
• Визуализация
• Сравнение трендов
• Ручное тестирование
• Целый вариант опций введения / развития
Автоматизированного тестирования
• Выбор оптимальной команды-тренда здесь и
сейчас

76. ROI
• Связь с другими метриками
• Процент тестов, поддающихся автоматизации
(ППА)
• Частота проведения регрессии (ЧР)
• Стабильность Автоматизированных Тестов
(САТ)
• Окно автоматизации тестирования
• Окно анализа результатов тестирования
• Время на создание автоматизированного
теста
• Время на поддержку автоматизированного
теста
• Категория:
• Цена / время
• Автоматизация тестирования

77. Пожарные извещатели
• Частота проведения регрессии (ЧР) - fire
• % проанализированных тестов в Test Report-е
• % ошибок / дефектов приложения
• % ошибок Автоматизации Тестирования
• % системных ошибок
• «Окно» Автоматизированного тестирования
(Время выполнения) - fire
• Окно анализа результатов тестирования - fire

78. Частота регрессии (ЧР) - fire
• Определение
• Частота проведения регрессии как пожарный
извещатель (ЧР) = Как часто проводится
автоматизированная регрессия?
• «Физический смысл»
• Чем выше частота использования продукта,
тем выше его ценность. Это касается и
автоматизированных тестов, чем выше
частота регрессии, а соответственно и
частота прогонов автотестов, тем выше их
ценность для заказчика. Таким образом данная
метрика является одной из ключевых при
оценке ROI автоматизации тестирования.

79. Частота регрессии (ЧР) - fire
• Границы
• Широкораспространенные границы /
рекомендации:
o smoke - каждую ночь
o full-regression - каждые выходные
• Где взять информацию
• Automation reports
• Continuous Integration (CI)

80. Частота регрессии (ЧР) - fire
• Примеры
• ЧР и Экономическая целесообразность АТ (ROI);
• Facebook и Bamboo
• Kanban, ЧР, опыт WG
• Доведенные до «абсолюта» «рекоммендации»
• «Окно commit-а»

81. Частота регрессии (ЧР) - fire
• Визуализация
• Не реже чем 1 раз в неделю - зеленый цвет
• Не реже чем 1 раз в 2 недели - желтый цвет
• Реже чем 1 раз в месяц - красный цвет
• Чаще чем раз в день - красный цвет
• Связь с другими метриками
• Экономическая целесообразность АТ (ROI);
• Окно автоматизации тестирования;
• Окно анализа результатов тестирования;
• “Окно commit-а“
• Категория:
• Качество
• Автоматизация тестирования

82. % of TA results analyzed - fire
• Определение
• Процент проанализированных негативных
результатов запуска Автоматизированных
тестов. Если негативные результаты не
проанализированны, Автоматизация не
принесла никакой пользы
1. # of not analyzed failed test cases (TI)
2. # of failed due to product bug (PB)
3. # of failed due to automation issues (AB)
4. # of failed due to system issue (SI)
5. Formula = TI / (PB+AB+SI+TI)

83. % of TA results analyzed - fire
• «Физический смысл»
• Чем выше частота использования продукта,
тем выше его ценность. Это касается и
автоматизированных тестов, чем выше
частота регрессии, а соответственно и
частота прогонов автотестов, тем выше их
ценность для заказчика. Но если только нет
анализа негативных результатов, вся value
превращается в ноль. Таким образом данная
метрика является одной из ключевых при
оценке ROI автоматизации тестирования.

84. % of TA results analyzed - fire
• Границы
• % >95% (в идеале, 100%) – зеленый
• 85% <% < 95% – желтый
• %<= 85 – красный
• Где взять информацию
• Automation reports
• Continuous Integration (CI)
• Примеры
• Множество негативных примеров
• Категория:
• Процесс (fire-эквалайзер)
• Автоматизация тестирования

85. % of TA results analyzed - fire
• Визуализация
• % >95% – зеленый
• 85% <% < 95% – желтый
• %<= 85 – красный
• Связь с другими метриками
• Прогресс автоматизации (ПА)
• Колличество дефектов, на
Автоматизированный Тест (ДАТ)
• Окно анализа результатов тестирования
• Экономическая целесообразность АТ (ROI)
• % of product issues
• % of automation issues
• % of system issues

86. % of product issues - fire
• Определение
• Важно понимать как много дефектов находит
Автоматизированное Тестирование, а так же
процентное соотношения найденных дефектов
к общему колличеству ложных срабатываний,
что показывает стабильность Автоматизации
1. # of not analyzed failed test cases (TI)
2. # of failed due to product bug (PB)
3. # of failed due to automation issues (AB)
4. # of failed due to system issue (SI)
5. Formula = PB / (PB+AB+SI+TI)

87. % of product issues - fire
• «Физический смысл»
• Чем выше частота использования продукта,
тем выше его ценность. Это касается и
автоматизированных тестов, чем выше
частота регрессии, а соответственно и
частота прогонов автотестов, тем выше их
ценность для заказчика. Но если только нет
анализа негативных результатов, вся value
превращается в ноль. Таким образом данная
метрика является одной из ключевых при
оценке ROI автоматизации тестирования.

88. % of product issues - fire
• Границы
• 5% > % (в идеале, 0) – зеленый
• 10% > % > 5% – желтый
• % >= 10 – красный
• Где взять информацию
• Automation reports
• Continuous Integration (CI)
• Примеры
• Множество негативных примеров
• Категория:
• Процесс (fire-эквалайзер)
• Автоматизация тестирования

89. % of product issues - fire
• Визуализация
• 5% > % – зеленый
• 10% >% > 5% – желтый
• % >= 10 – красный
• Связь с другими метриками
• Прогресс автоматизации (ПА)
• Колличество дефектов, на
Автоматизированный Тест (ДАТ)
• Окно анализа результатов тестирования
• Экономическая целесообразность АТ (ROI)
• % of TA results analyzed
• % of automation issues
• % of system issues

90. % of automation issues - fire
• Определение
• Важно понимать как много
Автоматизированных тестов падает в силу
ошибок самих тестов, а так же процентное
соотношене ложный падений в силу ошибок в
тесте к общему колличеству ложных
срабатываний, что показывает корректность
Автоматизации
1. # of not analyzed failed test cases (TI)
2. # of failed due to product bug (PB)
3. # of failed due to automation issues (AB)
4. # of failed due to system issue (SI)
5. Formula = AB / (PB+AB+SI+TI)

91. % of automation issues - fire
• «Физический смысл»
• Чем выше частота использования продукта,
тем выше его ценность. Это касается и
автоматизированных тестов, чем выше
частота регрессии, а соответственно и
частота прогонов автотестов, тем выше их
ценность для заказчика. Но если только нет
анализа негативных результатов, вся value
превращается в ноль. Таким образом данная
метрика является одной из ключевых при
оценке ROI автоматизации тестирования.

92. % of automation issues - fire
• Границы
• 5% > % (в идеале, 0) – зеленый
• 10% > % > 5% – желтый
• % >= 10 – красный
• Где взять информацию
• Automation reports
• Continuous Integration (CI)
• Примеры
• Множество негативных примеров
• Категория:
• Процесс (fire-эквалайзер)
• Автоматизация тестирования

93. % of automation issues - fire
• Визуализация
• 5% > % – зеленый
• 10% >% > 5% – желтый
• % >= 10 – красный
• Связь с другими метриками
• Прогресс автоматизации (ПА)
• Колличество дефектов, на
Автоматизированный Тест (ДАТ)
• Окно анализа результатов тестирования
• Экономическая целесообразность АТ (ROI)
• % of TA results analyzed
• % of product issues
• % of system issues

94. % of system issues
• Определение
• Важно понимать как много
Автоматизированных тестов падает в силу не
стабильности окружения, а так же процентное
соотношене ложный падений в силу проблем
окружения к общему колличеству ложных
срабатываний, что показывает корректность
окружения
1. # of not analyzed failed test cases (TI)
2. # of failed due to product bug (PB)
3. # of failed due to automation issues (AB)
4. # of failed due to system issue (SI)
5. Formula = SI / (PB+AB+SI+TI)

95. % of system issues
• «Физический смысл»
• Чем выше частота использования продукта,
тем выше его ценность. Это касается и
автоматизированных тестов, чем выше
частота регрессии, а соответственно и
частота прогонов автотестов, тем выше их
ценность для заказчика. Но если только нет
анализа негативных результатов, вся value
превращается в ноль. Таким образом данная
метрика является одной из ключевых при
оценке ROI автоматизации тестирования.

96. % of system issues
• Границы
• 5% > % (в идеале, 0) – зеленый
• 10% > % > 5% – желтый
• % >= 10 – красный
• Где взять информацию
• Automation reports
• Continuous Integration (CI)
• Примеры
• Множество негативных примеров
• Категория:
• Процесс (fire-эквалайзер)
• Автоматизация тестирования

97. % of system issues
• Визуализация
• 5% > % – зеленый
• 10% >% > 5% – желтый
• % >= 10 – красный
• Связь с другими метриками
• Прогресс автоматизации (ПА)
• Колличество дефектов, на
Автоматизированный Тест (ДАТ)
• Окно анализа результатов тестирования
• Экономическая целесообразность АТ (ROI)
• % of TA results analyzed
• % of product issues
• % of automation issues

98. «Окно» АТ - fire
• Определение
• «Окно» Автоматизированного тестирования
(как пожарный извещатель) – как много
физического времени занимает прогон
Автоматизированных тестов (полное или
подмножество)
• «Окно» Автоматизированного тестирования –
как много системного «лабороторного»
времени занимает прогон
Автоматизированных тестов (полное или
подмножество)

99. «Окно» АТ - fire
• «Физический смысл»
• Время, требуемое для прогона автотестов
необходимо учитывать при оценке
экономической эффективности
автоматизации, при анализе ROI и сравнении с
ручным тестированием. Метрика необходима
как при принятии решения о целесообразности
внедрения автоматизации, так и при оценке
текущего состояния уже реализованной
автоматизации с целью выявления узких мест.

100. «Окно» АТ - fire
• Границы
• В зависимости от размера проекта может
занимать от нескольких до многих часов. Как
правило, Smoke после commit-а должен
занимать не более часа, полная Регрессия не
более двух дней (выходные)
• Где взять информацию
• Test Reports
• Continuous Integration (CI)

101. «Окно» АТ - fire
• Примеры
• Социальные сети (Facebook, Bamboo), CMS,
шаблоны для CMS - до появления средств
автоматизации визуального тестирования
процент автоматизируемых тестов был
относительно невысок;
• Контр пример – физическое время
• Контр пример – машинное время (Claud)
• Технические детали: Stateless и Statefull
Автоматизация, параллельный запуск
• Технические детали: Эффективные ожидания
• Технические детали: Преждевременная
оптимизация

102. «Окно» АТ - fire
• Визуализация
• Smoke <= 1 час, Full Regression <= 12 часов
(ночь) - зеленый цвет
• Smoke <= 2 часа, Full Regression <= 2 дня
(выходные) - желтый цвет
• Smoke > 2 часа, Full Regression > 2 дня
(выходные) - красный цвет

103. «Окно» АТ - fire
• Связь с другими метриками
• Прогресс автоматизации
• Процент покрытия автоматизированными
тестами
• Частота проведения регрессии
• Стабильность Автоматизированных Тестов
• «Окно» анализа результатов тестирования
• Категория:
• Цена / Время
• Автоматизация тестирования

104. «Окно» анализа АТ - fire
• Определение
• «Окно» анализа результатов
Автоматизированного Тестирования (как
пожарный извещатель) = Сколько времени
требуется чтобы проанализировать
полученные данные?
• «Физический смысл»
• Метрика показывает, насколько
исчерпывающими и читабильными являются
отчеты. При слишком большом окне анализа
меньше времени будет уделяться
фактическому написанию тестов, или анализ
будет проводиться недостаточно тщательно,
что обесценит value Автоматизации

105. «Окно» анализа АТ - fire
• Границы
• В зависимости от размера проекта может
занимать от нескольких минут до многих часов.
Как правило, анализ результатов Smoke
тестов после commit - должен занимать
считанные минуты, анализ результатов
полной Регрессии – должен занимать
считанные часы, в идеале, меньше часа.
• Где взять информацию
• Test Reports
• Continuous Integration (CI)
• Task Tracking Systems

106. «Окно» анализа АТ - fire
• Примеры
• Социальные сети (Facebook, Bamboo), CMS,
шаблоны для CMS - до появления средств
автоматизации визуального тестирования
процент автоматизируемых тестов был
относительно невысок;
• Mature Data Protection Solution, new SQL Denali
plug-in, close to 100%;
• Mature Secure VPN (Russian), технологический
стек;
• Контрпримеры

107. «Окно» анализа АТ - fire
• Визуализация
• Smoke <= 10 минут, Full Regression <= 2 часа -
зеленый цвет
• Smoke <= 20 минут, Full Regression <= 4 часа -
желтый цвет
• Smoke > 20 минут, Full Regression > 4 часов -
красный цвет

108. «Окно» анализа АТ - fire
• Связь с другими метриками
• Прогресс автоматизации
• Процент покрытия автоматизированными
тестами
• Частота проведения регрессии
• Стабильность Автоматизированных Тестов
• «Окно» анализа результатов тестирования
• Категория:
• Цена / Время
• Автоматизация тестирования

109. М личной эффективности
• Определение
• Большинство метрик применимо к изучению
личной эффективности, но не в контексте
проекта, а в контексте индивидуального
профессионального развития.
• Пример
• Экономическая целесообразность Автоматизации
(ROI)

110. Как выбрать и исп. набор м?
• Out of scope, but … 

111. Как выбрать и исп. набор м?
• Сформулируйте цели проекта
• Выберете метрики, которые смогут дать
некоторую информацию по сформулированным
целям
• Путем экспертной оценки определите границы
выбранных метрик для вашего проекта
• Автоматизируйте подсчет метрик
• Визуализируйте значения метрик на базе
определенных границ
• Не забывайте про эквалайзер и принцип
светофора

112. Как выбрать и исп. набор м?
• Заблаговременно разработайте план действий
при выходе значений той или иной метрики из
приемлемого диапазона
• Регулярно пересматривайте цели проекта и
набор метрик
• Регулярно пересматривайте границы допустимых
значений каждой метрики
• Регулярно «балансируйте» эквалайзер под ваш
проект в данной фазе

113. «Увлекательные» истории
• Результаты голосования в РБ
• Результаты голосования в РФ
• Панельная дискуссия CodeFest 2016 Новосибирск
• Уголок QA Secon 2016 в Пензе
• Панельная дискуссия в EPAM Systems, Минск
• Панельная дискуссия в EPAM Systems, Санкт-
Петербург
• Панельная дискуссия в EPAM Systems, Саратов

114. “Актуальность” информации
• Результаты голосования в РБ
• Результаты голосования в РФ
• EPAM Systems best practices
• DPI.Solutions best practices
• EPAM IT Week и Open Days
• Панельная дискуссия в EPAM Systems, Минск
• Панельная дискуссия в EPAM Systems, Санкт-
Петербург
• Панельная дискуссия в EPAM Systems, Саратов
• Панельная дискуссия CodeFest 2016 Новосибирск
• Уголок QA Secon 2016 в Пензе

115. “Источники” информации
• ISTQB certifications
• “Implementing Automated Software Testing,” by Elfriede
Dustin, Thom Garrett, Bernie Gauf
• “Useful Automated Software Testing Metrics” by Thom
Garrett
• Результаты голосования в РБ от COMAQA
• Результаты голосования в РФ от Software-Testing.ru
• EPAM Systems best practices
• DPI.Solutions best practices

116. “Take away” points
• Уверен, презентация не бесполезна в нашей
ежедневной работе. Коллеги, пожалуйста
перечитывайте, при случае, презентацию, прежде всего
слайды посвященные непосредственно метрикам.
Спасибо!
…

117. Что дальше?
• Применяйте метрики 
• Внимательно «всмотритесь» в ваш проект – скорее
всего какие-то метрики, пусть и в неявном виде, но
используются. Идентифицируйте неявно
используемые метрики.
• Классифицируйте выявленные метрики
• Постарайтесь установить связь / корреляцию между
метриками
• Дополните метрики
• Регулярно рассчитывайте значения метрик
(Автоматически)
• Используйте полученные данные
• Постоянно адаптируйте процесс
• Например, стоит ввести стандартные QA
риски в качестве варанта классификации
• Спасибо 
…

118. IT overview
• Фредерик Брукс «Мифический человеко-месяц или Как
создаются программные системы»
Notes: «Мировоззренческая» книга ... очень легко читается,
около художественная литература ... рекоммендую прочитать
дважды.
• Том де Марко «Peopleware: Productive Projects and Teams.»
Notes: «Мировоззренческая» книга ... очень легко читается,
около художественная литература ... рекоммендую прочитать
дважды.

119. IT overview
• Том де Марко «The Deadline: A Novel About Project
Management»
Notes: «Мировоззренческая» книга ... очень легко читается,
около художественная литература ... рекоммендую прочитать
дважды.
• Кент Бек «Экстремальное программирование. Разработка
через тестирование»
Notes: IMHO Легкая для прочтения, концептуально целостная
книга, с полезными примерами

120. Tech overview
• Гради Буч «Объектно Ориентированный Анализ и
проектирование с примерами приложений на С++»
Notes: Не стоит пугаться примеров на С++, 95% материала
концептуального, не зависящего от конретного языка
программирования.
На мой взгляд это одна из лучших книг для настоящего, а не
шапочного, знакомство с ООП.
• Стив Макконнелл «Совершенный код»
Notes: Не стоит бояться размера книги ... ее стоит или
читать перед сном с любого места ... или выборочные
главы, что бы освежить свои знания в конкретной
проблемной области.

121. Tech overview
• Мартин Фаулер «Рефакторинг»
Notes: IMHO категорически рекомендую прочитать от
корки до корки, 2 раза подряд, что бы содержание книги
стало вашим активным профессиональным багажом.
• Gang of four “Design patterns”
Notes: IMHO категорически рекомендую прочитать от
корки до корки, как минимум, 2 раза подряд, что бы
содержание книги стало вашим активным
профессиональным багажом.
• Д. Томас, Эндрю Хант «Программист-прагматик. Путь от
подмастерья к мастеру»
Notes: Замечательная книга, состоящая из множества
атомарных советов. IMHO стоит прочитать от корки до
корки 2 раза, а затем пролистывать выборочные главы при
подготовке к обсуждению с заказчиком или интервью.

122. CONTACT ME
semenchenko@dpi.solutions
dpi.semenchenko
https://www.linkedin.com/in/anton-
semenchenko-612a926b
https://www.facebook.com/semenche
nko.anton.v
https://twitter.com/comaqa

123. www.COMAQA.BY
Аудитория сообщества
Специалисты по тестированию (как ручному, так и
автоматизированному)
Разработчики средств автоматизации
Менеджеры и специалисты по продажам в IT
IT-специалисты, думающие о переходе в автоматизацию
Студенты в поиске перспективной профессии
Цель сообщества
Создать единую площадку для эффективного общения всех IT-
специалистов в контексте автоматизированного тестирования
Ваша выгода
Возможность услышать доклады ведущих IT-профессионалов и
поделиться своим опытом
Бесплатно участвовать в “промо” - версиях топовых IT-
конференций стран СНГ
Регулярно встречаться лично, на тематическом форуме, в
“филиалах” сообщества в социальных сетях и мессенджерах

124. www.COMAQA.BY
info@comaqa.by
https://www.facebook.com/comaqa.by/
http://vk.com/comaqaby
+375 33 33 46 120
+375 44 74 00 385

125. www.CoreHard.by
Аудитория сообщества
«Суровые» разработчики на С++ & co, IoT, BigData, High Load,
Parallel Computing
Разработчики средств автоматизации
Менеджеры и специалисты по продажам в IT
Студенты в поиске перспективной профессии
Цель сообщества
Создать единую площадку для эффективного общения всех IT-
специалистов в контексте “суровой” разработки
Ваша выгода
Возможность услышать доклады ведущих IT-профессионалов и
поделиться своим опытом
Бесплатно участвовать в “промо” - версиях топовых IT-
конференций стран СНГ
Регулярно встречаться лично, на тематическом форуме, в
“филиалах” сообщества в социальных сетях и мессенджерах

126. www.CoreHard.by
info@corehard.by
https://www.facebook.com/corehard.by/
+375 33 33 46 120
+375 44 74 00 385