Метрики по обеспечению качества, метрики тестирования

Лекция

Привет, Вы узнаете о том , что такое метрики по обеспечению качества, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое метрики по обеспечению качества, метрики тестирования , настоятельно рекомендую прочитать все из категории Качество и тестирование программного обеспечения. Quality Assurance..

Согласно международному стандарту ISO 14598:

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

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

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

Создание, использование и анализ метрик

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

Метрики по тестовым случаям (Test Cases)
Метрики по багам / дефектам
Метрики по задачам

Давайте более детально разберем каждую из них:

Метрики по тест кейсам

Название	Описание
Passed/Failed Test Cases	Метрика показывает результаты прохождения тест кейсов, а именно отношение количества удачно пройденных к завершившимся с ошибками. В идеале, к концу проекта, количество провальных тестов стремиться к нулю
Not Run Test Cases	Метрика показывает количество тест кейсов, которые еще необходимо выполнить в данной фазе тестирования. Имея данную информацию, мы можем проанализировать и выявить причины, по которым тест не были проведены

Метрики по багам

Название	Описание
Open/Closed Bugs	Метрика показывает отношение количества открытых багов к закрытым (исправленным и перепроверенным)
Reopened/Closed Bugs	Метрика показывает отношение количества переоткрытых багов к закрытым (исправленным и перепроверенным)
Rejected/Opened Bugs	Метрика показывает отношение количества отклоненных багов к открытым
Bugs by Severity	Количество багов по серьезности
Bugs by Priority	Количество багов по приоритету

Хотим отметить, что метрики "Open/Closed Bugs", "Bugs by Severity" и "Bugs by Priority" хорошо визуализируют степень приближения продукта к достижению критериев качества по багам. Имеятребования к количеству открытых багов, после каждой итерации тестирования мы сравниваем их с реальными данными, тем самым видя места, где нам нужно прибавить, для скорейшего достижения цели.

Метрики "Reopened/Closed Bugs" и "Rejected/Opened Bugs" направлены на отслеживание работы отдельных участников групп разработки и тестирования.

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

Требования к функции можно трактовать по разному
Тестировщик не точно описал проблему
Некачественное поверхностное решение проблемы (фикс бага)

Второй пример покажет для чего необходима метрика "Rejected/Opened Bugs":
Мы наблюдаем, что процент отклоненных (Rejected) багов очень большой. Это может значить:

Требования к функции можно трактовать по разному
Тестировщик не точно описал проблему
Разработчик не желает исправлять допущенную им ошибку или не считает, что это на самом деле ошибка. (Эта проблема является прямым следствием 2-ой, возникшей из-за не точного описания)

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

Метрики по задачам

Название	Описание
Deployment tasks	Метрика показывает количество и результаты установок приложения. Процедура установки приложения была описана в статье Процедура проведения установки новой версии ПО (Deployment WorkFlow). В случае, если количество отклоненных командой тестирования версий будет критически высоким, рекомендуется срочно проанализировать и выявить причины, а также в кротчайшие сроки решить имеющуюся проблему.
Still Opened Tasks	Метрика показывает количество все еще открытых задач. К окончанию проекта все задачи должны быть закрыты. Под задачами понимаем следующие виды работ: написание документации (архитектура, требования, планы), имплементация новых модули или изменение существующих по запросам на изменения, работы по настройке стендов, различные исследования и многое другое

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

1.1 Пропуски дефектов

#	Метрика рус.	Метрика англ.	Как рассчитывать	Визуализация метрики	Как использовать
1	Количество дефектов, пропущенных в продуктив	Bugs Leakage	Дефектов, зарегистрированных на пром. среде Всего зарегистрировано дефектов× 100% Для сбора метрики необходимо добавить поле в баг-трекер «на каком окружении был обнаружен дефект»		• Как один из KPI тестирования • Для анализа причин ненахождения дефектов в тестовой сборке
2	% дефектов, найденных пользователями	Bugs Reported by Users	Дефектов выявлено пользователями Всего зарегистрировано дефектов× 100%		• Как один из KPI тестирования • Для анализа, какие дефекты критичны для пользователей
3	% дефектов, найденных не тестировщиками	Bugs Reported not by Testers	Дефектов,выявленных не тестировщиками Всего зарегистрировано дефектов × 100%		• Как один из KPI тестирования • Для анализа, почему другие участники процесса находят ошибки, пропущенные тестировщиками
4	Пропуски дефектов по категориям	Bugs Leakage by Category	Дефектов с пром среды по категории Всего дефектов по категории× 100%		Для анализа, в каких областях необходимо развивать тестирование • В качестве категорий могут выступать уровни тестирования, типы тестирования, зоны функциональности и т.д.

