Вы находитесь на странице: 1из 21

Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

ОГЛАВЛЕНИЕ

1. Качество тестирования................................................................................................................................................................................................................... 2
1.1 Пропуски дефектов .................................................................................................................................................................................................................. 2
1.2 Тестовое покрытие – 1/2 .......................................................................................................................................................................................................... 3
1.2 Тестовое покрытие – 2/2 .......................................................................................................................................................................................................... 4
1.3 Качество тест-дизайна .............................................................................................................................................................................................................. 5
2. Проектное планирование .............................................................................................................................................................................................................. 6
2.1 Следование плану работ .......................................................................................................................................................................................................... 6
2.2 Учёт проектных рисков ............................................................................................................................................................................................................. 7
2.3 Метрики для прогнозирования трудозатрат по тестированию ............................................................................................................................................... 8
3. Качество продукта.......................................................................................................................................................................................................................... 9
3.1 Удовлетворение пользователей .............................................................................................................................................................................................. 9
3.2 Дефекты в продукте ............................................................................................................................................................................................................... 10
3.3 Результаты тестирования ....................................................................................................................................................................................................... 11
3.4 Характеристики качества ПО – 1/4 ......................................................................................................................................................................................... 12
3.4 Характеристики качества ПО – 2/4 ......................................................................................................................................................................................... 13
3.4 Характеристики качества ПО – 3/4 ......................................................................................................................................................................................... 14
3.4 Характеристики качества ПО – 4/4 ......................................................................................................................................................................................... 15
4. Эффективность тестирования ...................................................................................................................................................................................................... 16
4.1 Скорость тестирования ........................................................................................................................................................................................................... 16
4.2 Финансовые показатели......................................................................................................................................................................................................... 17
4.3 Работа с дефектами ................................................................................................................................................................................................................ 18
4.4 Автотесты................................................................................................................................................................................................................................ 19
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

1. Качество тестирования
1.1 Пропуски дефектов
# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать

ГДЕ НАЙДЕНЫ ДЕФЕКТЫ


В пром.
Дефектов, зарегистрированных на пром. среде эксплуатации
× 100%
Всего зарегистрировано дефектов 130
• Как один из KPI тестирования
Количество дефектов,
• Для анализа причин ненахождения
1 пропущенных в Bugs Leakage
дефектов в тестовой сборке
продуктив Для сбора метрики необходимо добавить поле
в баг-трекер «на каком окружении был
обнаружен дефект» На тестовой
сборке
820

КТО СООБЩИЛ О ДЕФЕКТЕ


% дефектов, Дефектов выявлено пользователями • Как один из KPI тестирования
Проектная Пользова
2 найденных Bugs Reported by Users × 100% • Для анализа, какие дефекты
пользователями
Всего зарегистрировано дефектов команда тели 9% критичны для пользователей
14%

• Как один из KPI тестирования


% дефектов, Дефектов, выявленных не тестировщиками • Для анализа, почему другие
Bugs Reported not by Тестиров
3 найденных не
Testers Всего зарегистрировано дефектов
× 100% участники процесса находят
тестировщиками щики 77% ошибки, пропущенные
тестировщиками

ПРОПУЩЕНО ДЕФЕКТОВ
25%
Для анализа, в каких областях
20% Функциональных необходимо развивать тестирование
дефектов
Дефектов
Пропуски дефектов по Дефектов с пром среды по категории 15% • В качестве категорий могут
4 категориям
Bugs Leakage by Category
Всего дефектов по категории
× 100% производительности
выступать уровни тестирования,
Дефектов
10% безопасности типы тестирования, зоны
Дефектов юзабилити функциональности и т.д.
5%

0%
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

1.2 Тестовое покрытие – 1/2


# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать

Требований с тестами ТЕСТЫ ПО ТРЕБОВАНИЯМ


× 100%
Всего требований
Согласованы с Отсутствуют
Покрытие требований Requirements Для расчёта этой метрики необходимо командой 12%
5 тестами Coverage определить критерий «требований с тестами». 20% Есть хотя бы
один тест
Это может быть «хотя бы 1 тест», «хотя бы 1 тест 24%
на каждую границу и т.д.». Рассчитывается в
системе ведения требований, по статусу или по • Для планирования
наличию ссылки на тесты. расширения тестового
покрытия
Требований с утверждёнными тестами • Для оценки рисков
× 100%
Всего требований пропуска дефектов

Для расчёта этой метрики необходимо


Подтверждённое Approved согласование тестовых наборов по каждому
6 покрытие требований Requirements требованию. Чаще всего такое согласование
тестами Coverage Соответствуют
происходит с аналитиком и разработчиком, критериям
ответственным за реализацию требования. По 44%
итогам обсуждения в системе ведения
требований проставляется статус «тесты
согласованы»

Покрытие требований
ET Requirements
ПРОВЕДЕНО ТЕСТИРОВАНИЕ ТРЕБОВАНИЙ/ПС
7 исследовательскими
Coverage
тестами
Постановка задач на исследовательское Приоритет 1 • Для оценки
тестирование по требованиям или готовности к релизу
Приоритет 2 • Для планирования
пользовательским сценариям и расчёт %
затрат на
Покрытие требований, по которым было проведено
User Stories Test Приоритет 3 тестирование
8 пользовательских тестирование.
Coverage
сценариев тестами 0% 20% 40% 60% 80% 100%

Протестировано Необходимо протестировать Тестирование не нужно

Покрытие кода по • Для оценки уровня


9 функциям
Code Coverage покрытия
All files
• Выбор инструмента оценки, исходя из • Для исследования
74,83% Statements 28,33% Branches 77,55% Functions 76,12% Lines
Покрытие кода по Alternatives потребностей и архитектуры проекта влияющих
10 условиям File Statements Branches Functions Lines параметров, не
Coverage • Создание инструментальной сборки
src 100% 3/3 100% 0/0 100% 0/0 100% 3/3 обозначенных в
• Проведение тестов на этой сборке для
Покрытие кода по src/app 100% 4/4 100% 0/0 100% 0/0 100% 3/3 документации, но
11 решениям Decision Coverage анализа покрытия влияющих на
src/app/edit 67,74% 21/31 25% 1/4 66,67% 6/9 65,52% 19/29
src/app/search 94,74% 18/19 50% 2/4 87,50% 7/8 93,33% 14/15
выполнение кода
Оценка покрытия кода возможна как для продукта
Покрытие строк автоматизированных, так и для ручных тестов! src/app/shared/search 67,65% 23/34 15,63% 5/32 80% 12/15 65,63% 21/32
• Для расширения
12 кода Path Coverage
тестового покрытия
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

