Anton Semenchenko

Метрики Автоматизированного

тестирования на пальцах

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

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

Agenda, part 2 (основная)• 3 вида классификации метрик• Классификация с точки зрения тех специалистов• Классификация с точки зрения бизнеса• Классификация с точки зрения менеджмента на

стороне исполнителя• Важность классификации• Стандартные QA Риски как вариант

классификации метрик• 2 вида проектов• Ниболее популярные метрики АТ• Метрики – пожарные извещатели• Ниболее популярные метрики общие как для

Ручного, так и для Автоматизированного тестирования

• Метрики личной эффективности• Как выбрать и использовать набор метрик?

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

QA и QC• Контроль качества (QC) — это измерение

параметров качества продукта

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

Метрика• Метрика программного обеспечения — мера,

позволяющая получить численное значение некоторого свойства программного обеспечения или его спецификаций.

• Метрика – как механизм обратной связи• Том ДеМарко, «вы не можете контролировать

то, что не можете измерить».

Потенциальные сложности• Что такое качество тестирования?• Не тривиальный вопрос, очень комплексное

понятие.• Успеваем ли мы уложиться в проектные

ограничения?• Дата Релиза• Бюджет

Потенциальные сложности• Как можно улучшить процесс тестирования и

разработки ПО в целом?• Успешна ли АТ, текущий статус АТ, не

отклонились ли мы от намеченной траектории• И многие другие

Где взять данные?• Этот вопрос регулярно задают не только

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

Трансформация• Трансформация:• Данные• =>• Информация (фильтрация данных)• =>• Визуализация информации (сложение,

вычитание, деление)• =>• Работа с «Трендом»

• Примеры:• Биржа• Любой BigData проект

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

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

Светофор - метрик• Светофор – как способ максимально быстро

получить актуальную высокоуровневую информацию о проекте. Многие метрики можно и нужно использовать в стиле «светофор».

• Красный – надо срочно обратить детальное внимание

• Желтый – в зависимости от загруженности, либо обратить поверхностное внимание лично, либо дерелировать эту активность

• Зеленый – не требует вмешательства\внимания

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

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

«Пожарные» метрики• Если процесс разработки и тестирования ПО

налажен – вероятность того, что проект будет успешно реализован приемлемо высока.

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

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

Классификация (IT stuff)• Классификация по «областям»• Качество Продукта (Quality)• Прогресс той или иной активности в тестировании

(Progress)• Покрытие (Coverage)• Цена / время (Cost / time)• Процесс обеспечения качества и разработки в

целом (Process)

Классификация (Business)• Классификация «Что должно быть

исправлено в первую очередь»• Качество Продукта (Quality)• Время тестирования продукта / впуска продукта

(Time)• Стоимость тестирования продукта (Costs/efforts)• Прозрачность тестирования продукта (Testing

visibility)• Автоматизация тестирования (Test automation

approach)

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

3 варианта классификации?• Классификация с точки зрения технического

специалиста / исполнителя• Классификация с точки зрения заказчика• Классификация с точки зрения менеджмента

• Любая классификация не идеальна и рассматривает «поблемную» область под определенным углом зрения

• Метрика – инструмент• А классификация – инструмент для эффективной

работы с инструментом-метрикой

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

2 вида проектов?• Outsourcing

• Own product development

Метрики АТ• Процент тестов, поддающихся автоматизации

(ППА)• Прогресс автоматизации (ПА)• Процент покрытия автоматизированными тестами

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

Тест (ДАТ)

Метрики АТ• Окно автоматизации тестирования• Окно анализа результатов тестирования

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

% т, поддающихся А (ППА)• Определение• Процент тестов, поддающихся автоматизации

= # тест кейсов которые можно автоматизировать (ПА) / # общее количество тест кейсов (ОТК)

• «Физический смысл»• Отражает адаптированность приложения к

автоматизированному тестированию с точки зрения технологий и архитектуры

% т, поддающихся А (ППА)• Границы• Для большинства относительно новых

приложений этот параметр, как правило, превышает 90%

• Где взять информацию• Информация получается на базе тест-плана и

экспертной оценки

% т, поддающихся А (ППА)• Примеры• Mature Data Protection Solution, new SQL Denali

plug-in, close to 100%;• Mature Secure VPN (Russian), технологический