#	Метрика рус.	Метрика англ.	Как рассчитывать	Визуализация метрики	Как использовать
5	Покрытие требований тестами	Requirements Coverage	Требований с тестами Всего требований× 100% Для расчета этой метрики необходимо определить критерий «требований с тестами». Это может быть «хотя бы 1 тест», «хотя бы 1 тест на каждую границу и т.д.». Рассчитывается в системе ведения требований, по статусу или по наличию ссылки на тесты.		• Для планирования расширения тестового покрытия • Для оценки рисков пропуска дефектов
6	Подтвержденное покрытие требований тестами	Approved Requirements Coverage	Требований с утвержденными тестами Всего требований× 100% Для расчета этой метрики необходимо согласование тестовых наборов по каждому требованию. Чаще всего такое согласование происходит с аналитиком и разработчиком, ответственным за реализацию требования. По итогам обсуждения в системе ведения требований проставляется статус «тесты согласованы»
7	Покрытие требований исследовательскими тестами	ET Requirements Coverage	Постановка задач на исследовательское тестирование по требованиям или пользовательским сценариям и расчет % требований, по которым было проведено тестирование.		• Для оценки готовности к релизу • Для планирования затрат на тестирование
8	Покрытие пользовательских сценариев тестами	User Stories Test Coverage
9	Покрытие кода по функциям	Code Coverage	• Выбор инструмента оценки, исходя из потребностей и архитектуры проекта • Создание инструментальной сборки • Проведение тестов на этой сборке для анализа покрытия Оценка покрытия кода возможна как для автоматизированных, так и для ручных тестов!		• Для оценки уровня покрытия • Для исследования влияющих параметров, не обозначенных в документации, но влияющих на выполнение кода продукта • Для расширения тестового покрытия
10	Покрытие кода по условиям	Alternatives Coverage
11	Покрытие кода по решениям	Decision Coverage
12	Покрытие строк кода	Path Coverage

#	Метрика рус.	Метрика англ.	Как рассчитывать	Визуализация метрики						Как использовать
13	Покрытие GUI	GUI Coverage	Объектов покрыто тестами Всего объектов× 100% Где в качестве объектов могут выступать: • Экранные формы • Элементы графического интерфейса • Функции API • Интерфейсы интеграции • И т.д.							• Выявить зоны рисков и «узкие горлышки» • Оценить статус тестирования
14	Покрытие API	API Coverage
15	Покрытие интеграций	Integration Coverage
16	Покрытие требований производительности	Performance Coverage	Требований по группе покрыто тестами Всего требований в группе× 100% Где в качестве группы могут выступать: • Разные типы требования • Разные модули • Разные функциональные области • И т.д.							• Для планирования расширения тестового покрытия • Для оценки рисков пропуска дефектов
17	Покрытие требований нагрузки	Load Coverage
18	Покрытие поддерживаемых форматов данных	Data Coverage
19	Покрытие пользовательских сценариев юзабилити-тестами	Use-Cases Covered by Usability Tests	• Проведение юзабилити-экспертизы с привлечением ЦА с анализом возможности выполнения сценариев • Проведение внутренней UX-экспертизы по удобству выполнения пользовательских сценариев							• Оценить юзабилити-риски • Принять решение, какие тесты необходимо провести
20	Покрытие окружений уникальными тестами	Environmental Unique Tests Coverage	• Анализ рисков, связанных с окружениями • Подготовка тестов, зависящих от окружения • Согласование достаточности тестов, зависящих от окружения		Платформа	Windows	Mac	Android	Unix	• Оценить качество планирования тестов, зависящих от окружения • Определить необходимость дополнительного анализа • Запланировать расширение тестового покрытия
					Применимо общих тестов	1350	1350	340	940
					Возможно выполнить только на этой платформе	42	60	160	36
					Уникальные риски на этой платформе	28	n/a	112	n/a
					Согласованы уникальные тесты с командой разработки	X	X	V	X
21	Проведение тестов на поддерживаемых окружениях	Environments Coverage	Проведено тестов на платформе Всего тестов отобрано для платформы× 100%							• Оценить риски, связанные с окружениями • Запланировать дополнительные тесты окружения

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