1.2 Тестовое покрытие – 2/2


# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать
13 Покрытие GUI GUI Coverage
Объектов покрыто тестами ПРОВЕДЕНО ТЕСТИРОВАНИЕ ТРЕБОВАНИЙ/ПС
14 Покрытие API API Coverage × 100%
Всего объектов
Экранные формы
Где в качестве объектов могут выступать: Элементы GUI • Выявить зоны рисков и
• Экранные формы «узкие горлышки»
Покрытие • Элементы графического интерфейса
Функции API • Оценить статус
15 Integration Coverage тестирования
интеграций • Функции API Интерфейсы интеграции

• Интерфейсы интеграции 0 200 400 600 800 1000


• И т.д.
Протестировано Необходимо тестирование Тестирование не нужно

Покрытие
ТРЕБОВАНИЯ ПОКРЫТЫ ТЕСТАМИ
16 требований Performance Coverage Требований по группе покрыто тестами
производительности × 100%
Всего требований в группе Поддерживаемые типы данных 50 11 40 • Для планирования
расширения тестового
Покрытие Где в качестве группы могут выступать: покрытия
17 требований нагрузки Load Coverage Требования безопасности 2.5 7 2
• Разные типы требования • Для оценки рисков
• Разные модули Требования производительности 67 25 15 пропуска дефектов
Покрытие • Разные функциональные области
0% 20% 40% 60% 80% 100%
18 поддерживаемых Data Coverage • И т.д.
форматов данных Есть хотя бы один тест Тесты отсутствуют Есть утверждённые тесты

ПРОВЕДЕНО ЮЗАБИЛИТИ-ТЕСТИРОВАНИЕ
100
• Проведение юзабилити-экспертизы с
Покрытие привлечением ЦА с анализом возможности
80 • Оценить юзабилити-риски
60 • Принять решение, какие
пользовательских Use-Cases Covered by выполнения сценариев
19 тесты необходимо
сценариев Usability Tests • Проведение внутренней UX-экспертизы по 40
провести
юзабилити-тестами удобству выполнения пользовательских 20
сценариев 0
Приоритет 1 Приоритет 2 Приоритет 3
Проведено тестирование на ЦА Проведена UX-экспертиза Тестирование не проводилось

Платформа Windows Mac Android Unix


Применимо общих тестов 1350 1350 340 940 • Оценить качество
Покрытие • Анализ рисков, связанных с окружениями Возможно выполнить планирования тестов,
42 60 160 36
только на этой платформе зависящих от окружения
окружений Environmental Unique • Подготовка тестов, зависящих от окружения
20 Уникальные риски на этой • Определить необходимость
уникальными Tests Coverage • Согласование достаточности тестов, платформе
28 n/a 112 n/a
дополнительного анализа
тестами зависящих от окружения Согласованы уникальные • Запланировать расширение
тесты с командой X X V X тестового покрытия
разработки
• Оценить риски, связанные с
Платформа Windows Mac Android Unix
Проведение тестов окружениями
Проведено тестов на платформе Всего тестов 1420 1438 612 1003
21 на поддерживаемых Environments Coverage × 100% • Запланировать
Всего тестов отобрано для платформы Проведено тестов 1 прио 92% 27% 96% 14%
окружениях Проведено тестов 2 прио 86% 13% 100% 6%
дополнительные тесты
окружения
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

1.3 Качество тест-дизайна


# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать

AVG ЭКСПЕРТНАЯ ОЦЕНКА ТЕСТОВ


(Оценки тестов в системе хранения тестов) Полнота тестов
Иван Семён 5 • Для выявления слабых зон
4 в тестовом покрытии
Тесты можно оценивать: 3 • Для обнаружения нехватки
• Одной оценкой Подобранные 2 квалификации и принятия
Детальность
22
Средняя экспертная Expert test cases • По различным шкалам значения 1 решений о
оценка тестов evaluation 0
дополнительном обучении
Оценки можно категоризировать: • Для выявления тестов,
которые необходимо
• По сотрудникам
улучшить
• По группам
• По типам или областям тестов Атомарность Удобство поддержки
• И т.д.

AVG (Последняя версия документации - Модуль % актуальных Среднее отклонение версии от • Оценить риски
Последняя версия документации, использования текущих
тестов последней
использованная в тестах) тестов
23 Актуальность тестов Test cases relevance
или
Модуль 1 100% 0
• Определить необходимость
Тестов, акт. в последней версии Модуль 2 46% 2,6 выделения ресурсов на
× 100% Модуль 3 89% 0,33 актуализацию тестов
Общее число тестов
ВЫПОЛНЕНО ТЕСТОВ ДЛЯ ЗАВЕДЕНИЯ 1
Выполнено тестов
ДЕФЕКТА
Зарегистрировано дефектов
25
Считается по версии, итерации или периоду • Выявить тесты,
20
времени подверженные эффекту
Рейтинг
15 пестицида (см. Продукт 1)
24 обнаружения TC bugs detecting ratio
• Оценить эффективность
дефектов тестами Возможна категоризация статистики по: 10
внедрения новых техник и
• По сотрудникам (тест-дизайнерам) 5 подходов (см. Продукт 2)
• По зонам функциональности
0
• По типам тестов Версия 1 Версия 2 Версия 3 Версия 4 Версия 5
• И т.д.
Продукт 1 Продукт 2

Проект Проект 1 Проект 2


Скорость Затраты на исследовательское тестирование 140 ч/ч 166 ч/ч
обнаружения Зарегистрировано дефектов Багов найдено в ИТ 73 91 • Выявить эффективные
25 дефектов по тест-
TC bugs detection speed Затраты на обнаружение 1 бага в ИТ 1,9 ч/ч 1,8 ч/ч тесты, скорость
Затрачено времени на тестирование по ТК Затраты на проверку тест-кейсов 97 ч/ч 130 ч/ч обнаружения ошибок, по
кейсам Багов найдено по ТК 132 48 которым выше, чем в ИТ
Затраты на обнаружение 1 бага по ТК 0,7 ч/ч 2,7 ч/ч
• Выявить неэффективные
Эффективность тест- тесты, по которым
Exploratory / Scripted Скорость обнаружения по ТК
кейсов по сравнению Проект Проект 1 Проект 2 находится мало дефектов
26 с исследовательским
Testing Efficacy Соотношение эффективности ИТ и ТК 2,7 0,6
Скорость обнаружения в ИТ
Comparison
тестированием
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