стек;• Социальные сети (Facebook, Bamboo), CMS,

шаблоны для CMS - до появления средств автоматизации визуального тестирования процент автоматизируемых тестов был относительно невысок;

• MS и Google;

% т, поддающихся А (ППА)• Визуализация• Более 90% - зеленый цвет• От 70% до 90% - желтый цвет• Менее 70% - красный цвет

• Связь с другими метриками• Прогресс автоматизации (ПА)• Процент покрытия автоматизированными

тестами (ПП АТ)

• Категория:• Качество• Автоматизация тестирования

Прогресс А (ПА)• Определение• Прогресс автоматизации (ПА) = # количество

автоматизированных на данный момент тест кейсов (АТК) / # общее количество тест кейсов автоматизации (ОАТК)

• «Физический смысл»• Отражение статуса во времени для понимания

достижимости или недостижимости поставленных целей

• Как много тест кейсов команда покрыла Автоматизацией в течении последней итерации (Sprint, Release)? Способ убедиться в том, что текущий прогресс позволяет достичь намеченных целей до Deadline-а

Прогресс А (ПА)• Границы• Границы: 0 – 100%

• Где взять информацию• Test Plan• Test Reports• Continues Integration (CI)• Test Management Systems (TMS)

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

стек;

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

Автоматизации тестов к уже реализованным• Общее колличество запланированных часов к

уже использованному

Прогресс А (ПА)• Связь с другими метриками• Процент покрытия автоматизированными

тестами (ПП АТ);• Колличество найденных дефектов на

Автоматизированный тест;• Окно Автоматизации Тестирования;• Окно Анализа результатов;• Экономическая целесообразность АТ (ROI);

• Категория:• Прогресс• Автоматизация тестирования

% покрытия АТ (coverage)• Определение• Процент покрытия автоматизированными

тестами (ПП АТ) = Покрытие автоматизированными тестами (ПАТ) / Общее покрытие (ОП) (KLOC, FP, etc.)

• Метрику можно «интерпретировать» очень по-разному

% покрытия АТ (ПП АТ)• «Физический смысл»• Данная метрика помогает выявить, насколько

«эффективна» / «разумна» автоматизация.• Выявить, какие тесты стоит

Автоматизировать в первую очередь (например, начать со Smoke и Regression, если эти тест кейсы достаточно формализованы) и сравнить с текущим покрытием (подразумевается что АТ запускаются регулярно и выявляют дефекты).

• Удостовериться, в том, что Автоматизированные тесты проверяют именно то, что должны проверять.

% покрытия АТ (ПП АТ)• Границы• Границы: 0 – 100%

• Где взять информацию• Test Reports• Continues Integration (CI)• Test Management Systems (TMS)

% покрытия АТ (ПП АТ)• Примеры• Mature Data Protection Solution, new SQL Denali

plug-in, close to 100%;• MS and Windows Millennium• Data Protection Giant and Automation

% покрытия АТ (ПП АТ)• Визуализация• Термин test coverage matrix и traceability matrix

взаимозаменяемы в большинстве случаев• Karen Johnson's использовать trace matrix как

индикатор test coverage.

• Связь с другими метриками• Процент покрытия автоматизированными

тестами (ПП АТ);• Прогресс Автоматизации

• Категория:• Покрытие• Автоматизация тестирования

Частота регрессии (ЧР)• Определение• Частота проведения регрессии (ЧР) = Как

часто проводится автоматизированная регрессия?

• «Физический смысл»• Чем выше частота использования продукта,

тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.

Частота регрессии (ЧР)• Границы• Широкораспространенные границы /

рекомендации:o smoke - каждую ночьo full-regression - каждые выходные

• Где взять информацию• Automation reports• Continuous Integration (CI)

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

Частота регрессии (ЧР)• Визуализация• Не реже чем 1 раз в неделю - зеленый цвет• Не реже чем 1 раз в 2 недели - желтый цвет• Реже чем 1 раз в месяц - красный цвет• Чаще чем раз в день - красный цвет

• Связь с другими метриками• Экономическая целесообразность АТ (ROI);• Окно автоматизации тестирования;• Окно анализа результатов тестирования; • “Окно commit-а“

• Категория:• Качество• Автоматизация тестирования

Стабильность АТ• Определение• Стабильность Автоматизированных тестов =

