Как оценивать работу тестировщиков по науке

Тестировщик с 50-летним стажем Александр Александров рассказывает про количественное управление процессом тестирования: какие метрики в ИТ-проектах бывают, как можно спрогнозировать количество дефектов в коде и зачем вообще оценивать результаты тестирования по численным KPI.

«То, что нельзя измерить, нельзя улучшить. Невозможно управлять тем, что нельзя измерить»

Эта фраза известного экономиста Питера Друкера имеет непосредственное отношение к процессу тестирования. Действительно, тестирование — одна из основных областей применения метрик. Изменяются дефекты в разных разрезах (критичность, статусы, тренды, компоненты объекта тестирования), трудозатраты на подготовку и проведение тестирования или размер кода (позволяющий сравнивать результаты тестирования для разных проектов).

От тестировщиков ожидают предоставления информации о состоянии программного продукта. Естественно, не на уровне «Хорошо / Плохо / Нормально». Ожидают, чтобы оценить масштаб проблем и выработать правильные эффективные решения. Разумеется, без точных числовых показателей здесь не обойтись.

Но как разобраться во всех имеющихся числовых данных? Дефектов может быть несколько тысяч, строк кода — и того больше. Учет трудозатрат, сравнение плана и факта. И все это нужно отслеживать в динамике, на регулярной основе.

Об этом настоящая публикация.

Описанные результаты были получены коллективом в составе Анатолия Галая, Ясны Мильковой и вашего покорного слуги. Коллеги, большое вам спасибо!

Статистическое и количественное управление процессами разработки ПО

Статистическое управление

Статистическое управление (Statistical Process Control, SPC) — это использование статистических методов для обработки и оценки результатов измерений параметров процессов в проекте.

В результате применения таких методов становится возможным:

• определять границы, в которых могут находиться значения параметра, если подпроцесс выполняется штатно (то есть предсказывать значение параметра подпроцесса);

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

Последовательность проведения SPC

Количественное управление

Количественное управление (Quantitative Process Control, QPC) — это процесс использования данных проектных измерений, обработанных с помощью статистического управления подпроцессами (или каких-то других методов) для:

• определения того, обеспечат ли текущие значения параметра процесса выполнение требований к нему в конце проекта;

• определения корректирующих действий, которые должны быть предприняты для обеспечения достижения установленных целей (если текущие результаты не дают уверенности в выполнении конечных требований);

• последующего контроля эффективности предпринятых мер.

Последовательность проведения QPC

 Ключевые метрики в ИТ-проектах:

• производительность кодирования команды;

• плотность дефектов до поставки;

• плотность дефектов после поставки;

• индекс отклонения от календарного плана (Schedule Performance Index, SPI);

• индекс отклонения трудозатрат (Cost Performance Index, CPI);

• общие удельные трудозатраты (Development Efficiency).

Процесс измерения проектов:

1. Определить набор метрик, которые интересуют организацию.

2. Дать однозначные определения всем метрикам.

3. Определить круг инструментов, с помощью которых можно получать эти метрики воспроизводимо и однозначно.

4. Собрать историческую информацию по этим метрикам.

5. Статистически ее обработать, в результате чего разработать границы возможностей процесса.

6. Ставить количественные цели для (под)процессов.

7. На регулярной основе проводить мониторинг метрик.

8. Анализировать метрики.

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

Границы возможностей процесса (Process Capability Baseline, PCB)

Условные обозначения: UCL — верхняя контрольная граница; CL — среднее значение; LCL — нижняя контрольная граница

Цели создания PCB:

• накопление истории измерений;

• определение возможностей процесса;

• основа для прогнозирования возможностей процесса.

PCB должна быть основана на бизнес-целях компании.

Статистический анализ в проекте и количественное управление (на примере процесса тестирования и метрики «Плотность дефектов»)

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

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

1. Убедиться в стабильности (под)процесса.

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

2. Выбрать метрики.

Выбранные метрики должны:

• отражать главные, ключевые характеристики процесса;

• отражать выполнение как минимум одной из целей проекта;

• быть самым полным образом определены (должно быть ясно, каким образом метрики будут собираться и вычисляться);

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

  Метрики в тестировании:

• Плотность дефектов (SDD = Число дефектов / Размер кода)

• Плотность дефектов после поставки (PDDD = Число дефектов после поставки / Размер кода)