2. Проектное планирование
2.1 Следование плану работ
# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать
Дата финиша факт – Дата финиша план
СРЫВЫ СРОКОВ ПО ЗАДАЧАМ В ДНЯХ • Для выявления
Метрика может собираться по: 7 среднего срыва
• Задачам 6 сроков и включения
Срывы сроков по • Итерациям 5
его в планы работ
27 задачам
Schedule slippage
• Релизам • Для анализа причин
4 сроков по каждой
И категоризироваться по:
3 6 задаче или по самым
• Сотрудникам
4.5 большим сдвигам
• Типам задач 2
3.5 4
• Для включения в
• И т.д. 1 2.3
1 планирование
При оценке групп задач, итераций и проектов 0 рисков исходя из
Задача 1 Задача 2 Задача 3 Задача 4 Задача 5 Задача 6 -1 7
Задача Среднее
Отклонение от плана Schedule оценивается в процентах: -1 -2 статистики срывов в
28 работ Variance -2
процентах
Дата фишина факт − Дата финиша план
× 100% -3
Дата финиша план − Дата старта план

ПРЕВЫШЕНИЯ ТРУДОЗАТРАТ
Фактические трудозатраты • Для анализа причин
× 100% − 100% 60% отклонения в
Плановые трудозатраты
50% оценках
40% • Как возможный KPI
Данные можно категорировать по: 30% при необходимости
Превышение Estimation
29 трудозатрат Changes • Задачам 20%
снижения
трудозатрат
• Итерациям 10% • Для поиска
• Командам 0% превышения
• Сотрудникам -10%
Задача 1 Задача 2 Задача 3 Задача 4 трудозатрат по
• И т.д. -20% категориям

В случае, если специалист не может


выполнять задачи по текущей итерации ТРУДОЗАТРАТЫ ПО ИТЕРАЦИИ
30 Простои суммарно Team Idling (заблокирована сборка, не готово тестовое
окружение и т.д.), то он списывает затраты Итерация 1
этого периода в категорию «Простои» • Для анализа причин
простоев
Итерация 2
• Для закладывания
простоев в планы
Итерация 3 работ
• Для контроля за
𝑆𝑈𝑀 (списания по простоям за период)
31 Доля простоев Team Idling %
𝑆𝑈𝑀 (все списания за период)
× 100% Итерация 4 динамикой при
борьбе с простоями
0 50 100 150 200 250

Задачи итерации Техдолг Простои


Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

2.2 Учёт проектных рисков


# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать
Ведение рисков на Risk • Для оценки уровня
32 проекте management
Наличие процесса ведения рисков на проекте Проект Учёт рисков Стратегия Согласование зрелости проектов
нивелирования стратегии
• Для анализа, где
Проект 1 V X X
необходимо
Risk Проект 2 V V V
Командное Согласование рисков и стратегии Проект 3 V V X внедрение учёта
33 согласование рисков management
нивелирования всей командой проекта рисков для более
Проект 4 X X X
approval грамотного
Проект 5 V X X
планирования

РИСКИ ПО ИТЕРАЦИЯМ
• Выявление
Итерация 1 избыточного
Возникшие риски по прогнозу
× 100% прогнозирования
Все риски Итерация 2
Корректность рисков (см. Итерация
Risk predicting Где «Все риски» это сумма:
34 прогнозирования 3)
correctness • Спрогнозированных возникших Итерация 3
• Выявление
рисков
• Спрогнозированных не возникших недостаточного
• Возникших не спрогнозированных Итерация 4
прогнозирования (см.
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Итерация 2)

Выявили корректно Выявили некорректно Возникли, не были выявлены

• Оценить, насколько
Проект Проект 1 Проект 2 Проект 3 Проект 4 корректные решения
Успешно нивелированы Рисков выявлено 42 35 28 70 мы выбираем для
× 100% Рисков со стратегией решения 42 16 26 56
Уровень Все риски в стратегии нивелирования
Risk avoidance Рисков, нивелированных по 14 3 20 18
35 нивелирования
efficacy стратегии
рисков
рисков Рассчитывается на основании стратегии Рисков, стратегия нивелирования по 6 11 3 7 • Найти более
нивелирования которым не помогли эффективные
Уровень нивелирования 70% 21% 87% 72% инструменты
нивелирования
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

2.3 Метрики для прогнозирования трудозатрат по тестированию


# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать
Затраты на тестирование
Соотношение
трудозатрат Test/Dev Effort Затраты на разработку
36 разработчиков и Rate Статистика по доработке Доработка 1 Доработка 2 Доработка 3 Доработка 4 Среднее
Рассчитывается по доработке, итерации,
тестировщиков Затраты на тестирование 168 143 224 130 166
модулю и т.д.
Затраты на разработку 353 279 482 273 347
Затраты на тестирование доработки Соотношение затрат 2.1 1.95 2.15 2.1 2.1
Объём кода доработки
CLOK 16 14.5 20 13 15.9
Test Effort per
37 Затраты ч/ч на KLOC KLOC Затрат на CLOK 10.5 9.9 11.2 10 10.4
Рассчитывается по объёму кода в строках
(KLOC) или с учётом сложности кода Число требований 111 98 192 104 126
(Cyclomatic Complexity)
Затрат на 1 требование 1.5 1.5 1.2 1.25 1.36
Затраты ч/ч на Затраты на тестирование доработки Затраты на проведение тестов
Test Effort per 12 12 11 12 11.5
38 проверку
Req
совместимости на 1 окружении
Число требований в доработке
требования Затраты на проверку инцидентов 6 15 8 3 8