#	Метрика рус.	Метрика англ.	Как рассчитывать	Визуализация метрики				Как использовать
22	Средняя экспертная оценка тестов	Expert test cases evaluation	AVG (Оценки тестов в системе хранения тестов) Тесты можно оценивать: • Одной оценкой • По различным шкалам Оценки можно категоризировать: • По сотрудникам • По группам • По типам или областям тестов • И т.д.					• Для выявления слабых зон в тестовом покрытии • Для обнаружения нехватки квалификации и принятия решений о дополнительном обучении • Для выявления тестов, которые необходимо улучшить
23	Актуальность тестов	Test cases relevance	AVG (Последняя версия документации - Последняя версия документации, использованная в тестах) или Тестов, акт.в последней версии Общее число тестов× 100%					• Оценить риски использования текущих тестов • Определить необходимость выделения ресурсов на актуализацию тестов
24	Рейтинг обнаружения дефектов тестами	TC bugs detecting ratio	Выполнено тестов Зарегистрировано дефектов Считается по версии, итерации или периоду времени Возможна категоризация статистики по: • По сотрудникам (тест-дизайнерам) • По зонам функциональности • По типам тестов • И т.д.					• Выявить тесты, подверженные эффекту пестицида (см. Продукт 1) • Оценить эффективность внедрения новых техник и подходов (см. Продукт 2)
25	Скорость обнаружения дефектов по тест кейсам	TC bugs detection speed	Зарегистрировано дефектов Затрачено времени на тестирование по ТК		Проект	Проект 1	Проект 2	• Выявить эффективные тесты, скорость обнаружения ошибок, по которым выше, чем в ИТ • Выявить неэффективные тесты, по которым находится мало дефектов
					Затраты на исследовательское тестирование	140 ч/ч	166 ч/ч
					Багов найдено в ИТ	73	91
					Затраты на обнаружение 1 бага в ИТ	1,9 ч/ч	1,8 ч/ч
					Затраты на проверку тест-кейсов	97 ч/ч	130 ч/ч
					Багов найдено по ТК	132	48
					Затраты на обнаружение 1 бага по ТК	0,7 ч/ч	2,7 ч/ч
26	Эффективность тест кейсов по сравнению с исследовательским тестированием	Exploratory / Scripted Testing Efficacy Comparison	Скорость обнаружения по ТК Скорость обнаружения в ИТ

2. Проектное планирование

2.1 Следование плану работ

#	Метрика рус.	Метрика англ.	Как рассчитывать	Визуализация метрики	Как использовать
27	Срывы сроков по задачам	Schedule slippage	Дата финиша факт – Дата финиша план Метрика может собираться по: • Задачам • Итерациям • Релизам И категоризироваться по: • Сотрудникам • Типам задач • И т.д.		• Для выявления среднего срыва сроков и включения его в планы работ • Для анализа причин сроков по каждой задаче или по самым большим сдвигам • Для включения в планирование рисков исходя из статистики срывов в процентах
28	Отклонение от плана работ	Schedule Variance	При оценке групп задач, итераций и проектов оценивается в процентах:
29	Превышение трудозатрат	Estimation Changes	Данные можно категорировать по: • Задачам • Итерациям • Командам • Сотрудникам • И т.д.		• Для анализа причин отклонения в оценках • Как возможный KPI при необходимости снижения трудозатрат • Для поиска превышения трудозатрат по категориям
30	Простои суммарно	Team Idling	В случае, если специалист не может выполнять задачи по текущей итерации (заблокирована сборка, не готово тестовое окружение и т.д.), то он списывает затраты этого периода в категорию «Простои»		• Для анализа причин простоев • Для закладывания простоев в планы работ • Для контроля за динамикой при борьбе с простоями
31	Доля простоев	Team Idling %

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

#	Метрика рус. Об этом говорит сайт https://intellect.icu .	Метрика англ.	Как рассчитывать	Визуализация метрики	Как использовать
32	Ведение рисков на проекте	Risk management	Наличие процесса ведения рисков на проекте		• Для оценки уровня зрелости проектов • Для анализа, где необходимо внедрение учета рисков для более грамотного планирования
33	Командное согласование рисков	Risk management approval	Согласование рисков и стратегии нивелирования всей командой проекта
34	Корректность прогнозирования рисков	Risk predicting correctness	Возникшие риски по прогнозу Все риски× 100% Где «Все риски» это сумма: • Спрогнозированных возникших • Спрогнозированных не возникших • Возникших не спрогнозированных		• Выявление избыточного прогнозирования рисков (см. Итерация 3) • Выявление недостаточного прогнозирования (см. Итерация 2)
35	Уровень нивелирования рисков	Risk avoidance efficacy	Успешно нивелированы Все риски в стратегии× 100% Рассчитывается на основании стратегии нивелирования		• Оценить, насколько корректные решения мы выбираем для нивелирования рисков • Найти более эффективные инструменты нивелирования

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