• Доля отклоненных дефектов (DDR = Число отклоненных дефектов / Число дефектов)

• «Убойность» тестов (DP = Число дефектов / Число тестов)

• Эффективность тестирования (TE = Число дефектов / Трудозатраты тестирования)

• Доля покрытия требований (RCR = Число требований, покрытых тестами / Число требований)

• Плотность покрытия требований (RCD = Число тестов / Число требований)

• Доля повторно открытых дефектов (RDR = Число повторно открытых дефектов / Число дефектов)

• И много-много других…

3. Выбрать аналитические техники (контрольные карты XmR).

Контрольные карты XmR (XmR chart) — это массив данных, где точки располагаются в хронологическом порядке.

XmR chart включает два вида диаграмм:

• Individual — контрольная карта размаха (массив измеряемых данных, где точки располагаются в хронологическом порядке);

• Moving Range — контрольная карта скользящего размаха (массив данных сдвига между двумя точками измерений).

4.1. Провести измерения по установленным правилам.

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

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

4.4. Отобразить полученные результаты на контрольной карте и провести анализ стабильности процессов на их основе.

Последние два действия могут выполняться с помощью специальных программных инструментов, реализующих алгоритм расчета контрольных карт. Мы в IBS разработали инструмент для расчета и вывода на диаграмму параметров исследуемых метрик по алгоритму XmR — Quantitative Dashboard (скриншоты будут чуть ниже).

5. Определить особые случаи.

Особый случай — это попадание значения контролируемой метрики за пределы границ, вычисленных с помощью контрольной карты или «особое», необычное поведение последовательности значений метрики, свидетельствующее о ее неслучайном поведении.

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





Что делать при обнаружении особого случая:

• найти его причины;

• принять меры по их недопущению в будущем;

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

6. Осуществить количественное управление.

Вычисленные ранее естественные границы процесса (process capability, или голос процесса) на этом шаге сравниваются с установленными целями по значению контролируемого параметра (objectives, или голос заказчика):

• если голос процесса удовлетворяет голосу заказчика, то ничего предпринимать не надо;

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

Меры могут быть следующие:

• изменить (по согласованию с заказчиком) установленные цели;

• улучшить выполнение существующего процесса для уменьшения размаха голоса процесса;

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

Пример распределения метрики SDD

Параметры процесса не обеспечивают полностью достижение проектной цели:

Причинами выхода за голос заказчика могут быть, например, слабая квалификация разработчиков, высокие требования заказчика, высокое качество тестирования, отсутствие анализа кода. Требуются корректирующие действия: обучение или замена специалистов; договор о снижении требований; внедрение анализа кода или любого дополнительного статистического тестирования (peer review объектов) и другие.

Параметры процесса (при гарантии его неизменности) с вероятностью до 100% обеспечивают достижение проектной цели:

Преимущества использования статистического управления:

• проактивный подход — своевременно предпринимаются корректирующие/ предупреждающие действия;

• импульс для улучшения процесса;

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

• возможность прогнозирования конечного результата.

Корреляция метрик

Примеры пар метрик, корреляцию которых организации может быть полезно получать:

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

• высокие оценки качества проектных аудитов и признание заказчиком проекта как успешного.

Корреляция метрик помогает на более раннем этапе проекта выявить проблемы и предпринять корректирующие действия.

Корреляция метрик — прогнозирование результата

• Параметр r (множественный коэффициент корреляции / множественное r / коэффициент корреляции Пирсона) — характеризует тесноту связи между зависимой переменной и предиктором.

• Параметр r2 (квадрат множественного коэффициента корреляции / множественный коэффициент детерминации) — коэффициент, показывающий, какая доля дисперсии результативного признака объясняется влиянием независимых переменных.

• Параметр Р — статистическая значимость коэффициента корреляции (например, для уровня значимости 0.05 вероятность ошибки — 5%).

• Проведенная прямая называется прямой регрессии или прямой, построенной методом наименьших квадратов.

Количественное управление результатами аудитов позволяет продемонстрировать:

• оценку качества выполнения проекта в целом;

• текущую оценку проекта.

Напоследок — обещанные скриншоты инструмента Quantitative Dashboard для расчета и вывода на диаграмму параметров исследуемых метрик по алгоритму XmR:

                                               Массив данных. В правой колонке особый случай

                                                         Пример построения контрольной карты

                                Пример распределения сдвига значений (Moving range)

Оригинал статьи на Хабре.