процент тестов, которые либо успешно проходят либо падают, по причине нахождения дефекта

• «Физический смысл»• Отражает качество автотестов и

соответствие их текущему состоянию тестируемой системы

Стабильность АТ• Границы• Цель – процент «случайных» падений не

превышает 5%

• Где взять информацию• Test Reports

Стабильность АТ• Примеры• Множество проектов;• Стандартная «проблема» при работе с middle+

специалистами по Автоматизированному тестированию «старой формации»

Стабильность АТ• Визуализация• Более 95% - зеленый цвет• Более 90%, менее 95% - желтый цвет• Менее 90% - красный цвет

• Связь с другими метриками• Колличество дефектов на

Автоматизированный тест

• Категория:• Качество / Процесс• Автоматизация тестирования

# дефектов на АТ• Определение• Колличество дефектов на

Автоматизированный Тест = ведется подсчет дефектов, как Автоматизированных, так и Ручных;

• Если Автоматизированное тестирование не находит дефектов или лишь незначительное колличество дефектов, то:

• Выделить области Автоматизации для улучшения;

• Репреоретизировать усилия в Автоматизации;• Отказаться от Автоматизации;

# дефектов на АТ• «Физический смысл»• Отражает эффективность автотестов с

точки зрения нахождения дефектов

• Границы• Отсутствие найденных дефектов может

являться индикатором неудачного фокуса автотестов

• Где взять информацию• Test Reports

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

Автоматизации• Стандартная «проблема» получения прибыли

исполнителем в ущерб заказчику

# дефектов на АТ• Визуализация• Более 5% (минимальный процент зависит от

фазы и деталей проекта) - зеленый цвет• От 1 до 5% - желтый цвет• Менее 1% - красный цвет

• Связь с другими метриками• Стабильность Автоматизированных тестов

• Категория:• Качество / Процесс• Автоматизация тестирования

«Окно» АТ• Определение• «Окно» Автоматизированного тестирования –

как много физического времени занимает прогон Автоматизированных тестов (полное или подмножество)

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

«Окно» АТ• «Физический смысл»• Время, требуемое для прогона автотестов

необходимо учитывать при оценке экономической эффективности автоматизации, при анализе ROI и сравнении с ручным тестированием. Метрика необходима как при принятии решения о целесообразности внедрения автоматизации, так и при оценке текущего состояния уже реализованной автоматизации с целью выявления узких мест.

«Окно» АТ• Границы• В зависимости от размера проекта может

занимать от нескольких до многих часов. Как правило, Smoke после commit-а должен занимать не более часа, полная Регрессия не более двух дней (выходные)

• Где взять информацию• Test Reports• Continuous Integration (CI)

«Окно» АТ• Примеры• Социальные сети (Facebook, Bamboo), CMS,

шаблоны для CMS - до появления средств автоматизации визуального тестирования процент автоматизируемых тестов был относительно невысок;

• Контр пример – физическое время• Контр пример – машинное время (Claud)• Технические детали: Stateless и Statefull

Автоматизация, параллельный запуск• Технические детали: Эффективные ожидания• Технические детали: Преждевременная

оптимизация

«Окно» АТ• Визуализация• Smoke <= 1 час, Full Regression <= 12 часов (ночь)

- зеленый цвет• Smoke <= 2 часа, Full Regression <= 2 дня

(выходные) - желтый цвет• Smoke > 2 часа, Full Regression > 2 дня

(выходные) - красный цвет

«Окно» АТ• Связь с другими метриками• Прогресс автоматизации• Процент покрытия автоматизированными

тестами• Частота проведения регрессии• Стабильность Автоматизированных Тестов • «Окно» анализа результатов тестирования

• Категория:• Цена / Время• Автоматизация тестирования

«Окно» анализа р-тов АТ• Определение• «Окно» анализа результатов

Автоматизированного Тестирования = Сколько времени требуется чтобы проанализировать полученные данные?

• «Физический смысл»• Метрика показывает, насколько

исчерпывающими и читабильными являются отчеты. При слишком большом окне анализа меньше времени будет уделяться фактическому написанию тестов, или анализ будет проводиться недостаточно тщательно, что обесценит value Автоматизации

«Окно» анализа р-тов АТ• Границы• В зависимости от размера проекта может