#	Метрика рус.	Метрика англ.	Как рассчитывать	Визуализация метрики	Как использовать
36	Соотношение трудозатрат разработчиков и тестировщиков	Test/Dev Effort Rate	Затраты на тестирование Затраты на разработку Рассчитывается по доработке, итерации, модулю и т.д.
37	Затраты ч/ч на KLOC	Test Effort per KLOC	Затраты на тестирование доработки Объем кода доработки Рассчитывается по объему кода в строках (KLOC) или с учетом сложности кода (Cyclomatic Complexity)
38	Затраты ч/ч на проверку требования	Test Effort per Req	Затраты на тестирование доработки Число требований в доработке
39	Затраты на 1 тестовое окружение	Tet Effort per 1 Environment	Затраты на тестирование совместимости Протестировано окружений
40	Время, затрачиваемое на создание ТК/ЧЛ	Test Effort for 1 TC creation	Затраты на создание тестов Число созданных тестов
41	Затраты на проверку 1 инцидента	Test Effort for 1 incident submit	Затраты на проверку инцидентов за период Число инцидентов обработано
42	Затраты на валидацию 1 дефекта	Test Effort for 1 bug validation	Затраты на валидацию дефектов Число дефектов провалидировано

Как использовать:

• Метрики грубой оценки (36,37,38) используются для быстрого получения планируемых трудозатрат исходя из предварительно собранной

статистики. Если на тестирование поступает доработка, содержащая 150 требований, мы можем быстро оценить затраты на ее тестирование как

150х1.36 = 204 ч/ч.

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

создать около 120 тестов, провести тестирование на 4 тестовых окружениях, провалидировать 40 дефектов, и т.д. В оценке мы суммируем затраты

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

• Анализируя затраты на повторяющиеся активности, мы можем выявить, что некоторые типы задач мы выполняем слишком долго. В этом случае мы