Затраты на 1 Tet Effort per 1 Затраты на тестирование совместимости Число инцидентов 17 32 21 8 19.5
39 тестовое окружение Environment Затраты на 1 инцидент 0.35 0.47 0.38 0.38 0.395
Протестировано окружений
Затраты на разработку тестов 32 28 43 23 31.5
Время, Затраты на создание тестов
Test Effort for 1 Число тестов 140 125 281 116 165.5
40 затрачиваемое на
TC creation Число созданных тестов
создание ТК/ЧЛ Затраты на 1 тест 0.23 0.22 0.16 0.2 0.2
Затраты на валидацию дефектов 11 9.5 17 8 11.375
Затраты на проверку Test Effort for 1 Затраты на проверку инцидентов за период
41 1 инцидента incident submit Число дефектов
Число инцидентов обработано 46 39 64 36 46.25
провалидировано
Затраты на Затраты на валидацию 1 дефекта 0.24 0.24 0.27 0.22 0.24
Test Effort for 1 Затраты на валидацию дефектов
42 валидацию 1
bug validation Число дефектов провалидировано
дефекта

Как использовать:
• Метрики грубой оценки (36,37,38) используются для быстрого получения планируемых трудозатрат исходя из предварительно собранной
статистики. Если на тестирование поступает доработка, содержащая 150 требований, мы можем быстро оценить затраты на её тестирование как
150х1.36 = 204 ч/ч.
• Метрики точной оценки используются при планировании трудозатрат по стратегии тестирования. В стратегии мы указываем, что нам необходимо
создать около 120 тестов, провести тестирование на 4 тестовых окружениях, провалидировать 40 дефектов, и т.д. В оценке мы суммируем затраты
на каждый из этих пунктов, затраты берём исходя из предварительно собранной статистики.
• Анализируя затраты на повторяющиеся активности, мы можем выявить, что некоторые типы задач мы выполняем слишком долго. В этом случае мы
проводим улучшения и оптимизацию процесса, направленные на сокращение затрат, и выносим такие показатели в KPI (например, цель – тратить
на валидацию 1 дефекта не более 10 минут, стратегия – автоматизация создания тестовых данных и окружений, KPI – метрика #42)
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

3. Качество продукта
3.1 Удовлетворение пользователей
# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать

ОЦЕНКИ ПОЛЬЗОВАТЕЛЕЙ
5
AVG (Пользовательские оценки за период) • KPI проекта
4
Можно собирать в: • Выявление источников
• Прямых опросах 3 низких оценок (см.
Средняя оценка Average Client
43 • Маркетах 2 диаграмму – проблемы в
пользователей Rating
Используется для оценки: iOS версии)
• Статика по релизу 1 • Отслеживание динамики
• Динамика по итерациям 0 внедрения изменений
Релиз 1 Релиз 2 Релиз 3 Релиз 4

Прямые опросы AppStore GooglePlay

Распределение Оценка 1 2 3 4 5 • Анализ исключительно


Clients Grades Сбор «сырых» данных по числу каждого типа
44 пользовательских
Evaluation оценки Число оценок 27 32 194 140 16
высоких и исключительно
оценок низких
Новых запросов от New
45 пользователей за Improvement • Внедрение очереди «запросы на улучшение ЗАПРОСЫ НА УЛУЧШЕНИЕ
Принято
период Requests от клиентов» в таск-трекере • Оценить уровень
заказчиком
удовлетворённости
Внедрено Improvement • Контроль статусов запросов: 13% Подвешено
45% клиентов внедрением
46 пользовательских Requests o «подвешено»
доработок
запросов за период Implemented o «в работе» • Спланировать работы по
Opened o «реализовано» 38%
Открытых внедрению запросов от
47 Improvement o «принято заказчиком» внедрено
пользовательских пользователей
запросов Requests • Отфильтровать давно
Реализовано подвешенные доработки и
Рейтинг внедрения Improvement Реализовано улучшений 26% принять по ним решения
48 пользовательских Ratio
× 100%
Запрошено улучшений В работе
запросов 16%

Продажи
Не принято сборок
Принято
14%
заказчиком
29% • KPI проектной команды
• Анализ причин непринятия
Customer Сборок принято заказчиком
Прохождение сборки
49 приёмки заказчиком Acceptance × 100%
• Инструмент аргументации
Всего сборок за период
Ratio
при внедрении решений по
углублению тестирования
Принято с
комментариями
57%
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

3.2 Дефекты в продукте


# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать

• Оценить необходимость в исправлении


Дефекты в продукте ДЕФЕКТЫ ПО СТАТУСАМ И ПРИОРИТЕТАМ дефектов
50 по статусам Defects by Status
• Спланировать затраты на достижение
требуемого уровня качества по дефектам

• Оценить приоритетность заведения багов


Дефекты в продукте Defects by тестировщиками
51 по критичности Severity • Оценить количество скрытых дефектов (при
заведении только высококритичных)
Дефектов в категории
× 100%
Всего дефектов
• Оценить качество отдельных функциональных
Дефекты в продукте Defects by областей
52 по области Functional Area Прио 3 Прио 2 Прио 1 - открыты Прио 1 - исправлены
• Принять решения о расширении подкоманд
разработки и/или тестирования
Возможен сбор более ОТКРЫТО ДЕФЕКТОВ ПО ОКРУЖЕНИЯМ
комплексных метрик, например:
120
статусы дефектов по приоритетам,
Дефекты в продукте Defects by Test критичность дефектов по 100 • Оценить качество продукта по соответствию
53 по типу тестов Type областям, и т.д. нефункциональным требованиям
80

60

40

20 • Оценить качество сборок по окружениям


Дефекты в продукте Defects by
54 • Принять решение о сокращении или повышении
по платформам Environment 0
Windows iOS Android Web-версия объёмов тестирования по окружениям

Critical Major Minor

ДИНАМИКА ПРИРОСТА ДЕФЕКТОВ


120 80
100 70
Прирост дефектов = Заведено 80 60
дефектов – Исправлено дефектов 60 50
• Отслеживать динамику качества продукта по
40 40
Число открытых дефектов = дефектам
55 Динамика дефектов Defects Dynamics 20 30 • Прогнозировать готовность продукта к релизу
Число дефектов, открытых на
начало периода, + Прирост 0 20 (обнаружение момента «сходимости дефектов»)
дефектов -20 Итерация 1 Итерация 2 Итерация 3 Итерация 4 Итерация 5 Итерация 6 10
-40 0

Исправлено за период Заведено


Прирост Число открытых дефектов
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

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


# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать

Пройдено тестов • Показывает процент работающей


Passed Test
56 Успешных тестов Cases
× 100% РЕЗУЛЬТАТЫ ЗАПУСКА ТЕСТОВ функциональности (в комбинации
Запущено тестов с оценкой тестового покрытия!)

Упало тестов Не запускалось Успешно


Failed Test • Показывает качество и
57 Упавших тестов Cases
× 100% 41% 30%
стабильность ПО
Запущено тестов

• Показывает объём задач,


Заблокированных Blocked Test Заблокировано тестов необходимых для выполнения
58 тестов Cases
× 100%
после получения новой сборки на
Запущено тестов
тестирование
Ошибки • Для оценки оставшихся работ по
Executed Test Запущено тестов Заблокировано 17% тестированию
59 Запущено тестов Cases × 100% 12% • Для оценки достоверности
Всего тестов
данных по метрикам 56-58

РЕЗУЛЬТАТЫ ТЕСТИРОВАНИЯ В %
Безопасность
При наличии категорий в тестах, используется
для оценки различных аспектов качества:
Производительность • Оценка качества различных
Результаты
Test Results by GUI категорий ПО
60 тестирования по • Типы тестов (функц, произв, нагрузка и т.д.)
Category • Распределение ресурсов в
категориям • По приоритетам тестов Установка
наиболее проблемные области
• По областям функциональности Расчёты данных

0% 20% 40% 60% 80% 100%

Успешно Упали Заблокированы

1. В системе ведения требований указываются


ссылки на тесты, покрывающие это ГОТОВНОСТЬ ТРЕБОВАНИЙ ПО СТАТУСАМ ТЕСТОВ
требование
2. По результатам выполнения тестов Требования 1 прио
проставляется статус готовности требования: • Для оценки оставшихся объёмов
• Готово - все тесты по требованию тестирования
Готовность Requirements пройдены успешно Требования 2 прио • Для оценки рисков при принятии
61 требований по Readiness by • Ошибки - часть тестов по требованию решения о релизе
тестам Tests упали • Для приоритезации задач по
Требования 3 прио
• Не работает - все тесты по требованию тестированию и исправлению
упали дефектов
• Не проверено - тесты по требованию не 0 50 100 150 200 250 300

запускались Готово Ошибки Не работает Не проверено Неизвестно


• Неизвестно - к требованию не привязаны
тесты
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

3.4 Характеристики качества ПО – 1/4


# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать

Сборка
Операция
7.1.132 7.1.134 7.1.141
Открытие файла 1.5 1.5 1.5
Оценка скорости работы основных Закрытие файла 2 7 7
бизнес опций (загрузка ключевых Сохранение файла 4.5 4.2 3.9
страниц, выполнение ключевых Архивация 11 9 6.8
операций или запросов). • Для выявления регресса в
• Изменение скорости работы производительности
Производительность в Dynamical СКОРОСТЬ ВЫПОЛНЕНИЯ ОПЕРАЦИЙ • Для оценки улучшений
62 динамике performance
основных элементов
• Для оценки изменения
приложения. 12
10
скорости работы
• Динамика изменения скорости ключевого функционала
8
работы основных элементов,
6
относительно целевого
4
уровня. 2
0
132 134 141 146

Откр Закр Сохр Арх

1. Оценка скорости работы


Параметр сравнения Наш продукт Конкурент 1 Конкурент 2
основных бизнес-сценариев в
сравнении с показателями Скорость открытия • Для маркетингового
2,4 2,8 6
файлов, сек продвижения
конкурентов.
Скорость закрытия • Для обнаружения зоны
• По минимальному количеству 16 10 11,2
файлов, сек развития
действий пользователя. GOMS для создания
19 18 26 • Для обоснования наличия
Производительность в Performance • По скорости выполнения отчёта
дефектов
63 сравнении с compared to 2. Сравнение нескоростных Размер архива с
4 5 9 производительности
конкурентами competitors ключевых параметров тестовыми данными,
• Выявляя наилучшие
производительности, таких как Мб
значения среди
• Коэффициент сжатия при Процент
1,7% 0,8% 6,4% конкурентов, мы
архивации пользовательских
определяем, к чему
ошибок
• Допускаемые пользователями можно стремиться
ошибки
• Число одновременных
подключений и т.д.
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

3.4 Характеристики качества ПО – 2/4


# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать

ВРЕМЯ ОТКЛИКА (СЕК)


1.4 1.3

1.2
1 • Оценить соответствие
Скорость отклика при разных 0.8 требованиям по нагрузке
Производительность Performance нагрузках, в подавляющем 0.6 • Для оценки возможности
64 под нагрузкой under load большинстве случаев измеряется
0.4
масштабирования
0.4
автоматизировано (JMeter, Grinder, 0.1 0.11 0.13 приложения по
0.2
HP Performance Center и т.д.) количеству пользователей
0
10 25 50 100 200
Количество одновременных подключений

СТАБИЛЬНОСТЬ ПОД НАГРУЗКОЙ


• Для определения
300 0.4
отказоустойчивости

Число одновременных запросов


1. Автоматизация множества 250 0.35
250 34% системы в стрессовых
одновременных запросов к
0.3 ситуациях
серверу
Стабильность под Stability under 200
0.25
• Соблюдение SLA
65 нагрузкой load
2. Сбор статистики, какой % (англ. Service Level Agree
запросов проходит успешно, 150 0.2
ment - Соглашение об
и какой вызывает ошибки 100 0.15
100 85 уровне предоставления
50 0.1 услуги)
7%
50 25 • Определить, на каком
10 2% 0.05
0 0 7
количестве
0 0
10 25 50 100 500 одновременных
Успешность выполнения подключений
проявляются ошибки
Кол-во ответов Кол-во ошибок % ошибок
Ошибки под Failures during Ошибочных откликов
66 нагрузкой load tests
× 100%
Всего запросов
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

3.4 Характеристики качества ПО – 3/4


# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать
Процент поддерживаемых
платформ, окружений, браузеров,
версий ОС, разрешений экрана и ПОДДЕРЖКА ЗАЯВЛЕННЫХ БРАУЗЕРОВ
т.д.
Список возможных статусов по
окружению может быть разным, • Для оценки рисков по
минимальный набор статусов: непротестированным
• Поддерживается окружениям
67 Совместимость Compatibility
• Не поддерживается • Для выявления
неподдерживаемых
По каждому статусу проводится окружений
расчёт:

Статус тестирования
× 100% Поддерживаемые Есть ошибки Не поддерживается Не тестировалось
Всего окружений

Параметр Модули B-1 B-2 B-3 B-4 B-5 AVG


M-1 14 9 11 13 11 11.6
Количество
M-2 4 3 2 4 1 2.8
регрессионных дефектов
M-3 2 3 3 1 0 1.8
Количество улучшений в M-1 4 2 1 3 1 2.2
реализованный M-2 4 3 2 4 3 3.2
функционал M-3 10 9 10 8 9 9.2

МОДИФИЦИРУЕМОСТЬ ПРОДУКТА
25
68 Модифицируемость Modifiability Проведён
20 рефакторинг

15

10

0
Март Апрель Май Июнь Июль Август

Улучшений/спринт Дефектов/спринт
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

3.4 Характеристики качества ПО – 4/4


# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать
Модели расчетов по GOMS
СКОРОСТЬ СОХРАНЕНИЯ ФАЙЛА, РАСЧЁТ ПО GOMS
16
𝑡 = 𝐻 + 𝐾 + 𝑃 + 𝑀 где, 14 • Для поиска неудачных
12 (долгих по выполнению)
t – время, затраченное на 10 реализаций в интерфейсе
Юзабилити выполнение действия 8 • Для выбора варианта
Usability measured
69 отдельных форм по
by GOMS
H – перенос руки на мышь 6 реализации экранной
GOMS K – нажатие клавиши клавиатуры 4 формы
или мыши 2 • Для сравнительного анализа
P – перенос курсора 0 продукта с конкурентами
В левом меню В контекстном меню Новый вариант меню от У конкурентов
M – обдумывание следующего шага
Семёна

H K P M

СОХРАНЕНИЕ ФАЙЛОВ ПОЛЬЗОВАТЕЛЯМИ


• Выполнение пользователем
заданных сценариев, подсчёт его • Для приоритезации
ошибок и вопросов, оценка юзабилити-доработок по
Юзабилити сценариям
успешности выполнения сценариев Сценарий №3
сценариев: Scenarios • Для выявления
• Сценарий считается успешным, если
70 успешность completion by непонятных мест и
выполнения users фактический результат прохождения Сценарий №2 юзабилити-ошибок
пользователями пользователем сценария совпадает с • Для обоснования
ожидаемым Сценарий №1 необходимости
исправлять ошибки
Статус выполнения 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
× 100%
Пользователей тестировало Пройдено успешно Вызвали вопросы Ошибки

ОБРАЩЕНИЯ ПОЛЬЗОВАТЕЛЕЙ
Сохранение файлов
7%
Сбор статистики по обращениям в Архивация
14%
• Выявить зоны, в которых
техническую поддержку в статусе необходимо проведение
«ошибка пользователя» (обращения, в юзабилити-экспертизы
Структура Users complains
которых причиной ошибки было • Обнаружить ошибки и
71 пользовательских by product
нелогичности, которые
непонимание пользователя, а не Формирование
обращений modules отчёта незаметны опытным
дефекты в продукте)
54% участникам проекта,
Обращений по модулю
× 100% Открытие документа привыкшим к продукту
Всего обращений 25%
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

4. Эффективность тестирования
4.1 Скорость тестирования
# Метрика рус. Метрика Как рассчитывать Визуализация метрики Как использовать
англ.
Сборка Дата готовности Дата начала Дата завершения
тестирования тестирования
14.1 29.11 03.12 11.12
Время на 𝐴𝑉𝐺 (Дата завершения тестирования 14.2 21.12 21.12 29.12 • Статистика для
72 Time to test − Дата начала тестирования) 14.3 18.01 24.01 12.02 последующего
тестирование
the build планирования релизов
сборки Измеряется в рабочих днях 14.4 27.02 01.03 10.03
• Для определения зон
развития / повышения
СРЕДНИЕ ЗНАЧЕНИЯ ПОКВАРТАЛЬНО скорости
12 • Для поиска отклонений и
10
выявления причин
(простоев и срывов
8
сроков)
𝐴𝑉𝐺 (Дата начала тестирования 6
• Для оценки динамики и
Время до начала Time to start − Дата готовности сборки ) 4
73 влияния внедрённых
тестирования testing Измеряется в рабочих днях 2 изменений
0
1 кв 2 кв 3 кв 4 кв

Время на тестирование Время до начала тестирования

РАСПРЕДЕЛЕНИЕ ДЕФЕКТОВ ПО СКОРОСТИ


ОБНАРУЖЕНИЯ В ДНЯХ

𝐴𝑉𝐺 (Дата заведения дефекта


− Дата внедрения дефекта в код )

Число дефектов
Для внедрения этой метрики необходимо добавить в • Для выяснения средних
баг-трекер поле «дата внедрения дефекта». значений (для планирования,
Время на Разработчик заполняет это поле в момент смены и оценки рисков)
обнаружение Time to start статуса дефекта на «исправлено» (в момент • Для обнаружения критичных
74 критического testing исправления он уже знает, какой именно коммит отклонения и выяснения
дефекта вызвал этот дефект, и может посмотреть, когда он был причин, почему так долго не
произведён). 0 1 2 3 4 5 6 7 8 9 10 могли обнаружить критичный
Дней на обнаружение дефект
Так как сбор этой метрики подразумевает
дополнительные затраты, обычно целесообразно
собирать эту статистику только по критичным Дефект Дней Причина долгого обнаружения Решение
17382 9 Был заблокирован для Убрать из статистики
дефектам.
обнаружения
17315 11 Не знали о влиянии параметра Провести ревью тестов по модулю с
в ТА архитектором, возможно, ещё что-то
упустили
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

4.2 Финансовые показатели


# Метрика рус. Метрика Как рассчитывать Визуализация метрики Как использовать
Общая стоимость тестирования
Стоимость Стоимость Стоимость
Виды расходов на сотрудника в месяц сотрудника сотрудника сотрудника Всего на команду/проект ( руб.)
1 ( руб.) 2 ( руб.) 3 ( руб.)
Заработная плата(gross) 80 000 85 000 83 000 245 000
Оплата труда ( net ) 69 600 73 950 72 210 215 760
Налоги с з/пл.
ПФР - 22% 17 600 18 700 18 260 54 560
Фонд оплаты труда команды тестирования, ФМС - 2.9% 2 320 2 465 2 407 7 192
включая все необходимые затраты для ФФОМС - 5.1% 4 080 4 435 4 233 12 648
обеспечения деятельности сотрудников. НДФЛ - 13% 10 400 11 050 10 790 32 240 • Для бюджетирования и
Отпуск сотрудника (1/12 с з/пл.) 6 667 7 083 6 917 20 667 расчётов при запросе
Организационные расходы расширения
При расчёте необходимо взаимодействие с аренда офиса( по СанНПину на каждого сотрудника должно
ФОТ (Фонд Total Cost of фин. департаментом и бухгалтерией, для быть не менее 4.5 кв/м площади офиса), из расчета средней 4 500 4 500 4 500 13 500 • Для контроля при
ставки аренды 1000 руб/кв.м.
75 оплаты труда) в Testing учёта налогов, отпусков, больничных, необходимости
офисных платежей, покупки оборудования, ПК и оргтехника, мебель. В среднем 1/20 от з/пл. сокращения
тестировании Labor сотрудника
4 000 4 250 4 150 12 400
сервисов, социальных выплат. Обычно, Административные расходы
сумма дополнительных затрат на команду
З/плата сотрудников HR: поиск, найм, увольнение, обучение,
варьируется от 50 до 120% от суммы сопровождение
заработных плат. З/плата бухгалтерии: найм, увольнение, сопровождение, 2 000 2 000 2 000 6 000
больничные
З/плата руководителя (начальника) сотрудника :
сопровождение, контроль, управление
Повышение квалификации сотрудника (курсы, тренинги пр.)
В среднем 1/12 от средней цены курса для ручного
тестировщика( 15 000 руб.) при условии прохождении 1-го 1 250 1 250 1 250 3 250
курса в год
ИТОГО в месяц: 122 417 129 583 126 717 378 717
Стоимость команды тестирования за месяц: 378 717

ЗАТРАТЫ НА ТЕСТИРОВАНИЕ, Т.Р./МЕС


• Для бюджетирования
ФОТ команды + тестовое оборудование Команда 1 проекта и команды
Затраты на Total Cost of + тестовые окружения тестирования
76 тестирование Testing + используемый инструментарий Команда 2
• Для обоснования
+ внешние подрядчики
0 100 200 300 400 500 600 700 800 расширения
ФОТ Оборудование Инструменты Дата-центр Подрядчики

Затраты на тестирование • Для оценки


Cтоимость Сумма экономической
77 Cost per Bug Число дефектов Полная
затрат на Общее кол-во Стоимость Стоимость
обнаружения Наименование Кол-во Дата стоимость оправданности
Find проекта сотрудников
Дата начала
завершения тестирования
исправление выявленных обнаружения исправления
ошибки Рассчитывается за период (руб.)
дефектов дефектов(шт.) дефекта (руб.) дефекта тестирования
(руб.)
Затраты на исправление дефектов 4 097,70 • Для поиска затратных
78 Cтоимость
Проект 1 3 01.08.2020 30.08.2020 710 400,13 504 416,32 158 4 476,30
Cost per Bug Число дефектов для исправления 4 932,64 в исправлении
исправления Проект 2 3 01.08.2020 30.08.2020 563 109,62 914 216,19 321 1 754,23
Fix 2 791,12 дефектов и анализа
ошибки Проект 3 3 01.08.2020 30.08.2020 314 043,90 92 116,70 38 8 264,31
причин
Рассчитывается за период
400
200 • Для планирования
Отклонение Testing Факт затрат − План затрат
79 0 бюджета в будущем
бюджета Budget × 100%
План затрат Релиз 1 Релиз 2 Релиз 3 Релиз 4 • Для анализа причин
тестирования Variance -200
отклонений
План Факт Отклонение
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

4.3 Работа с дефектами


# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать

Исправлено дефектов СТАТУСЫ ДЕФЕКТОВ


× 100%
Заведено дефектов
80 % исправленных Исправлено • Для выявления причин
Bugs Fix Ratio 14%
дефектов НЕисправления
Отклонено
Расчёт проводится за период или по 11% дефектов.
версии/итерации • Для оценки статуса
тестирования по
Отклонено дефектов Открыто
× 100% 53% модулям,
Заведено дефектов направлениям, типам
81 % отклонённых Bugs Reject Отложено тестов
дефектов Ratio 22%
Расчёт проводится за период или по
версии/итерации

ПРИЧИНЫ ОТКЛОНЕНИЯ ДЕФЕКТОВ


Для сбора этой метрики требуется выпадающий
список в баг-трекере, необходимый для Семён
заполнения разработчиком при отклонении • Чтобы найти способ
Настя сократить число
дефекта, например:
отклонённых дефектов
82 Причины отклонения Rejection • не воспроизводится Катя (решить проблему,
дефектов по группам Causes • неправильное понимание ожидаемого результата
• исправление невозможно Среднее вызывающую
• ошибка в требованиях наибольшее число
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% отклонений)
Причина отклонения
× 100% Некорректное описание Ошибка в требованиях
Всего отклонено
Неправильное понимание ОР Невозможно исправить

• Оценить качество
ОЦЕНКИ ДЕФЕКТОВ РАЗРАБОТЧИКАМИ заведения дефектов на
5 проекте, в команде, у
4 отдельного сотрудника
• Выяснить причины
Bugs Субъективная оценка в баг-трекере, в разрезе 3
83 Качество заведения анормально низких
Submission разработчиков, тестировщиков, типов дефектов и 2
дефектов оценок для решения
Quality т.д. 1 • Учитывать
0 разработчиков, которые
Разработчик 1 Разработчик 2 Разработчик 3 Разработчик 4 могут завышать или
Катя Семён Настя
занижать оценки
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

4.4 Автоматизированное тестирование – 1/2


# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать
Время прохождения автотестов:
ДИНАМИКА РАЗРАБОТКИ АВТОТЕСТОВ
𝐴𝑉𝐺 (Время готовности отчёта по автотестам
− Время запуска автотестов) 200

Скорость Autotests
Среднее время на выполнение 1 теста: 150
84 прохождения execution
автотестов speed Время прохождения автотестов • Для планирования
100
Число автотестов тестовых циклов
50 • Для принятия решения об
эффективности автотестов
0 и их расширении
Релиз 1 Релиз 2 Релиз 3 Релиз 4 • Для обнаружения проблем
-50 со скоростью автотестов
Затраты на автоматизацию за период • Для своевременного
Актуальных тестов Новых тестов Сломано тестов Итого обнаружения регресса
Число новых автотестов за период
Autotests Релиз Время на Время на Затраты на Затраты на производительности
Скорость разработки
85 implementation Может считаться в разрезе сотрудников, автотестирование прохождение 1 поддержку 1 разработку 1
автотестов
speed команд, типов автотестов и т.д. сборки теста автотеста автотеста
Релиз 1 9ч 7 мин 0,2 ч/ч 3,4 ч/ч
Релиз 2 9ч 6,5 мин 0,2 ч/ч 4,2 ч/ч
Релиз 3 9,3 ч 7,2 мин 0,2 ч/ч 17 ч/ч
Релиз 4 9,5 ч 7,6 мин 0,3 ч/ч 6 ч/ч

Успешно пройдено автотестов РЕЗУЛЬТАТЫ ЗАПУСКА АВТОТЕСТОВ


× 100%
Всего автотестов • Для планирования
трудозатрат на поддержку
Пользовательские сценарии
Измеряется как среднее за период или релиз и анализ автотестов
Может группироваться по разработчику • Для оценочного сравнения
Стабильность Autotests Тесты GUI
86 автотестов, функциональной области стабильности автотестов
автотестов Stability
продукта, и т.д. по категориям
Тесты API
(разработчик, тип тестов,
функц. область и т.д.)
0 20 40 60 80 100 120 140 160 180

Предупреждения Ошибки Успех

• Для поиска ключевой


ПРИЧИНЫ ПАДЕНИЯ АВТОТЕСТОВ причины нестабильности
Ошибки в коде
Другое
автотестов
продукта
Заполнение из выпадающего списка каждый 20% 20% • Для решения проблемы,
раз, когда вносятся изменения в автотесты, вызывающей наибольшее
Причины число падений
для фиксации причины изменений, и
Autotests • В редких случаях – для
87 нестабильности дальнейший расчёт доли каждой причины: Изменения
Failures Causes реализации Ошибки в коде
принятия решения о смене
тестов по категориям
продукта автотестов стратегии автоматизации
Причина падения автотестов
× 100% 11% 17% (выбор других
Всего падений автотестов интерфейсов,
инструментов, отказ от
Изменения
локаторов автоматизации новой
32% функциональности и т.д.)
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

# Метрика рус. Метрика англ. Как рассчитывать Визуализация метрики Как использовать
При анализе причин падения автотестов
Ложные Autotesting
88 выявлять все результаты, которые не ЛОЖНЫЕ РЕЗУЛЬТАТЫ АВТОТЕСТОВ
срабатывания False Alarms
были вызваны ошибками в продукте
100% • Для оценки уровня
При регистрации дефектов в областях,
90% достоверности
покрытых автотестами, уточнять, почему автотестов
дефект не был зарегистрирован по 80%
• Для оценки
итогам запуска автотестов. Если 70%
возможности
обнаруживаются автотесты, которые 60% принятия решений о
пропускают ошибки (нехватка проверок, 50% релизе продукта по
Ложные ошибки в логике), то такие ситуации 40% итогам автотестов
Autotesting (насколько
89 прохождения помечаются как ложные прохождения 30%
False Positives достоверны
тестов тестов. 20%
показатели
10% автотестов до
!Важно
0% проведения ручного
Ложные прохождения, как и пропуски в Продукт 1 Продукт 2 Продукт 3 Продукт 4 анализа)
ручном тестировании, невозможно
выявить все, и это будет примерная Корректный результат Ложные срабатывания Ложные прохождения

оценка.
Выгода от внедрения автотестов
Затраты на внедрение автотестов
× 100%
Где выгода от внедрения учитывает все • Для принятия
решений о внедрении
затраты на ручное тестирование, а
автоматизированного
Экономическая Autotests затраты на автоматизацию включают в
тестирования
90 оправданность Return of себя • Для выбора и
автотестов Investment • Разработку автотестов приоритезации
• Поддержку и актуализацию автотестов исходя из
автотестов их экономической
• Запуски и анализ результатов оправданности
автоматизированного
тестирования
Функций тестироуется автоматизировано
× 100% Есть автотесты Нет автотестов Невозможны автотесты
Всего функций в продукте
Покрытие
Features
автотестами В качестве функций могут выступать Функциональные требования
91 Coverage by
функционала функциональные требования,
Autotests • Для контроля
продукта пользовательские сценарии, области и
Автоматизировано Не автоматизировано следования плану
модули продукта и т.д.
• Для оценки
Покрытие возможности
Code Coverage Регресс тесты 1 прио
92 автотестами кода См. метрики #9-12 сокращения ручного
by Autotests
продукта Регресс тесты 2 прио тестирования
Regression • Для поиска зон, в
Автоматизировано
Coverage by Автоматизировано регр. −х тестов Рергресс тесты 3 прио которых необходимо
93 регрессионных × 100%
Coverage by Всего регрессионных тестов расширять
тестов автоматизацию
Autotests Реализовано по плану Запланировано, не реализовано Не планировалось
тестов
Выполнение
плана Automation Автоматизировано тестов План автоматизации
94 × 100%
автоматизации Plan Fulfilment План автоматизировать тестов
тестирования
Курс «QA Аудит» УЦ Лаборатория Качества > Неделя 3 > Дополнительные материалы > Список проектных метрик

Авторы документа с непередаваемым


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

Пожалуйста, свяжитесь с авторами курса


«Аудит процесса тестирования», если:
• У вас остались вопросы по внедрению
и использованию метрик,
рассмотренных в этом документе
• Вы не нашли в этом списке метрики,
которая вам нужна для оценки
рабочей деятельности.
Мы обязательно поможем решить эти задачи!

И уж тем более свяжитесь с нами, если вы


измеряете хотя бы одну полезную метрику,
которая отсутствует в этом документе. Мы
обязательно протестируем её в деле, и
ua.sacred добавим в следующую версию документа.

natalya.rukol

Вам также может понравиться