занимать от нескольких минут до многих часов. Как правило, анализ результатов Smoke тестов после commit - должен занимать считанные минуты, анализ результатов полной Регрессии – должен занимать считанные часы, в идеале, меньше часа.

• Где взять информацию• Test Reports• Continuous Integration (CI)• Task Tracking Systems

«Окно» анализа р-тов АТ• Примеры• Социальные сети (Facebook, Bamboo), CMS,

шаблоны для CMS - до появления средств автоматизации визуального тестирования процент автоматизируемых тестов был относительно невысок;

• Mature Data Protection Solution, new SQL Denali plug-in, close to 100%;

• Mature Secure VPN (Russian), технологический стек;

• Контрпримеры

«Окно» анализа р-тов АТ• Визуализация• Smoke <= 10 минут, Full Regression <= 2 часа -

зеленый цвет• Smoke <= 20 минут, Full Regression <= 4 часа -

желтый цвет• Smoke > 20 минут, Full Regression > 4 часов -

красный цвет

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

• Категория:• Цена / Время• Автоматизация тестирования

t разработки АТ-а• Определение• Среднее время разработки Автоматизированного

Теста = # всех автоматизированных тестов / время на создание

• «Физический смысл»• Информация о времени на разработку одного

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

t разработки АТ-а• Границы• Границы: 1-16 часов на тест, в зависимости от

сложности сценария, применяемых технологий (как в разработке приложения, так и в автоматизации), среднее время «по-больнице» 4 часа.

• Где взять информацию• Task Tracking System

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

специалистами по Автоматизированному тестированию «старой формации»

t разработки АТ-а• Визуализация• Менее 4 часов- зеленый цвет• Менее 8 часов, но более 4 часов - желтый цвет• Более 8 часов - красный цвет

• Связь с другими метриками• Время на поддержку автоматизированного

теста• Экономическая целесообразность АТ (ROI)

• Категория:• Цена / время• Автоматизация тестирования

t поддержки АТ-а• Определение• Среднее время уделяемое поддержке

Автоматизированного Теста в течении указанного периуда времени = # всех автоматизированных тестов / время на поддержку.

t поддержки АТ-а• «Физический смысл»• Любой программный продукт при работе по

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

t разработки АТ-а• Границы• Границы: от 0.5 часа на тест в год, до ... чуть

ли не бесконечности (заниматься тонкой балансировкой Sleep-ов можно сколько угодно – стабилизация так и не наступит) ... Безусловно конкретные показатели зависят от множества факторов – стабильности требований, стабильности приложения, технологического стека – как приложения, так и автоматизации, но время не должно превышать 4 часов в большиснтве случаев.

• Где взять информацию• Task Tracking System

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

специалистами по Автоматизированному тестированию «старой формации»

t разработки АТ-а• Визуализация• Менее 0,5 часа на тест в год - зеленый цвет• Не более 1 часа на тест в год - желтый цвет• Более 2 часов на тест в год - красный цвет

• Связь с другими метриками• Время на поддержку автоматизированного

теста• Экономическая целесообразность АТ (ROI)

• Категория:• Цена / время• Автоматизация тестирования

ROI (out of scope, but )• Определение• Экономическая целесообразность

Автоматизированного Тестирования (ROI) = Manual efforts – (Automation efforts + Automation investment) / QA investment * 100%

• «Физический смысл»• Указывает на то, имеет ли смысл внедрять

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

ROI• Границы• Out of scope

• Где взять информацию• Test Strategy• Test Plan• Test Management Systems (TMS)

ROI• Примеры• Множество проектов• Стандартная «проблема» при работе с middle+

специалистами по Автоматизированному тестированию «старой формации»

ROI (+ доп выгоды)• Визуализация• Сравнение трендов• Ручное тестирование• Целый вариант опций введения / развития

Автоматизированного тестирования• Выбор оптимальной команды-тренда здесь и

сейчас

ROI• Связь с другими метриками• Процент тестов, поддающихся автоматизации

(ППА)• Частота проведения регрессии (ЧР)• Стабильность Автоматизированных Тестов

(САТ)• Окно автоматизации тестирования• Окно анализа результатов тестирования• Время на создание автоматизированного

теста• Время на поддержку автоматизированного

теста• Категория:• Цена / время• Автоматизация тестирования

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

(Время выполнения) - fire• Окно анализа результатов тестирования - fire