проводим улучшения и оптимизацию процесса, направленные на сокращение затрат, и выносим такие показатели в KPI (например, цель – тратить

на валидацию 1 дефекта не более 10 минут, стратегия – автоматизация создания тестовых данных и окружений, KPI – метрика #42)

3. Качество продукта

3.1 Удовлетворение пользователей

#	Метрика рус.	Метрика англ.	Как рассчитывать	Визуализация метрики	Как использовать
43	Средняя оценка пользователей	Average Client Rating	AVG (Пользовательские оценки за период) Можно собирать в: • Прямых опросах • Маркетах Используется для оценки: • Статика по релизу • Динамика по итерациям		• KPI проекта • Выявление источников низких оценок (см. диаграмму – проблемы в iOS версии) • Отслеживание динамики внедрения изменений
44	Распределение пользовательских оценок	Clients Grades Evaluation	Сбор «сырых» данных по числу каждого типа оценки		• Анализ исключительно высоких и исключительно низких
45	Новых запросов от пользователей за период	New Improvement Requests	• Внедрение очереди «запросы на улучшение от клиентов» в таск-трекере • Контроль статусов запросов: o «подвешено» o «в работе» o «реализовано» o «принято заказчиком»		• Оценить уровень удовлетворенности клиентов внедрением доработок • Спланировать работы по внедрению запросов от пользователей • Отфильтровать давно подвешенные доработки и принять по ним решения
46	Внедрено пользовательских запросов за период	Improvement Requests Implemented
47	Открытых пользовательских запросов	Opened Improvement Requests
48	Рейтинг внедрения пользовательских запросов	Improvement Ratio	Реализовано улучшений Запрошено улучшений × 100%
49	Прохождение приемки заказчиком	Customer Acceptance Ratio	Сборок принято заказчиком Всего сборок за период× 100%		• KPI проектной команды • Анализ причин непринятия сборки • Инструмент аргументации при внедрении решений по углублению тестирования

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

#	Метрика рус.	Метрика англ.	Как рассчитывать	Визуализация метрики	Как использовать
50	Дефекты в продукте по статусам	Defects by Status	Дефектов в категории Всего дефектов × 100% Возможен сбор более комплексных метрик, например: статусы дефектов по приоритетам, критичность дефектов по областям, и т.д.		• Оценить необходимость в исправлении дефектов • Спланировать затраты на достижение требуемого уровня качества по дефектам
51	Дефекты в продукте по критичности	Defects by Severity			• Оценить приоритетность заведения багов тестировщиками • Оценить количество скрытых дефектов (при заведении только высококритичных)
52	Дефекты в продукте по области	Defects by Functional Area			• Оценить качество отдельных функциональных областей • Принять решения о расширении подкоманд разработки и/или тестирования
53	Дефекты в продукте по типу тестов	Defects by Test Type			• Оценить качество продукта по соответствию нефункциональным требованиям
54	Дефекты в продукте по платформам	Defects by Environment			• Оценить качество сборок по окружениям • Принять решение о сокращении или повышении объемов тестирования по окружениям
55	Динамика дефектов	Defects Dynamics	Прирост дефектов = Заведено дефектов – Исправлено дефектов Число открытых дефектов = Число дефектов, открытых на начало периода, + Прирост дефектов		• Отслеживать динамику качества продукта по дефектам • Прогнозировать готовность продукта к релизу (обнаружение момента «сходимости дефектов»)

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

#	Метрика рус.	Метрика англ.	Как рассчитывать	Визуализация метрики	Как использовать
56	Успешных тестов	Passed Test Cases	Пройдено тестов Запущено тестов× 100%		• Показывает процент работающей функциональности (в комбинации с оценкой тестового покрытия!)
57	Упавших тестов	Failed Test Cases	Упало тестов Запущено тестов× 100%		• Показывает качество и стабильность ПО
58	Заблокированных тестов	Blocked Test Cases	Заблокировано тестов Запущено тестов× 100%		• Показывает объем задач, необходимых для выполнения после получения новой сборки на тестирование
59	Запущено тестов	Executed Test Cases	Запущено тестов Всего тестов× 100%		• Для оценки оставшихся работ по тестированию • Для оценки достоверности данных по метрикам 56-58
60	Результаты тестирования по категориям	Test Results by Category	При наличии категорий в тестах, используется для оценки различных аспектов качества: • Типы тестов (функц, произв, нагрузка и т.д.) • По приоритетам тестов • По областям функциональности		• Оценка качества различных категорий ПО • Распределение ресурсов в наиболее проблемные области
61	Готовность требований по тестам	Requirements Readiness by Tests	1. В системе ведения требований указываются ссылки на тесты, покрывающие это требование 2. По результатам выполнения тестов проставляется статус готовности требования: • Готово - все тесты по требованию пройдены успешно • Ошибки - часть тестов по требованию упали • Не работает - все тесты по требованию упали • Не проверено - тесты по требованию не запускались • Неизвестно - к требованию не привязаны тесты		• Для оценки оставшихся объемов тестирования • Для оценки рисков при принятии решения о релизе • Для приоритезации задач по тестированию и исправлению дефектов

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

Метрика рус.

Метрика англ.

Как рассчитывать

Визуализация метрики

Как использовать

Производительность в динамике

Dynamical

performance

Оценка скорости работы основных бизнес опций (загрузка ключевых страниц, выполнение ключевых операций или запросов).

•Изменение скорости работы основных элементов

приложения.

•Динамика изменения скорости работы основных элементов,

относительно целевого

уровня.

Метрики по обеспечению качества, метрики тестирования

• Для выявления регресса в производительности

• Для оценки улучшений

• Для оценки изменения

скорости работы

ключевого функционала

Производительность в сравнении с

конкурентами

Performance

compared to

competitors

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

основных бизнес-сценариев в сравнении с показателями

конкурентов.

•По минимальному количеству действий пользователя.

•По скорости выполнения

2.Сравнение нескоростных

ключевых параметров

производительности, таких как • Коэффициент сжатия при

архивации

•Допускаемые пользователями ошибки

•Число одновременных

подключений и т.д.

Метрики по обеспечению качества, метрики тестирования

• Для маркетингового

продвижения

• Для обнаружения зоны развития

• Для обоснования наличия дефектов

производительности

• Выявляя наилучшие

значения среди

конкурентов, мы

определяем, к чему

можно стремиться

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

#	Метрика рус.	Метрика англ.	Как рассчитывать	Визуализация метрики	Как использовать
64	Производительность под нагрузкой	Performance under load	Скорость отклика при разных нагрузках, в подавляющем большинстве случаев измеряется автоматизировано (JMeter, Grinder, HP Performance Center и т.д.)		• Оценить соответствие требованиям по нагрузке • Для оценки возможности масштабирования приложения по количеству пользователей
65	Стабильность под нагрузкой	Stability under load	1. Автоматизация множества одновременных запросов к серверу 2. Сбор статистики, какой % запросов проходит успешно, и какой вызывает ошибки		• Для определения отказоустойчивости системы в стрессовых ситуациях • Соблюдение SLA (англ. Service Level Agree ment - Соглашение об уровне предоставления услуги) • Определить, на каком количестве одновременных подключений проявляются ошибки
66	Ошибки под нагрузкой	Failures during load tests	Ошибочных откликов Всего запросов× 100%

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

Метрика рус.

Метрика англ.

Как рассчитывать

Визуализация метрики

Как использовать

Совместимость

Compatibility

Процент поддерживаемых

платформ, окружений, браузеров, версий ОС, разрешений экрана и т.д.

Список возможных статусов по окружению может быть разным, минимальный набор статусов: • Поддерживается

• Не поддерживается

По каждому статусу проводится расчет:

Статус тестирования

Всего окружений × 100%

Метрики по обеспечению качества, метрики тестирования

• Для оценки рисков по

непротестированным

окружениям

• Для выявления

неподдерживаемых

окружений

Модифицируемость

Modifiability

Метрики по обеспечению качества, метрики тестирования

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

#	Метрика рус.	Метрика англ.	Как рассчитывать	Визуализация метрики	Как использовать
69	Юзабилити отдельных форм по GOMS	Usability measured by GOMS	Модели расчетов по GOMS t – время, затраченное на выполнение действия H – перенос руки на мышь K – нажатие клавиши клавиатуры или мыши P – перенос курсора M – обдумывание следующего шага		• Для поиска неудачных (долгих по выполнению) реализаций в интерфейсе • Для выбора варианта реализации экранной формы • Для сравнительного анализа продукта с конкурентами
70	Юзабилити сценариев: успешность выполнения пользователями	Scenarios completion by users	• Выполнение пользователем заданных сценариев, подсчет его ошибок и вопросов, оценка успешности выполнения сценариев • Сценарий считается успешным, если фактический результат прохождения пользователем сценария совпадает с ожидаемым Статус выполнения Пользователей тестировало× 100%	и	• Для приоритезации юзабилити-доработок по сценариям • Для выявления непонятных мест и юзабилити-ошибок • Для обоснования необходимости исправлять ошибки
71	Структура пользовательских обращений	Users complains by product modules	Сбор статистики по обращениям в техническую поддержку в статусе «ошибка пользователя» (обращения, в которых причиной ошибки было непонимание пользователя, а не дефекты в продукте) Обращений по модулю Всего обращений× 100%		• Выявить зоны, в которых необходимо проведение юзабилити-экспертизы • Обнаружить ошибки и нелогичности, которые незаметны опытным участникам проекта, привыкшим к продукту

4. Эффективность тестирования

4.1 Скорость тестирования

#	Метрика рус.	Метрика англ.	Как рассчитывать	Визуализация метрики				Как использовать
72	Время на тестирование сборки	Time to test the build	AVG (Дата завершения тестирования − Дата начала тестирования) Измеряется в рабочих днях					• Статистика для последующего планирования релизов • Для определения зон развития / повышения скорости • Для поиска отклонений и выявления причин (простоев и срывов сроков) • Для оценки динамики и влияния внедренных изменений
73	Время до начала тестирования	Time to start testing	AVG (Дата начала тестирования − Дата готовности сборки ) Измеряется в рабочих днях
74	Время на обнаружение критического дефекта	Time to start testing	AVG (Дата заведения дефекта − Дата внедрения дефекта в код ) Для внедрения этой метрики необходимо добавить в баг-трекер поле «дата внедрения дефекта». Разработчик заполняет это поле в момент смены статуса дефекта на «исправлено» (в момент исправления он уже знает, какой именно коммит вызвал этот дефект, и может посмотреть, когда он был произведен). Так как сбор этой метрики подразумевает дополнительные затраты, обычно целесообразно собирать эту статистику только по критичным дефектам.					• Для выяснения средних значений (для планирования, и оценки рисков) • Для обнаружения критичных отклонения и выяснения причин, почему так долго не могли обнаружить критичный дефект
				Дефект	Дней	Причина долгого обнаружения	Решение
				17382	9	Был заблокирован для обнаружения	Убрать из статистики
				17315	11	Не знали о влиянии параметра в ТА	Провести ревью тестов по модулю с архитектором, возможно, еще что-то упустили

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

#	Метрика рус.	Метрика	Как рассчитывать	Визуализация метрики			Как использовать
75	ФОТ (Фонд оплаты труда) в тестировании	Total Cost of Testing Labor	Фонд оплаты труда команды тестирования, включая все необходимые затраты для обеспечения деятельности сотрудников. При расчете необходимо взаимодействие с фин. департаментом и бухгалтерией, для учета налогов, отпусков, больничных, офисных платежей, покупки оборудования, сервисов, социальных выплат. Обычно, сумма дополнительных затрат на команду варьируется от 50 до 120% от суммы заработных плат.		Общая стоимость тестирования		• Для бюджетирования и расчетов при запросе расширения • Для контроля при необходимости сокращения
					Стоимость Стоимость Стоимость Виды расходов на сотрудника в месяц сотрудника сотрудника сотрудника 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 ФМС - 2.9% 2 320 2 465 2 407 ФФОМС - 5.1% 4 080 4 435 4 233 НДФЛ - 13% 10 400 11 050 10 790	54 560 7 192 12 648 32 240
					Отпуск сотрудника (1/12 с з/пл.) 6 667 7 083 6 917	20 667
					Организационные расходы
					аренда офиса( по СанНПину на каждого сотрудника должно быть не менее 4.5 кв/м площади офиса), из расчета средней 4 500 4 500 4 500 ставки аренды 1000 руб/кв.м. ПК и оргтехника, мебель. В среднем 1/20 от з/пл. сотрудника4 000 4 250 4 150	13 500 12 400
					Административные расходы
					З/плата сотрудников HR: поиск, найм, увольнение, обучение, сопровождение З/плата бухгалтерии: найм, увольнение, сопровождение, больничные 2 000 2 000 2 000 З/плата руководителя (начальника) сотрудника : сопровождение, контроль, управление	6 000
					Повышение квалификации сотрудника (курсы, тренинги пр.)
					В среднем 1/12 от средней цены курса для ручного 1 250 1 250 1 250 тестировщика( 15 000 руб.) при условии прохождении 1-го курса в год	3 250
					ИТОГО в месяц: 122 417 129 583 126 717 378 717
					Стоимость команды тестирования за месяц: 378 717
76	Затраты на тестирование	Total Cost of Testing	ФОТ команды + тестовое оборудование + тестовые окружения + используемый инструментарий + внешние подрядчики				• Для бюджетирования проекта и команды тестирования • Для обоснования расширения
77	Cтоимость обнаружения ошибки	Cost per Bug Find	Затраты на тестирование Число дефектов Рассчитывается за период				• Для оценки экономической оправданности тестирования
78	Cтоимость исправления ошибки	Cost per Bug Fix	Затраты на исправление дефектов Число дефектов для исправления Рассчитывается за период				• Для поиска затратных в исправлении дефектов и анализа причин
79	Отклонение бюджета тестирования	Testing Budget Variance	Факт затрат − План затрат План затрат× 100%				• Для планирования бюджета в будущем • Для анализа причин отклонений

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

#	Метрика рус.	Метрика англ.	Как рассчитывать	Визуализация метрики	Как использовать
80	% исправленных дефектов	Bugs Fix Ratio	Исправлено дефектов Заведено дефектов × 100% Расчет проводится за период или по версии/итерации		• Для выявления причин НЕисправления дефектов. • Для оценки статуса тестирования по модулям, направлениям, типам тестов
81	% отклоненных дефектов	Bugs Reject Ratio	Отклонено дефектов Заведено дефектов × 100% Расчет проводится за период или по версии/итерации
82	Причины отклонения дефектов по группам	Rejection Causes	Для сбора этой метрики требуется выпадающий список в баг-трекере, необходимый для заполнения разработчиком при отклонении дефекта, например: • не воспроизводится • неправильное понимание ожидаемого результата • исправление невозможно • ошибка в требованиях Причина отклонения Всего отклонено× 100%		• Чтобы найти способ сократить число отклоненных дефектов (решить проблему, вызывающую наибольшее число отклонений)
83	Качество заведения дефектов	Bugs Submission Quality	Субъективная оценка в баг-трекере, в разрезе разработчиков, тестировщиков, типов дефектов и т.д.		• Оценить качество заведения дефектов на проекте, в команде, у отдельного сотрудника • Выяснить причины анормально низких оценок для решения • Учитывать разработчиков, которые могут завышать или занижать оценки

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

#	Метрика рус.	Метрика англ.	Как рассчитывать	Визуализация метрики	Как использовать
84	Скорость прохождения автотестов	Autotests execution speed	Время прохождения автотестов: AVG (Время готовности отчета по автотестам − Время запуска автотестов) Среднее время на выполнение 1 теста: Время прохождения автотестов Число автотестов		• Для планирования тестовых циклов • Для принятия решения об эффективности автотестов и их расширении • Для обнаружения проблем со скоростью автотестов • Для своевременного обнаружения регресса производительности
85	Скорость разработки автотестов	Autotests implementation speed	Затраты на автоматизацию за период Число новых автотестов за период Может считаться в разрезе сотрудников, команд, типов автотестов и т.д.
86	Стабильность автотестов	Autotests Stability	Успешно пройдено автотестов Всего автотестов× 100% Измеряется как среднее за период или релиз Может группироваться по разработчику автотестов, функциональной области продукта, и т.д.		• Для планирования трудозатрат на поддержку и анализ автотестов • Для оценочного сравнения стабильности автотестов по категориям (разработчик, тип тестов, функц. область и т.д.)
87	Причины нестабильности тестов по категориям	Autotests Failures Causes	Заполнение из выпадающего списка каждый раз, когда вносятся изменения в автотесты, для фиксации причины изменений, и дальнейший расчет доли каждой причины: Причина падения автотестов Всего падений автотестов× 100%		• Для поиска ключевой причины нестабильности автотестов • Для решения проблемы, вызывающей наибольшее число падений • В редких случаях – для принятия решения о смене стратегии автоматизации (выбор других интерфейсов, инструментов, отказ от автоматизации новой функциональности и т.д.)

Метрика рус.

Метрика англ.

Как рассчитывать

Визуализация метрики

Как использовать

Ложные

срабатывания

Autotesting

False Alarms

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

Метрики по обеспечению качества, метрики тестирования

• Для оценки уровня достоверности

автотестов

• Для оценки

возможности

принятия решений о релизе продукта по итогам автотестов

(насколько

достоверны

показатели

автотестов до

проведения ручного анализа)

Ложные

прохождения

тестов

Autotesting

False Positives

При регистрации дефектов в областях, покрытых автотестами, уточнять, почему дефект не был зарегистрирован по итогам запуска автотестов. Если

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

!Важно

Ложные прохождения, как и пропуски в ручном тестировании, невозможно выявить все, и это будет примерная оценка.

Экономическая оправданность

автотестов

Autotests

Return of

Investment

Выгода от внедрения автотестов Затраты на внедрение автотестов × 100%

Где выгода от внедрения учитывает все затраты на ручное тестирование, а затраты на автоматизацию включают в себя

• Разработку автотестов

• Поддержку и актуализацию

автотестов

• Запуски и анализ результатов автоматизированного

тестирования

Метрики по обеспечению качества, метрики тестирования

• Для принятия

решений о внедрении автоматизированного тестирования

• Для выбора и

приоритезации

автотестов исходя из их экономической

оправданности

Покрытие

автотестами

функционала

продукта

Features

Coverage by

Autotests

Функций тестироуется автоматизировано Всего функций в продукте× 100%

В качестве функций могут выступать функциональные требования,

пользовательские сценарии, области и модули продукта и т.д.

Метрики по обеспечению качества, метрики тестирования

• Для контроля

следования плану

• Для оценки

возможности

сокращения ручного тестирования

• Для поиска зон, в которых необходимо расширять

автоматизацию

тестов

Покрытие

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

Code Coverage by Autotests

См. метрики #9-12

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

тестов

Regression

Coverage by

Autotests

Автоматизировано регр. −х тестов

Всего регрессионных тестов× 100%

Выполнение

плана

автоматизации

тестирования

Automation

Plan Fulfilment

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

План автоматизировать тестов× 100%

Заключение

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

Вау!! 😲 Ты еще не читал? Это зря!

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

Метрики по обеспечению качества, метрики тестирования

Создание, использование и анализ метрик

Метрики по тест кейсам

Метрики по багам

Метрики по задачам

1.1 Пропуски дефектов

2. Проектное планирование

2.1 Следование плану работ

3. Качество продукта

3.1 Удовлетворение пользователей

Заключение

Вау!! 😲 Ты еще не читал? Это зря!

Комментарии

Оставить комментарий

Качество и тестирование программного обеспечения. Quality Assurance.

Термины: Качество и тестирование программного обеспечения. Quality Assurance.