на основе каких данных рассчитывается метрика выполнение тест кейсов
Поиск наименьшего смысла
Ключевой принцип тестирования давно уже сформулирован Базом Дийкстра: мы не можем доказать отсутствие багов, мы способны только продемонстрировать их присутствие. Даже если миллион кейсов прошел успешно, значимыми будут те тесты, что упали.
Наименьший смысл в подсчете кейсов имеет подсчет пройденных. Подсчет тех, которые не нашли баги. Подсчет только тех, которые успешно завершены. В этом случае мы забываем, что каждое изменение, следующее за найденным багом, аннулирует пройденные кейсы и создает новую цель тестирования.
Добавление смысла
Думая о том, как я считала кейсы восемь лет назад, я вспоминаю бессмысленную битву, которая превратилась в продуктивные переговоры. Начала я с предпосылки, что способ, которым все всегда делалось – подсчет пройденных и упавших тестов – это путь к плохому тестированию и плохим отношениям с менеджментом. Я столкнулась с тем, что в 30-дневном проекте приемочного тестирования после нескольких лет разработки все чувствовали дискомфорт, не имея способа оценить прогресс тестирования. Я не могла полностью отдаться сессионному тест-менеджменту, так как это был бы не очень удачный выбор для замены существующего подхода: пришлось бы потратить много сил, чтобы познакомить бизнес-специалиста с этой методологией.
Я подошла к этой проблеме экспериментальным образом, попросив о возможности сделать что-то иначе – только в этот раз, без обязательств заниматься этим еще раз, потому что оно может не сработать. Мы начали с того, как это делалось раньше: писали кейсы заранее и следили за пройденными и упавшими в течение тридцати дней.
В течение первого 30-дневного приемочного тестирования меня начало напрягать то, что я считаю наивысшим риском использования тест-кейсов как метрики: качество выполненного тестирования. Когда тесты составлены заранее, вы генерируете идеи о тестировании, не зная практически ничего. У вас нет ПО, есть только требования. Кейсы создавались на основании старой версии продукта: мы думали о том, как нововведения его затронут, и создавали сценарии, чтобы проверить эти нововведения.
Под моим руководством мы внедрили два типа тест-кейсов. Первая группа была вполне традиционной и детализировала, куда нужно идти и на что обратить внимания. Вторая была совсем иной. Мы использовали инструментарий HP для создания шаблона кейса – идея была в шагах, которые можно было многократно использовать. Эти шаги описывали высокоуровневый процесс, без деталей. Реальные кейсы были тестовыми данными: люди, чьи данные мы могли использовать для прохождения по сценарию различными путями. Доступное нам время мы разделили между тестами: половину потратили на традиционные тесты, а вторую – на исследовательское, по сути, тестирование.
Мы нашли приличное количество багов, и все они были найдены в ходе исследовательского тестирования. Таким образом, мы убедились, что на текущий момент этот способ нам очень подходит. Резкий переход на полную свободу действий нервировал бы команду, а микс старого и нового позволил нам много добиться, не сильно отклоняясь от привычных навыков и зон комфорта. Отчитывались мы о запланированных, прошедших, упавших тестах, а также тех, которые начаты, но еще не закончены – для обоих наборов тест-кейсов.
Когда мы проводили 30-дневное приемочное тестирование для другого продукта, то сильнее углубились в исследовательское тестирование. У нашей системы была сложная логика процессов, которые в том числе обращались к сторонней системе и включали ручную обработку данных. Мы снова создали наборы тестовых данных в качестве тест-кейсов, а также шаблоны для повторного использования шагов, где 7 шаг из 12 был той информацией, которую нам отдавала сторонняя система. Групповое тестирование было привычным делом для бизнес-процесса, раньше кейсы в процессе не использовались, и метод отлично подошел.
Перед выходом в прод мы достигли не менее пристойных результатов. Цифры показали, что большая часть тестов находилась в состоянии «начаты, но не закончены», и способствовали тому, что мы попросили стороннюю систему отслеживать, доходят ли до нее наши запросы информации.
Третье тридцатидневное приемочное тестирование под моим руководством экспериментировало с вторичным риском использования кейсов как метрики прогресса тестирования – отражение природы тестирования как вида деятельности. Первые пару раз я осознавала, что «пройденные» и «упавшие» тесты создают иллюзию. Когда мы выявляли проблему, выкатывалась новая версия системы. Если мы находили критический кросс-системный баг, требующий внесения изменений, а 80% тестов уже успешно прошли – оставшихся 20% было недостаточно для тестирования. Идея этой метрики не просто базировалась на убеждении, снижающем качество возможного тестирования – она поощряла ложь насчет тестового покрытия, так как предполагалось, что изменений не было.
Мы все еще считали тест-кейсы, но изменили наши графики и то, как мы говорили об этих подсчетах – теперь это были прогресс-бары. Все мы знаем, что это такое. Время, потраченное на ожидание обновления, и цифры на экране иногда каким-то образом связаны, но это непредсказуемо и ненадежно. Это просто способ сообщить «ожидайте, мы над чем-то работаем». Вместе с прогресс-баром мы внедрили 30% «невидимых тестов», демонстрирующих тесты, которые, как мы ожидали, будут повторены или добавлены в процессе тестирования. К моменту, когда 100% наших тестов было завершено, нам требовалось еще примерно 30%, чтобы протестировать изменения, и таким образом мы избегали старых проблем, когда менеджеры, не разбирающиеся в тестировании, считали, что оно завершено, если запланированные тесты единожды прошли.
Зачем считать тест-кейсы в проекте?
Я не сторонник подсчета тест-кейсов, однако когда мне приходится их считать, я умею делать это так, чтобы подсчет шел на пользу качественному тестированию:
Проектам нужно подсчитывать тест-кейсы, если у них нет другой метрики прогресса, и команда не готова доверять устному описанию прогресса без насильно навязанной методологии подсчета.
Когда я начала рассматривать тестирование как вложение времени и отчетность по нему, все стало значительно проще. Если у меня есть неделя, я всегда могу сказать, что если прошло четыре дня – остался всего один. Исследуя, я могу объяснить, что я за это время обнаружила, и что я буду использовать на следующей неделе. Это могу как я, так и команды исследовательского тестирования, но это умеют не все специалисты, временно переведенные в тестировщики.
Я знаю, что подсчет кейсов не имеет смысла, и знаю, что ранний прогон кейса может занять больше времени, потому что я непременно начну исследовать систему рядышком. Я знаю, что при более позднем прогоне кейса я могу найти проблему, которая была там всегда, но при первоначальных прогонах мне не хватало информации, чтобы разглядеть ее. Ограничивать себя кейсами, когда процесс завязан на получение знаний, бессмысленно.
Однако я могу принять то, что иногда приходится делать бессмысленные вещи, потому что они помогают кому-то еще. Я также знаю, что я могу экспериментировать и предлагать альтернативы, медленно приближающие людей к моему пониманию динамики тестирования. Иногда достаточно попросить доверять моему восприятию статуса тестирования. Я проводила вдали от команды достаточно времени и научилась выстраивать работу так, что в мое отсутствие все не летит в тартарары.
Отличный способ что-то изменить – более частые релизы. Если я сталкиваюсь с организацией, подсчитывающей кейсы – это мой способ борьбы с этим подсчетом, применяемый по умолчанию.
Метрики тестирования программного обеспечения
Что такое метрика тестирования программного обеспечения?
Идеальным примером для понимания метрик будет недельный пробег автомобиля по сравнению с его идеальным пробегом, рекомендованным производителем.
Метрики тестирования программного обеспечения — Повышает эффективность и результативность процесса тестирования программного обеспечения.
Метрики тестирования программного обеспечения или измерения теста программного обеспечения — это количественный показатель степени, емкости, измерения, количества или размера какого-либо атрибута процесса или продукта.
Пример измерения теста программного обеспечения : общее количество дефектов
В этом уроке вы узнаете
Почему метрики теста важны?
Типы тестовых метрик
Определение правильных показателей тестирования очень важно. Немного вещей, которые необходимо учитывать, прежде чем определять показатели теста
Метрики ручного теста
В программной инженерии, ручные тестовые метрики делятся на два класса
Базовые метрики — это необработанные данные, собранные Test Analyst во время разработки и выполнения тестовых примеров (количество выполненных тестов, количество тестовых случаев ). При этом рассчитанные показатели выводятся из данных, собранных в базовых показателях. За расчетными показателями обычно следует менеджер тестов для целей составления отчетов о тестировании ( % Complete,% Test Coverage ).
В зависимости от проекта или бизнес-модели, некоторые важные показатели
Тест метрики жизненного цикла
Различные этапы жизненного цикла метрики
Шаги на каждом этапе
Как рассчитать тестовую метрику
Пример тестовой метрики
Чтобы понять, как рассчитать показатели теста, мы увидим пример выполнения процентного теста.
Для получения статуса выполнения тестовых случаев в процентах мы используем формулу.
Кроме того, вы можете рассчитывать для других параметров, таких как не выполненные тесты, тесты пройдены, тесты не пройдены, тесты заблокированы и т. Д.
На основе каких данных рассчитывается метрика выполнение тест кейсов
Что пишут в блогах
Продолжу хвастаться статусом книги.
I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:
Онлайн-тренинги
Что пишут в блогах (EN)
Introduction
Разделы портала
Про инструменты
Автор: Наталья Руколь, тренер курса «Аудит и оптимизация QA-процессов»
Ключевой парадокс тестирования за эти годы так и остался нерешенным: как оценить результаты процесса, который не производит конкретный, ожидаемый заказчиком продукт? Никому не нужны баг-репорты и тест-кейсы, всем нужен только качественный софт, да ещё и выпущенный вовремя. Как в таких условиях показать ценность работы QA-команды? Здесь нам на помощь приходят метрики, и на текущий момент наверное уже в каждом проекте по разработке софта собираются какие-то измеримые показатели тестирования. Тест-менеджеры понимают, что какие-то метрики им надо внедрить, это в тренде, и начинают искать, что бы им такого померять на проекте? Статьи, форумы, доклады на конференциях пестрят конкретными примерами метрик, которые начинающие тест-менеджеры спешат посчитать на своих проектах. Но так не работает!
Никакие метрики не являются универсальными – напротив, это лишь инструмент, который помогает вам в решении определенных задач. Вы сначала определяете, что вам нужно, а уже потом ищете способы это померить, но не наоборот! Никто не покупает молоток, чтобы потом ходить и думать, какой бы гвоздь им забить. проверить сталкиваясь с задачей “повесить на стену картину” мы думаем, что нам для этого нужно, и только после этого идём в магазин за нужным гвоздём и подходящим молотком. Вот и с метриками в тестировании то же самое: сначала мы определяем цели, и только потом думаем, какие метрики могут нам помочь в их достижении (и могут ли).
Для чего нужны метрики?
В таком случае мы ищем косвенные процессные метрики, которые будут вести нас к повышению оценок. Читаем отзывы и выясняем, за что снижены оценки. Находим три лидера по упоминаниям среди жалоб: падения на нестандартных окружениях, медленная скорость работы, нехватка запрошенных фич. Отлично, с этим уже значительно понятнее, как работать, чем с абстрактной оценкой нравится/не нравится! Мы можем выбрать метрики, которые помогут нам оценить свою работу (покрытие тестами на разных окружениях, проведение тестов производительности), так и общепроектные метрики: скорость работы и готовность запрошенных фич. Таким образом мы поможем и самим себе, чётко отслеживая рост требуемого тестового покрытия, и другим участникам команды, сразу показав, чего не хватает для релиза. До выпуска полгода, а поднять число тестовых окружений на 6% я уже могу сегодня!
Допустим, вы приходите к руководству со стандартным списком жалоб: ресурсов не хватает, времени слишком мало, требований нет, код отстой. Скажите ему это, и он будет отмахиваться от вас всеми доступными способами.
Хотите получить результат вместо отмашек? Придите с метриками. Покажите, что экономия ресурсов тестирования в 2000$ обходится проекту в 9000$ на штрафах по договору. Проиллюстрируйте, как экономия недели в начале релиза на написание требований ведёт к задержке релиза в три недели из-за разного понимания ожиданий. Такая беседа всегда будет конструктивнее и результативнее пустой болтовни, не подтверждённой измеримыми показателями!
Метрики: как выбрать и внедрить
Если по написанному выше ещё не стало понятно, что циферки ради циферок не нужны, придётся повториться: никогда не пытайтесь внедрить какую-то метрику просто потому, что она вам кажется логичной или полезной. Всегда идите от задачи, например:
Максимально осознанно пройдитесь по этому списку вопросов. Подключите коллег через совместный брейншторм или опросы. Определите, что вы хотите измерять, не доходя до уровня конкретных чисел и метрик. Сначала вам нужны обобщённые названия метрик, например:
Примеры метрик в тестировании с описанием вариантов их использования
В рамках курса «Аудит и оптимизация QA-процессов» мы с Олегом Грабко помогаем ученикам выявлять те метрики, которые будут им максимально полезны в конкретных ситуациях. Из тех более трехсот метрик, которые мы когда-либо использовали, мы выбрали 94, наиболее наглядно иллюстрирующих возможности этих инструментов и приложили их в качестве дополнительного материала к уроку №3. Я очень надеюсь, что изложенной выше статьи достаточно для того, чтобы вы смогли внедрить нужные вам показатели с пользой и существенно улучшить с ними свой процесс тестирования.
Внимание! Пожалуйста, сначала проведите работу по анализу ваших потребностей в измерении, алгоритм которой я привела выше, и только после этого ознакомьтесь с примерами метрик.
Скорее всего в этих примерах вы найдёте такие показатели, которые помогут в решении стоящих перед вами задач. Но что делать, если необходимость в метрике вы выявили, но подходящего варианта для её расчёта не нашли? Пишите нам! Обещаем по каждому запросу на вариант внедрения метрики подготовить такой способ расчёта и визуализации, который получится внедрить в ваши условия. Таким образом, постепенно мы сделаем этот документ ещё более полным и полезным для всей отрасли.
Всем качественных продуктов, растущих показателей и зрелых процессов!
Самый полный список метрик тестирования на русском языке
Ключевой парадокс тестирования за эти годы так и остался нерешенным: как оценить результаты процесса, который не производит конкретный, ожидаемый заказчиком продукт? Никому не нужны баг-репорты и тест-кейсы, всем нужен только качественный софт, да ещё и выпущенный вовремя. Как в таких условиях показать ценность работы QA-команды? Здесь нам на помощь приходят метрики, и на текущий момент наверное уже в каждом проекте по разработке софта собираются какие-то измеримые показатели тестирования. Тест-менеджеры понимают, что какие-то метрики им надо внедрить, это в тренде, и начинают искать, что бы им такого померять на проекте? Статьи, форумы, доклады на конференциях пестрят конкретными примерами метрик, которые начинающие тест-менеджеры спешат посчитать на своих проектах. Но так не работает!
Никакие метрики не являются универсальными – напротив, это лишь инструмент, который помогает вам в решении определенных задач. Вы сначала определяете, что вам нужно, а уже потом ищете способы это померить, но не наоборот! Никто не покупает молоток, чтобы потом ходить и думать, какой бы гвоздь им забить. Сталкиваясь с задачей “повесить на стену картину” мы думаем, что нам для этого нужно, и только после этого идём в магазин за нужным гвоздём и подходящим молотком. Вот и с метриками в тестировании то же самое: сначала мы определяем цели, и только потом думаем, какие метрики могут нам помочь в их достижении (и могут ли).
Для чего нужны метрики?
1. Оценка прогресса. Если перед нами стоит какая-то задача, которую невозможно выполнить “здесь и сейчас”, нам нужен инструмент оценки, чтобы понять, ведут ли наши действия к ожидаемому результату?
2. Промежуточные замеры. Есть метрики, показывающие финальный результат, а есть процессные, благодаря которым еще до релиза продукта и до выдачи отчета руководству мы можем определить, движемся ли мы в нужном направлении и что еще нам нужно улучшать.
В таком случае мы ищем косвенные процессные метрики, которые будут вести нас к повышению оценок. Читаем отзывы и выясняем, за что снижены оценки. Находим три лидера по упоминаниям среди жалоб: падения на нестандартных окружениях, медленная скорость работы, нехватка запрошенных фич. Отлично, с этим уже значительно понятнее, как работать, чем с абстрактной оценкой нравится/не нравится! Мы можем выбрать метрики, которые помогут нам оценить свою работу (покрытие тестами на разных окружениях, проведение тестов производительности), так и общепроектные метрики: скорость работы и готовность запрошенных фич. Таким образом мы поможем и самим себе, чётко отслеживая рост требуемого тестового покрытия, и другим участникам команды, сразу показав, чего не хватает для релиза. До выпуска полгода, а поднять число тестовых окружений на 6% я уже могу сегодня!
3. Поиск проблем. Третий случай, когда мы используем метрики, – это проведение аудита и поиск слабых мест. Тут бывают два стандартных сценария: либо мы ищем проблему, которую пока не можем осознать, либо ищем корни и первопричины у известных проблем.
4.Числовые обоснования. Ну, и последняя цель, которую мы можем преследовать при внедрении метрик, – это презентация и иллюстрация руководству. Через метрики мы можем конструктивно и наглядно обосновать то, что почти невозможно донести на уровне простого общения: потребность в ресурсах, проблемы в разработке, влияние недостающих требований на общий процесс разработки и т.д.
Допустим, вы приходите к руководству со стандартным списком жалоб: ресурсов не хватает, времени слишком мало, требований нет, код отстой. Скажите ему это, и он будет отмахиваться от вас всеми доступными способами.
Хотите получить результат вместо отмашек? Придите с метриками. Покажите, что экономия ресурсов тестирования в 2000$ обходится проекту в 9000$ на штрафах по договору. Проиллюстрируйте, как экономия недели в начале релиза на написание требований ведёт к задержке релиза в три недели из-за разного понимания ожиданий. Такая беседа всегда будет конструктивнее и результативнее пустой болтовни, не подтверждённой измеримыми показателями!
Метрики: как выбрать и внедрить
Если по написанному выше ещё не стало понятно, что циферки ради циферок не нужны, придётся повториться: никогда не пытайтесь внедрить какую-то метрику просто потому, что она вам кажется логичной или полезной. Всегда идите от задачи, например:
Согласуйте ожидания руководства, зафиксируйте, а потом уже думайте: какими показателями можно оценить именно эту цель?
Вы хотите что-то улучшить в своей работе. Что именно? Определившись, какой результат вы хотите достигнуть, подумайте о его измерении:
2.1. как оценивать прогресс в достижении этого показателя?
2.2. как измерять достижения на уровне процесса, пока ключевой показатель, возможно, не меняется?
Вы хотите решить какую-то проблему, непосредственно в команде тестирования или на проекте в целом:
3.1. как оценивать эту проблему, в чём её можно измерить?
3.2. какие могут быть предпосылки для этой проблемы, очевидные или кажущиеся совсем нелогичными?
3.3. как можно обнаружить корень этой проблемы, или “узкое горлышко”?
Вам надо обосновать что-то своему руководству, и вы исчерпали аргументы:
4.1. как проиллюстрировать наличие проблемы?
4.2. как показать пользу от предлагаемого вами решения?
Максимально осознанно пройдитесь по этому списку вопросов. Подключите коллег через совместный брейншторм или опросы. Определите, что вы хотите измерять, не доходя до уровня конкретных чисел и метрик. Сначала вам нужны обобщённые названия метрик, например:
срывы сроков (для обработки жалобы от РМа)
причины срыва сроков (чтобы найти решения проблеме)
низкое качество тестирования (для решения жалоб от техподдержки)
низкое качество кода (чтобы конструктивно пожаловаться руководителю разработки)
отчётность для РМа по качеству продукта (по которой он сможет принимать взвешенные решения)
Примеры метрик в тестировании с описанием вариантов их использования
В рамках курса «Аудит и оптимизация QA-процессов» (ссылка на курс в моём профиле) мы с Олегом Грабко помогаем ученикам выявлять те метрики, которые будут им максимально полезны в конкретных ситуациях. Из тех более трехсот метрик, которые мы когда-либо использовали, мы выбрали 94, наиболее наглядно иллюстрирующих возможности этих инструментов и приложили их в качестве дополнительного материала к уроку №3. Я очень надеюсь, что изложенной выше статьи достаточно для того, чтобы вы смогли внедрить нужные вам показатели с пользой и существенно улучшить с ними свой процесс тестирования.
Внимание! Пожалуйста, сначала проведите работу по анализу ваших потребностей в измерении, алгоритм которой я привела выше, и только после этого ознакомьтесь с примерами метрик.
Скорее всего в этих примерах вы найдёте такие показатели, которые помогут в решении стоящих перед вами задач. Но что делать, если необходимость в метрике вы выявили, но подходящего варианта для её расчёта не нашли? Пишите нам! Обещаем по каждому запросу на вариант внедрения метрики подготовить такой способ расчёта и визуализации, который получится внедрить в ваши условия. Таким образом, постепенно мы сделаем этот документ ещё более полным и полезным для всей отрасли.
Всем качественных продуктов, растущих показателей и зрелых процессов!
Основные показатели процесса QA
В рамках Quality Assurance могут и должны быть использованы различные метрики и показатели качества продукта и процесса разработки. Метрики можно разделить на группы по параметрам, на основании которых они рассчитываются, по этапам жизненного цикла разработки, на которых они применяются, по целям и задачам, по стейкхолдерам, для которых они предназначены. Этот список можно продолжать и дальше.
В этой статье я решил собрать вместе и рассмотреть самые основные, на мой взгляд, группы критериев и измерителей для QA процесса. А в каждой группе я перечислю только самые важные и показательные, опять же на мой взгляд, метрики а также разберу, для чего они необходимы, в каких ситуациях полезны и как их использовать.
Какими должны быть метрики?
Сама по себе метрика в контексте ПО — это численное выражение какого-либо свойства, качества самого продукта или процесса его разработки. Иными словами, это то, с помощью чего мы можем измерить, сравнить и оценить ПО.
Теперь буквально пара комментариев по поводу значений и свойств метрик:
Основные группы метрик для QA
Теоретически возможно придумать свою характеристику, формулу или показатель практически для каждого, даже самого незначительного действия, этапа или статуса процесса QA. Можно учитывать каждый артефакт, все переходы дефектов по статусам, вычислять количество тестов в наборе. Однако, самый важный вопрос, который сразу следует задать себе, когда возникает желание что-то измерить: «Зачем нужна эта информация, как ее можно использовать?». При формирования набора метрик, следует отталкиваться от целей, планов по улучшению процессов и продукта.
Итак, в этой статье мы не будем рассматривать обычные количественные показатели прогресса тестирования, которые используются в большинстве отчетов и статусов. Вместо этого разберем, какие сферы, артефакты и области разработки с точки зрения Quality Assurance мы должны измерять и контролировать для оценки качества выполнения работы. Анализ и оптимизация этих точек крайне важнны для эффективного взаимодействия со стейкхолдерами (https://doitsmartly.ru/all-articles/sw-testing/120-stakeholders-for-qa.html) и разработки ПО в целом:
1. Требования к разрабатываемому ПО.
Совершенно точно мы должны понимать, что разрабатываем и тестируем, и степень этого понимания необходимо уметь оценить. Потенциальные риски или пропущенные проблемы на уровне спецификации могут привести к самым серьезным и дорогим ошибкам.
2. Качество разрабатываемого продукта.
Тут все очевидно: необходимо иметь возможность оценивать качество разработки и ПО, чтобы делать прогнозы и оценку рисков. Важно понимать, насколько продукт является качественным и надежным, опираясь не только на наличие или отсутствие найденных ошибок, но как раз прогнозируя, много ли потенциальных проблем.
3. Возможности команды QA.
Здесь тоже просто: для того, чтобы управлять процессом тестирования, планировать работы и прогнозировать сроки, требуется всегда иметь не только актуальный статус задач, но и знать возможности команды QA.
4. Качество работы команды тестирования.
Помимо качества самого продукта нужно измерять эффективность самого процесса QA и команды тестирования. Чтобы постоянно оптимизировать и улучшать качество работы, требуется знать, где мы находимся сейчас, что позволяет двигаться вперед, а что отбрасывает назад.
5. Обратная связь и удовлетворенность продуктом.
Последняя область, но, конечно же, не по значимости, а по отзывам стэйкхолдеров процесса, потребителей наших услуг, пользователей продукта. Очень важно иметь возможность измерять общую степень удовлетворенности продуктом, выделять тенденции и делать соответствующие выводы. Правильно подобранные для этой группы метрики позволят вовремя выявить возможные проблемы и оперативно применить обратную связь для улучшения процессов.
Далее рассмотрим, какие именно метрики входят в каждую группу, разберем, как именно их можно оценить. Для каждой группы я приведу несколько примеров возможных метрик и опишу их значение. Более подробно эти и некоторые другие индикаторы QA процесса разобраны в моей статье «Самые важные метрики QA» (https://doitsmartly.ru/all-articles/sw-testing/133-the-most-important-metrics-in-qa.html).
Группа 1 — Требования к разрабатываемому ПО
Эта группа метрик позволит оценить, насколько мы проработали требования (user story) к ПО, определить уязвимые места и наиболее сложные, потенциально проблемные фичи ПО, понять, где требуется особый контроль.
1. Тестовое покрытие требования
«Общее количество тестов» / «Общее количество требований»
Назначение метрики: выявить слабые места в тестовом покрытии, подсветить риски.
Метрика вычисляется как количество связей каждого требования с остальными требованиями. При этом используется среднее по всем требованиям значение.
Назначение метрики: дать основание для оценки сроков тестирования и учета возможных рисков. Зная степень взаимного влияния требований друг на друга, можно, например, запланировать дополнительное время и кейсы для сквозного тестирования, проработать регрессионные проверки, посмотреть в сторону интеграции и т.п.
Назначение метрики: показать, как много уже реализованных требований приходится переделывать от релиза к релизу при разработке новых фич. Также метрика дает представление о том, насколько легко масштабируется функционал системы, добавляются новые возможности.
Группа 2 — Качество разрабатываемого продукта
Данная группа метрик позволяет оценить и сравнить от релиза к релизу как качество ПО, так и качество самой разработки.
1. Плотность дефектов
«Количество дефектов в отдельном модуле» / «Общее количество дефектов в ПО»
Рассчитывается как доля дефектов от общего их числа, приходящихся на отдельный модуль в рамках итерации или релиза.
Назначение метрики: подсветить, какая часть ПО является наиболее проблемной. Эта информация поможет при оценке и планировании работ с данным модулем, а также при анализе рисков.
Назначение метрики: показать, на что уходят усилия команды — занимается ли она больше разработкой и отладкой новых фич или основную часть времени тратит на исправления в уже существующих частях ПО.
Назначение метрики: дать оценку качеству разработки и исправления дефектов, а также сложности продукта или отдельного модуля.
Группа 3 – Возможности и эффективность команды QA
Основная задача данной группы метрик заключается в том, чтобы выразить в цифрах, на что способна команда тестирования. Эти показатели можно и нужно рассчитывать и сравнивать на регулярной основе, анализировать тенденции, наблюдая, как на работу команды влияют те или иные изменения.
1. Скорость работы (velocity) команды QA
«Количество story points за N итераций)» / «N»
Рассчитывается как отношение реализованных story points \ требований \ user stories за несколько итераций \ sprints к количеству выбранных итераций.
Назначение метрики: численно выразить возможности, скорость работы команды для дальнейшего планирования объема работ и анализа трендов развития. Метрика позволяет следить за скоростью работы QA, наблюдать за тем, какие внутренние или внешние воздействия на команду влияют на эту скорость.
2. Среднее время жизни дефекта
«Суммарное время исправления найденных дефектов» / «Количество дефектов»
Общее время, в течение которого были открытыми дефекты, найденные в рамках итерации или релиза, к сумме дефектов.
Назначение метрики: показать, сколько в среднем времени уходит на работу с одним дефектом: на его регистрацию, исправление и воспроизведение. Данный показатель позволит оценить время, необходимое на тестирование, выделить области ПО, с которыми возникают наибольшие сложности.
Группа 4 — Качество работы команды тестирования
Задача этого набора метрик: оценить, насколько качественно тестировщики выполняют свои задачи, определить уровень компетенций и зрелости команды QA. Обладая таким набором показателей, можно сравнивать команду с ней же на разных отрезках времени или с другими, внешними группами тестирования.
1. Эффективность тестов и тестовых наборов
«Количество обнаруженных ошибок» / «Количество кейсов в тестовом наборе»
Назначение метрики: показать, как много ошибок в среднем позволяют обнаружить наши кейсы. Эта метрика отражает качество тест дизайна и помогает следить за тенденцией его изменения.
Назначение метрики: продемонстрировать качество тестирования и эффективность обнаружения ошибок — какая доля дефектов была отфильтрована, а какая прошла на продуктив.
Отношение времени, потраченного командой непосредственно на целевые QA активности, к общему количеству часов.
Назначение метрики: во-первых, увеличить точность планирования, а во-вторых, отслеживать и управлять эффективностью работы команды.
Назначение метрики: позволяет использовать поправочный коэффициент для последующих оценок.
Группа 5 — Обратная связь и удовлетворенность пользователей
И в заключение, группа метрик, показывающая, как продукт был принят конечными пользователями, насколько он соответствовал их ожиданиям. При этом в рамках оценки взаимодействия с пользователями нам важна не только обратная связь о самом ПО. Еще одна значимая задача этой группы метрик — показать, удовлетворены ли пользователи процессом взаимодействия с командой ИТ в целом и QA в частности.
1. Удовлетворенность пользователей ИТ сервисом
Проводится регулярный опрос удовлетворенности пользователей сервисом ИТ с выставлением баллов.
Назначение метрики: показать, доверяют ли пользователи команде ИТ, понимают ли, как и почему организована ее работа, насколько эта работа оправдывает ожидания.
Назначение метрики: определить степень участия внешних стейкхолдеров (бизнес, инфраструктура, пользователи, поддержка и т.д.) в работе над продуктом. Имея на руках такую метрику, можно сориентироваться, где требуется получить обратную связь, чтобы однажды не столкнуться с проблемами и непониманием.