Частота регрессии (ЧР) - fire• Определение• Частота проведения регрессии как пожарный

извещатель (ЧР) = Как часто проводится автоматизированная регрессия?

• «Физический смысл»• Чем выше частота использования продукта,

тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.

Частота регрессии (ЧР) - fire• Границы• Широкораспространенные границы /

рекомендации:o smoke - каждую ночьo full-regression - каждые выходные

• Где взять информацию• Automation reports• Continuous Integration (CI)

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

Частота регрессии (ЧР) - fire• Визуализация• Не реже чем 1 раз в неделю - зеленый цвет• Не реже чем 1 раз в 2 недели - желтый цвет• Реже чем 1 раз в месяц - красный цвет• Чаще чем раз в день - красный цвет

• Связь с другими метриками• Экономическая целесообразность АТ (ROI);• Окно автоматизации тестирования;• Окно анализа результатов тестирования; • “Окно commit-а“

• Категория:• Качество• Автоматизация тестирования

% 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)

% of TA results analyzed - fire• «Физический смысл»• Чем выше частота использования продукта,

тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Но если только нет анализа негативных результатов, вся value превращается в ноль. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.

% of TA results analyzed - fire• Границы• % >95% (в идеале, 100%) – зеленый• 85% <% < 95% – желтый• %<= 85 – красный

• Где взять информацию• Automation reports• Continuous Integration (CI)

• Примеры• Множество негативных примеров

• Категория:• Процесс (fire-эквалайзер)• Автоматизация тестирования

% of TA results analyzed - fire• Визуализация• % >95% – зеленый• 85% <% < 95% – желтый• %<= 85 – красный

• Связь с другими метриками• Прогресс автоматизации (ПА)• Колличество дефектов, на

Автоматизированный Тест (ДАТ)• Окно анализа результатов тестирования• Экономическая целесообразность АТ (ROI)• % of product issues• % of automation issues• % of system issues

% 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)

% of product issues - fire• «Физический смысл»• Чем выше частота использования продукта,

тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Но если только нет анализа негативных результатов, вся value превращается в ноль. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.

% of product issues - fire• Границы• 5% > % (в идеале, 0) – зеленый• 10% > % > 5% – желтый• % >= 10 – красный

• Где взять информацию• Automation reports• Continuous Integration (CI)

• Примеры• Множество негативных примеров

• Категория:• Процесс (fire-эквалайзер)• Автоматизация тестирования

% of product issues - fire• Визуализация• 5% > % – зеленый• 10% >% > 5% – желтый• % >= 10 – красный

• Связь с другими метриками• Прогресс автоматизации (ПА)• Колличество дефектов, на

Автоматизированный Тест (ДАТ)• Окно анализа результатов тестирования• Экономическая целесообразность АТ (ROI)• % of TA results analyzed• % of automation issues• % of system issues

% 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)

% of automation issues - fire• «Физический смысл»• Чем выше частота использования продукта,

тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Но если только нет анализа негативных результатов, вся value превращается в ноль. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.

% of automation issues - fire• Границы• 5% > % (в идеале, 0) – зеленый• 10% > % > 5% – желтый• % >= 10 – красный

• Где взять информацию• Automation reports• Continuous Integration (CI)

• Примеры• Множество негативных примеров

• Категория:• Процесс (fire-эквалайзер)• Автоматизация тестирования

% of automation issues - fire• Визуализация• 5% > % – зеленый• 10% >% > 5% – желтый• % >= 10 – красный

• Связь с другими метриками• Прогресс автоматизации (ПА)• Колличество дефектов, на

Автоматизированный Тест (ДАТ)• Окно анализа результатов тестирования• Экономическая целесообразность АТ (ROI)• % of TA results analyzed• % of product issues• % of system issues

% 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)

% of system issues• «Физический смысл»• Чем выше частота использования продукта,

тем выше его ценность. Это касается и автоматизированных тестов, чем выше частота регрессии, а соответственно и частота прогонов автотестов, тем выше их ценность для заказчика. Но если только нет анализа негативных результатов, вся value превращается в ноль. Таким образом данная метрика является одной из ключевых при оценке ROI автоматизации тестирования.

% of system issues• Границы• 5% > % (в идеале, 0) – зеленый• 10% > % > 5% – желтый• % >= 10 – красный

• Где взять информацию• Automation reports• Continuous Integration (CI)

• Примеры• Множество негативных примеров

• Категория:• Процесс (fire-эквалайзер)• Автоматизация тестирования

% of system issues• Визуализация• 5% > % – зеленый• 10% >% > 5% – желтый• % >= 10 – красный

• Связь с другими метриками• Прогресс автоматизации (ПА)• Колличество дефектов, на

Автоматизированный Тест (ДАТ)• Окно анализа результатов тестирования• Экономическая целесообразность АТ (ROI)• % of TA results analyzed• % of product issues• % of automation issues

«Окно» АТ - fire• Определение• «Окно» Автоматизированного тестирования

(как пожарный извещатель) – как много физического времени занимает прогон Автоматизированных тестов (полное или подмножество)

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

«Окно» АТ - fire• «Физический смысл»• Время, требуемое для прогона автотестов

необходимо учитывать при оценке экономической эффективности автоматизации, при анализе ROI и сравнении с ручным тестированием. Метрика необходима как при принятии решения о целесообразности внедрения автоматизации, так и при оценке текущего состояния уже реализованной автоматизации с целью выявления узких мест.

«Окно» АТ - fire• Границы• В зависимости от размера проекта может

занимать от нескольких до многих часов. Как правило, Smoke после commit-а должен занимать не более часа, полная Регрессия не более двух дней (выходные)

• Где взять информацию• Test Reports• Continuous Integration (CI)

«Окно» АТ - fire• Примеры• Социальные сети (Facebook, Bamboo), CMS,

шаблоны для CMS - до появления средств автоматизации визуального тестирования процент автоматизируемых тестов был относительно невысок;

• Контр пример – физическое время• Контр пример – машинное время (Claud)• Технические детали: Stateless и Statefull

Автоматизация, параллельный запуск• Технические детали: Эффективные ожидания• Технические детали: Преждевременная

оптимизация

«Окно» АТ - fire• Визуализация• Smoke <= 1 час, Full Regression <= 12 часов (ночь)

- зеленый цвет• Smoke <= 2 часа, Full Regression <= 2 дня

(выходные) - желтый цвет• Smoke > 2 часа, Full Regression > 2 дня

(выходные) - красный цвет

«Окно» АТ - fire• Связь с другими метриками• Прогресс автоматизации• Процент покрытия автоматизированными

тестами• Частота проведения регрессии• Стабильность Автоматизированных Тестов • «Окно» анализа результатов тестирования

• Категория:• Цена / Время• Автоматизация тестирования

«Окно» анализа АТ - fire• Определение• «Окно» анализа результатов

Автоматизированного Тестирования (как пожарный извещатель) = Сколько времени требуется чтобы проанализировать полученные данные?

• «Физический смысл»• Метрика показывает, насколько

исчерпывающими и читабильными являются отчеты. При слишком большом окне анализа меньше времени будет уделяться фактическому написанию тестов, или анализ будет проводиться недостаточно тщательно, что обесценит value Автоматизации

«Окно» анализа АТ - fire• Границы• В зависимости от размера проекта может

занимать от нескольких минут до многих часов. Как правило, анализ результатов Smoke тестов после commit - должен занимать считанные минуты, анализ результатов полной Регрессии – должен занимать считанные часы, в идеале, меньше часа.

• Где взять информацию• Test Reports• Continuous Integration (CI)• Task Tracking Systems

«Окно» анализа АТ - fire• Примеры• Социальные сети (Facebook, Bamboo), CMS,

шаблоны для CMS - до появления средств автоматизации визуального тестирования процент автоматизируемых тестов был относительно невысок;

• Mature Data Protection Solution, new SQL Denali plug-in, close to 100%;

• Mature Secure VPN (Russian), технологический стек;

• Контрпримеры

«Окно» анализа АТ - fire• Визуализация• Smoke <= 10 минут, Full Regression <= 2 часа -

зеленый цвет• Smoke <= 20 минут, Full Regression <= 4 часа -

желтый цвет• Smoke > 20 минут, Full Regression > 4 часов -

красный цвет

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

• Категория:• Цена / Время• Автоматизация тестирования

М личной эффективности• Определение• Большинство метрик применимо к изучению

личной эффективности, но не в контексте проекта, а в контексте индивидуального профессионального развития.

• Пример• Экономическая целесообразность Автоматизации

(ROI)

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

Как выбрать и исп. набор м?• Сформулируйте цели проекта• Выберете метрики, которые смогут дать

некоторую информацию по сформулированным целям

• Путем экспертной оценки определите границы выбранных метрик для вашего проекта

• Автоматизируйте подсчет метрик• Визуализируйте значения метрик на базе

определенных границ• Не забывайте про эквалайзер и принцип

светофора

Как выбрать и исп. набор м?• Заблаговременно разработайте план действий

при выходе значений той или иной метрики из приемлемого диапазона

• Регулярно пересматривайте цели проекта и набор метрик

• Регулярно пересматривайте границы допустимых значений каждой метрики

• Регулярно «балансируйте» эквалайзер под ваш проект в данной фазе

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

Петербург• Панельная дискуссия в EPAM Systems, Саратов

“Актуальность” информации

• Результаты голосования в РБ• Результаты голосования в РФ

• EPAM Systems best practices• DPI.Solutions best practices

• EPAM IT Week и Open Days• Панельная дискуссия в EPAM Systems, Минск• Панельная дискуссия в EPAM Systems, Санкт-Петербург• Панельная дискуссия в EPAM Systems, Саратов

• Панельная дискуссия CodeFest 2016 Новосибирск• Уголок QA Secon 2016 в Пензе

“Источники” информации

• 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

“Take away” points

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

…

Что дальше?

• Применяйте метрики • Внимательно «всмотритесь» в ваш проект – скорее

всего какие-то метрики, пусть и в неявном виде, но используются. Идентифицируйте неявно используемые метрики.

• Классифицируйте выявленные метрики• Постарайтесь установить связь / корреляцию между

метриками• Дополните метрики• Регулярно рассчитывайте значения метрик

(Автоматически)• Используйте полученные данные• Постоянно адаптируйте процесс• Например, стоит ввести стандартные QA риски в качестве варанта классификации • Спасибо …

IT overview• Фредерик Брукс «Мифический человеко-месяц или Как

создаются программные системы»Notes: «Мировоззренческая» книга ... очень легко читается, около художественная литература ... рекоммендую прочитать дважды.

• Том де Марко «Peopleware: Productive Projects and Teams.»Notes: «Мировоззренческая» книга ... очень легко читается, около художественная литература ... рекоммендую прочитать дважды.

IT overview• Том де Марко «The Deadline: A Novel About Project

Management»Notes: «Мировоззренческая» книга ... очень легко читается, около художественная литература ... рекоммендую прочитать дважды.

• Кент Бек «Экстремальное программирование. Разработка через тестирование»

Notes: IMHO Легкая для прочтения, концептуально целостная книга, с полезными примерами

Tech overview• Гради Буч «Объектно Ориентированный Анализ и

проектирование с примерами приложений на С++»Notes: Не стоит пугаться примеров на С++, 95% материала концептуального, не зависящего от конретного языка программирования.На мой взгляд это одна из лучших книг для настоящего, а не шапочного, знакомство с ООП.

• Стив Макконнелл «Совершенный код»Notes: Не стоит бояться размера книги ... ее стоит или читать перед сном с любого места ... или выборочные главы, что бы освежить свои знания в конкретной проблемной области.

Tech overview• Мартин Фаулер «Рефакторинг»

Notes: IMHO категорически рекомендую прочитать от корки до корки, 2 раза подряд, что бы содержание книги стало вашим активным профессиональным багажом.

• Gang of four “Design patterns”Notes: IMHO категорически рекомендую прочитать от корки до корки, как минимум, 2 раза подряд, что бы содержание книги стало вашим активным профессиональным багажом.

• Д. Томас, Эндрю Хант «Программист-прагматик. Путь от подмастерья к мастеру»Notes: Замечательная книга, состоящая из множества атомарных советов. IMHO стоит прочитать от корки до корки 2 раза, а затем пролистывать выборочные главы при подготовке к обсуждению с заказчиком или интервью.

CONTACT MEsemenchenko@dpi.solutions

dpi.semenchenko

https://www.linkedin.com/in/anton-semenchenko-612a926b

https://www.facebook.com/semenchenko.anton.v

https://twitter.com/comaqa

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

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

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

www.CoreHard.by

info@corehard.by

https://www.facebook.com/corehard.by/

+375 33 33 46 120+375 44 74 00 385