Kpi тестировщика: Как измерить тестирование — Лаборатория Качества

Как измерить тестирование — Лаборатория Качества

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

Что такое KPI?

Итак, для начала обратимся к самому понятию KPI. KPI (Key Performance Indicator) – это показатель достижения успеха в определенной деятельности или в достижении определенных целей. Можно сказать, что KPI – это количественно измеримый индикатор фактически достигнутых результатов.

В нашем случае KPI на проекте – это показатель эффективности работы всей команды тестирования. Помимо термина KPI в статье будет использоваться термин «метрики», под которым мы будем понимать числовое значение для измерения этой эффективности.

Зачем нам KPI?

Теперь давайте поговорим о том, зачем нам понадобились KPI на проекте, и почему мы решили их внедрить. Здесь все просто: мы хотели видеть состояние проекта в любой момент времени и принимать превентивные меры, дабы избежать проблем. Благодаря KPI руководитель направления тестирования на проекте не только видит сильные и слабые стороны проекта и всей своей команды, но и может отслеживать в динамике последствия своих собственных управленческих решений (что было сделано правильно, какие из принятых решений были удачными или неудачными), а в дальнейшем – корректировать их.

Кроме того, в KPI можно включить не только общепринятые количественные показатели, но и качественные (например, «уровень удовлетворенности заказчика»). Но давайте обо всем по порядку!

Откуда взять KPI?

Какие метрики подойдут проекту? Как их считать? Существует ли какая-то база с набором метрик, из которых сложатся KPI?

Каждый проект – вещь во многом уникальная. Не стоит полагать, что метрики с одного проекта хорошо «приживутся» на другом; их стоит разрабатывать с учетом специфики проекта и ожиданий/опасений вашего заказчика. А вот для превращения ожиданий в метрики потребуются время и терпение.

Как было у нас

Теперь я, как и обещала, расскажу о наших действиях на проекте.

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

Заказчик пришел к нам с какими-то определенными ожиданиями от тестирования, со своей целью. На данном этапе моей задачей как руководителя направления тестирования на проекте стало выявление этих самых целей и ожиданий. Существует множество вариантов такого анализа – это опросы, заполнение брифов, устное общение. Самое важное – узнать, чего хочет заказчик, за что переживает, и что у него «болит».

По клику на картинку откроется полная версия. 

Приведем примеры формулировок заказчика: «Из одного модуля программы в другой не «прилетают» сущности, а они там нужны, на них многое завязано»; «Не можем из старой программы в новую версию передать информацию»; «Мы полностью планируем переезд из одной системы в другую, поэтому будем настраивать передачу».

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

Теперь нам предстояло провести процесс декомпозиции, то есть разбиения глобальной цели на небольшие решаемые задачи для проектной команды. Кстати, в этом мне помогла сама команда! Давайте посмотрим, как же это происходило, но для начала вновь уточним сам термин «декомпозиция», разложив все по полочкам.

Декомпозиция

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

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

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

Принцип SMART

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

• Specific – конкретный. Ставя задачу, мы должны четко понимать, какого результата хотим достичь. Результат должен быть однозначным и понятным всем участникам процесса – сотрудникам команды тестирования, заказчикам, руководителям разных уровней.
• Measurable – измеримый. Нам нужны задачи, которые могут быть измерены. Иными словами, измеримость предполагает наличие критериев – измерителей, показателей выполнения.
• Attainable – достижимый. В данном случае определение «достижимый» я бы переименовала в «доступный» (доступный для выполнения сотрудником с определенным уровнем подготовки и квалификации). Грамотный руководитель никогда не даст новичку сверхсложную задачу, так как понимает, что новичок с ней просто не справится, а время, затраченное на попытки решения, уже не вернуть. Учет личностных особенностей и качеств сотрудников команды тестирования на проекте позволит очень четко (а главное – равномерно и посильно) распределить нагрузку, дать новичкам несложные задачи, а «звездочкам» и профи – задачи со сложной логикой в соответствии с их силами и навыками.
• Relevant – актуальный, значимый. Действительно ли выполнение задачи так важно для нас? Является ли данная задача необходимой именно сейчас? Что мы получим, если решим эту задачу? А если не решим?
• Time-bound – ограниченный во времени. Любая задача должна иметь свой срок, в течение которого ее необходимо решить. Установление временных рамок и границ для выполнения задачи позволяет сделать процесс контролируемым и прозрачным. Руководитель в любой момент времени может увидеть прогресс выполнения задачи.

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

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

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

Помимо этих основных подзадач я выделила еще несколько дополнительных:

 

 

 

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

 

Теперь давайте вместе пройдемся по каждой подзадаче и рассмотрим измеримые показатели (метрики).

Метрики, из которых складываются KPI

Покрытие функционала тестами. Как мы его можем измерить? Мы остановились на метрике «% покрытия xx числа модулей продукта тестами» (более подробную информацию о том, как это посчитать, вы можете найти в статье Натальи Руколь «Оценка тестового покрытия на проекте»).

По клику на картинку откроется полная версия. 

Разработка тест-кейсов и тестовых сущностей. Здесь мы решили работать с метрикой «количество модулей / функциональных блоков продукта, для которых разработано 100% сущностей».

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

«Заведение дефектов». Мы решили воспользоваться несколькими метриками, которые бы давали нам информацию о состоянии версии: «количество дефектов, заведенных командой», «количество дефектов приоритета Blocker на версии».

«Тестировать релизы и хот-фиксы» мы решили метриками «% протестированных задач, входящих в релиз и/или хот-фикс» (отношение проверенных задач к общему числу задач версии), «% тест-кейсов, пройденных на версии» и «% успешности прохождения кейсов на версии».
Последнюю метрику мы считаем по формуле:

где P1 – passed-шаги по первому блоку,
P2 – passed-шаги по второму блоку,
Pn – passed-шаги по n-ному блоку,
A1 – число шагов по первому блоку,
А2 – число шагов по второму блоку,
An – число шагов n-ного блока,
N – общее число всех блоков продукта.

Для измерения задачи, связанной с работоспособностью приоритетных продуктов, мы специально разработали матрицу (в ней отмечалось, работает или не работает то или иное значение для продукта) а далее подсчитали «% значений, работающих для продукта 1 и продукта 2 на версии». Считаем по формуле:

где Pп1 – это число работающих значений для продукта один,
Aп1 – все значения для продукта один.

По клику на картинку откроется полная версия. 

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

Напомню, что мы не хотели тратить дорогое нам время на объяснения багов и комментирование отчетов, но в то же время нам было важно, чтобы заказчик был доволен нашей работой. Таким образом для первой подзадачи, мы решили использовать количественные показатели «% отклоненных дефектов на версии с резолюцией Can’t reproduce», а для второй – «количество обращений заказчика с просьбой прокомментировать промежуточный отчет» и качественный показатель «удовлетворенность заказчика нашей работой».
Для оценки «удовлетворенности заказчика» мы ввели три уровня – «все отлично», «есть небольшие замечания / вопросы к работе» и «все плохо, заказчик недоволен». Этот показатель, кстати, вообще очень помогает с оперативным принятием решений внутри проектной команды. Если заказчик чем-то недоволен или огорчен, мы по «горячим следам» проводим обсуждение: стараемся минимизировать риски, понять причины недовольства, в максимально короткие сроки проработать решение и представить его заказчику.

По клику на картинку откроется полная версия. 

Что в итоге нам дают KPI

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

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

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

Вместо заключения

В «Лаборатории качества» мы пошли чуть дальше и все же решили собирать базу метрик, которые применимы на наших проектах. Нет, я не говорю, что можно брать готовый материал и работать с ним, но каждый менеджер, столкнувшийся с темой внедрения KPI на своем проекте, может обратиться к этой базе, посмотреть метрики, из которых собираются KPI на других проектах, и адаптировать эти метрики под свои нужды. Также мы подготовили внутренний регламент (своеобразную инструкцию по внедрению KPI на проектах), с помощью которого этот процесс проходит плавно и безболезненно.

Не бойтесь потратить время на подготовку и внедрение KPI на проекте: эти затраты полностью окупятся! Ваш заказчик будет удовлетворен проведенными работами и отличным качеством продукта. Он вновь и вновь обратится к вам за помощью!

Основные показатели процесса QA / Блог компании Luxoft / Хабр

В рамках 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. Тестовое покрытие требования

«Общее количество тестов» / «Общее количество требований»

Назначение метрики: выявить слабые места в тестовом покрытии, подсветить риски.

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

2. Степень взаимосвязанности требований
AVERAGE («Количество требований, связанных с требованием №1» / «Общее количество требований -1» ,…, «Количество требований, связанных с требованием №n» / «Общее количество требований -1»)

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

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

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

3. Коэффициент стабильности требований
«Количество изменений в существующих требованиях» / «Общее количество требований, реализованных за итерацию, включая новые»

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

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

Группа 2 — Качество разрабатываемого продукта

Данная группа метрик позволяет оценить и сравнить от релиза к релизу как качество ПО, так и качество самой разработки.

1. Плотность дефектов

«Количество дефектов в отдельном модуле» / «Общее количество дефектов в ПО»

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

Назначение метрики: подсветить, какая часть ПО является наиболее проблемной. Эта информация поможет при оценке и планировании работ с данным модулем, а также при анализе рисков.

• Данная метрика поможет обратить наше внимание на проблемный модуль\систему\функциональность, где доля дефектов выше среднего.

2. Коэффициент регрессии
«Количество дефектов в старом функционале» / «Общее количество дефектов, включая новый функционал»

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

• Например, если коэффициент регрессии больше 0,5, это значит, что больше половины времени мы тратим на восстановление ранее работавших функций ПО. Такую ситуацию требуется исправлять.

3. Коэффициент повторно открытых дефектов
«Количество повторно обнаруженных дефектов» / «Общее количество ошибок, включая ранее исправленные и новые»

Назначение метрики: дать оценку качеству разработки и исправления дефектов, а также сложности продукта или отдельного модуля.

• Чем ближе значение коэффициента к 0, тем меньше повторяются старые ошибки.
• При этом, если значение больше 0,2-0,3, это может говорить либо о технической сложности модуля, либо о проблемах в архитектуре, либо о некачественном исправлении ошибок.

Группа 3 – Возможности и эффективность команды QA

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

1. Скорость работы (velocity) команды QA

«Количество story points за N итераций)» / «N»

Рассчитывается как отношение реализованных story points \ требований \ user stories за несколько итераций \ sprints к количеству выбранных итераций.

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

2. Среднее время жизни дефекта

«Суммарное время исправления найденных дефектов» / «Количество дефектов»

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

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

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

Группа 4 — Качество работы команды тестирования

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

1. Эффективность тестов и тестовых наборов

«Количество обнаруженных ошибок» / «Количество кейсов в тестовом наборе»

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

• Показатель «убойности» тестов позволяет мониторить эффективность каждого из тестовых наборов, как она меняется с течением времени. Это даст возможность вовремя дополнять их «свежими» тестами.

2. Коэффициент ошибок, пропущенных на продуктив
«Количество ошибок, обнаруженных после выпуска релиза» / «Общее количество ошибок, обнаруженных до и после релиза»

Назначение метрики: продемонстрировать качество тестирования и эффективность обнаружения ошибок — какая доля дефектов была отфильтрована, а какая прошла на продуктив.

• Конечно, допустимый процент пропущенных ошибок будет зависеть от многих факторов, однако, если он >0,1, то тут явно есть проблема, ведь в таком случае каждый десятый дефект попал на продуктив и привел к сбоям ПО у пользователей.

3. Реальное время работы команды QA
«Время, потраченное на целевые QA активности» / «Общее количество рабочих часов команды»

Отношение времени, потраченного командой непосредственно на целевые QA активности, к общему количеству часов.

Назначение метрики: во-первых, увеличить точность планирования, а во-вторых, отслеживать и управлять эффективностью работы команды.

• К целевым активностям могут относиться: анализ, дизайн, оценки, тестирование, рабочие встречи и многое другое, к нецелевым — простой из-за блокеров, проблемы в коммуникациях, недоступность ресурсов и т.п.
• Конечно, данная метрика никогда не будет равна 1. Практика показывает, что для эффективных команд ее значение может составлять 0,5-0,6.

4. Точность оценки времени по областям\видам\типам работ
«Оценочное время работы» / «Фактическое время работы»

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

• Степень точности оценки можно определить для всей команды или отдельных тестировщиков, для всей системы или отдельных модулей ПО.

Группа 5 — Обратная связь и удовлетворенность пользователей

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

1. Удовлетворенность пользователей ИТ сервисом

Проводится регулярный опрос удовлетворенности пользователей сервисом ИТ с выставлением баллов.

Назначение метрики: показать, доверяют ли пользователи команде ИТ, понимают ли, как и почему организована ее работа, насколько эта работа оправдывает ожидания.

• Метрика может служить индикатором того, что необходимо сфокусироваться на оптимизации процесса или сделать его понятнее и прозрачнее для пользователей.
• Расчет показателя удовлетворенности можно проводить на основе результатов опроса по итогам поставки ПО. Для этого необходимо собрать все оценки и посчитать средний балл.

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

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

3. Вовлеченность стейкхолдеров
Количество инициатив и предложений по улучшению процесса и продукта, поступивших в течение итерации (релиза) со стороны стейкхолдеров.

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

Павел Новиков,

Program Manager
https://doitsmartly.ru/

Числовая оценка работы тестировщиков — Портал TMGuru

Оригинал статьи

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

Почему все рано или поздно приходят к необходимости измерений? К каким результатам приводит численная оценка тестировщиков? О вопросах внедрения метрик по оценке тестировщиков рассказывает в своей статье Наталья Руколь, опытный тест-менеджер и ведущая Школы Тест-Менеджеров.

Почему встаёт вопрос о метриках

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

1. Не хватает чувства контроля за ситуацией.

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

2. Сотрудникам не хватает внимания.

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

3. Сотрудникам требуются измеримые цели для повышения мотивации.

Сложно сказать сотруднику «заводи баги лучше», или «заводи багов больше», особенно если сотрудник уверен, что и так работает хорошо. Зато если мы измерим результаты их работы, то чувство необъективности пройдёт, и сотрудники будут знать, над какими именно показателями им нужно работать.

4. Невозможно доказать отсутствие проблем.

Разработчики жалуются на дефекты, РМ’ы жалуются на сроки, клиенты жалуются на баги. Тест-менеджер пытается оправдать работу своего отдела, показав, кто чем занят, и какие высокие у них результаты. А для этого результаты сначала нужно измерить!

А теперь давайте внимательно присмотримся к причинам ведения метрик сотрудников. У вас нет лёгкого чувства обмана? «Что-то здесь явно не то»! Почему это у нас недостаточно контроля? Почему у сотрудников цели неизмеримы, а внимания недостаточно? Почему мы занимаемся оправданием себя вместо решения проблем?

Истина проста: метрики для оценки сотрудников внедряются в ситуациях, когда у руководства есть проблемы с управлением. Что же происходит дальше?

К чему приводит внедрение метрик

Отлично, у нас появились метрики. Это может быть 1-2 значения, а могут быть полноценные KPI. Каков стандартный результат от таких нововведений?

1. Трата времени

Для сбора метрик необходимо расширять используемые инструменты, вводить новые поля, собирать новые данные, обрабатывать их, структурировать. Это неизбежная трата времени и тест-менеджером, и сотрудниками. Эта трата чаще всего несущественная, допустим 1-2 часа в неделю. Но когда вы тратите несколько процентов рабочего времени на задачи, не повышающие качество продукта и результаты тестирования, неизбежно появляется лёгкая демотивация и чувство неважности основных задач.

2. Демотивация сотрудников

В теории мотивации есть очень чёткое деление мотиваторов и стимулов. У сотрудника может быть мотивация делать всё хорошо просто потому что он хочет этого самого отличного результата, это и есть истинная мотивация. Но как только за результатом появляется «морковка», то результат сам по себе теряет ценность. Я уже не хочу выпускать качественные продукты и приносить пользу команде – я хочу завести не менее 144 дефектов в месяц, чтобы получить квартальную премию. Чувствуете разницу? В результатах работы она будет колоссальной. Сложный баг, непонятно как воспроизвести? У меня нет времени разбираться, я лучше 4 минора заведу, это будет выгоднее! Учитываем % отклонённых дефектов? Побоюсь заводить спорный баг. В итоге вы получите дубликаты, ниже качество дефектов, а потом и споры «нет, это не минор, это мажор, ты не объективен ко мне!» и «так я не 100% был занят на тестировании». То есть и объективность не получена, и демотивация, и конфликты.

3. Снижение качества работы

За счёт демотивации сотрудников и ориентации на циферки вместо истинных результатов вы 100% получите прирост по всем выбранным для измерения показателям, и 100% почувствуете в целом ухудшение работы команды. Но что нам чувства, если есть цифры, они-то объективны!

Сторонники числового измерения результатов работы в этом месте обычно объясняют проблему плохо подобранными метриками, не отображающими действительный результат. И впрямь, если метрики на 100% отображают качество работы, то такой проблемы не будет. Но, к огромному сожалению, в тестировании такие метрики невозможны.На заводе всё просто: сколько деталек в день, какой % брака. В тестировании, при всём желании, определить такие метрики невозможно.

Что делать, как жить?

Я не буду пускаться в долгую полемику на тему метрик, хотя с удовольствием отвечу на любые аргументированные комментарии в их пользу. В моей картине мира метрикам в тестировании места нет (опять же, на заводе – пожалуйста). Но описанные в начале статьи проблемы решать как-то всё же надо, если не метриками – то как?

1. Регулярная обратная связь

Сотрудники и без циферок должны знать, что их ждёт, какие их перспективы и куда они могут развиваться. По результатам исследований института Гэллапа люди, понимающие свои рабочие перспективы, работают в разы эффективнее и значительно более счастливы на работе (хотя далеко не все из них понимают важность обратной связи). Более того, многие большие боссы внедряют аттестации с метриками только для того, чтобы менеджеры наконец-то начали общаться со своей командой! А зря: я видела результаты таких «насильно» внедрённых регулярных аттестаций, толку от них всё равно нет. Просто старайтесь не реже раза в месяц общаться с каждым сотрудником тет-а-тет – это всем действительно необходимо!

2. Оперативная оценка задач

Чтобы сотрудники развивались, вы должны регулярно оценивать результаты их работы. Не раз в квартал и не сухими метриками. Делитесь с ними: что вам понравилось, что было не очень. При этом делайте эти оценки обязательно конструктивными! Слова из серии «ты молодец!» не просто не приносят пользы – они зачастую раздражают и вызывают недоверие и отдалённость от менеджера. А вот конкретная похвала заведению дефекта, найденному багу или интересному тесту – очень даже помогают вашим сотрудникам и дальше работать по высшим стандартам, понимая что именно от них требуется. Для критики правило своевременности ещё важнее – говорить «последний квартал ты работал на 22% хуже предыдущего» бесполезно, а вот своевременно комментировать плохо выполненные задачи – залог повышения качества работы.

3. Искренность в общении с сотрудниками и коллегами

Ваши циферки не нужны ни тестировщикам, ни сотрудникам из смежных отделов. Ваши сотрудники хотят искреннего общения, а ваши коллеги (разработчики, Рмы) – заинтересованности в общих проектных результатах. И если кто-то просит циферки – значит, просто не хватает правильного общения!

на Ваш сайт.

KPI для определения эффективности отдела тестирования

Управление тестированием больших объемов

Управление тестированием больших объемов Содержание О тестировании в целом Метрики тестирования Тесты Дефекты Задачи Мониторинг и прогнозы Результат тестирования Управление это процесс прогнозирования,

Подробнее

Wonderware MES/Performance

Wonderware MES/Performance Управление предприятием и производительностью линий в реальном времени Предлагаемый компанией Wonderware полный комплект программных функций MES позволяет ответственным сотрудникам

Подробнее

Управление CRM-проектами

Управление CRM-проектами Подводные камни и лучшие практики Алексей Клочков Директор практики bpm online financial services Главная встреча профессионалов в сфере CRM Содержание Организационная структура

Подробнее

Test Driven Development

Девятая независимая научно-практическая конференция «Разработка ПО 2013» 23-25 октября, Москва Test Driven Development Alexey Ragozin Deutsche Bank Тестирование и нагрузочное тестирование Функциональное

Подробнее

Качество ПО и методы его контроля

Качество ПО и методы его контроля Кафедра дискретной математики и информационных технологий Синельников Евгений Александрович 7 Ноябрь, 2011 Качество программного обеспечения Типичные проблемы важные для

Подробнее

Управление проектами НИОКР

Управление проектами НИОКР Содержание 1. Зачем нужна автоматизация управления проектами НИОКР………. 2 2. Какие выгоды получают руководители от внедрения решения «Управление проектами НИОКР»?……………………….

Подробнее

Устав проекта. Дата создания:

Устав проекта Дата создания: Оглавление 1. Список изменений…2 2. Лист согласований…2 3. Описание проекта…3 3.1 Общая информация…3 3.2 Цели проекта…3 3.3 Обоснование целесообразности реализации

Подробнее

BIM Управление Проектом

BIM Управление Проектом Андрей Кумсков AECOM, BIM менеджер Антон Посысоев AECOM, BIM координатор Пишите в Twitter с тегом #auru2015 AECOM GLOBAL AECOM команда профессионалов в Планировании, Проектировании

Подробнее

Система Metso Metrics

Максимальное время бесперебойной работы оборудования Система Metso Metrics Использование информации и опыта эксплуатации для повышения рентабельности вашего предприятия 1 Больше, чем просто цифровое решение

Подробнее

Обучение, Оценка, Оптимизация

Обучение, Оценка, Оптимизация Соложенцев Максим / SAP Education Апрель 09, 2015 Internal Предлагаемый подход и технологии SAP Поддержка, развитие, дельта-обучение SAP WPB+LSO Обучение SAP WPB+LSO Мониторинг,

Подробнее

Консалтинговые услуги

Консалтинговые услуги Перечень услуг и целевая аудитория Проектный консалтинг Разработка и организация исследований Повышение квалификации персонала учёных и экспертов бизнесменов студентов, активной молодежи

Подробнее

А.И. Лозинин, И.Б. Шубинский

Определение требований к программному обеспечению А.И. Лозинин, И.Б. Шубинский Определяющей задачей в жизненном цикле современных программнотехнических комплексов автоматизированных систем стало обеспечение

Подробнее

Применяемые понятия и определения:

ПОРЯДОК выполнения процедур технического сопровождения, планирования и учета исполнения задач по развитию Программы для ЭВМ «Госзакупки» (АИС «Госзакупки») Применяемые понятия и определения: Плановая доработка:

Подробнее

Числовая оценка работы тестировщиков

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

Почему все рано или поздно приходят к необходимости измерений? К каким результатам приводит численная оценка тестировщиков? О вопросах внедрения метрик по оценке тестировщиков рассказывает в своей статье Наталья Руколь, опытный тест-менеджер и ведущая Школы Тест-Менеджеров.

Почему встаёт вопрос о метриках

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

1. Не хватает чувства контроля за ситуацией.

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

2. Сотрудникам не хватает внимания.

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

3. Сотрудникам требуются измеримые цели для повышения мотивации.

Сложно сказать сотруднику «заводи баги лучше», или «заводи багов больше», особенно если сотрудник уверен, что и так работает хорошо. Зато если мы измерим результаты их работы, то чувство необъективности пройдёт, и сотрудники будут знать, над какими именно показателями им нужно работать.

4. Невозможно доказать отсутствие проблем.

Разработчики жалуются на дефекты, РМ’ы жалуются на сроки, клиенты жалуются на баги. Тест-менеджер пытается оправдать работу своего отдела, показав, кто чем занят, и какие высокие у них результаты. А для этого результаты сначала нужно измерить!

А теперь давайте внимательно присмотримся к причинам ведения метрик сотрудников. У вас нет лёгкого чувства обмана? «Что-то здесь явно не то»! Почему это у нас недостаточно контроля? Почему у сотрудников цели неизмеримы, а внимания недостаточно? Почему мы занимаемся оправданием себя вместо решения проблем?

Истина проста: метрики для оценки сотрудников внедряются в ситуациях, когда у руководства есть проблемы с управлением. Что же происходит дальше?

К чему приводит внедрение метрик

Отлично, у нас появились метрики. Это может быть 1-2 значения, а могут быть полноценные KPI. Каков стандартный результат от таких нововведений?

1. Трата времени

Для сбора метрик необходимо расширять используемые инструменты, вводить новые поля, собирать новые данные, обрабатывать их, структурировать. Это неизбежная трата времени и тест-менеджером, и сотрудниками. Эта трата чаще всего несущественная, допустим 1-2 часа в неделю. Но когда вы тратите несколько процентов рабочего времени на задачи, не повышающие качество продукта и результаты тестирования, неизбежно появляется лёгкая демотивация и чувство неважности основных задач.

2. Демотивация сотрудников

В теории мотивации есть очень чёткое деление мотиваторов и стимулов. У сотрудника может быть мотивация делать всё хорошо просто потому что он хочет этого самого отличного результата, это и есть истинная мотивация. Но как только за результатом появляется «морковка», то результат сам по себе теряет ценность. Я уже не хочу выпускать качественные продукты и приносить пользу команде – я хочу завести не менее 144 дефектов в месяц, чтобы получить квартальную премию. Чувствуете разницу? В результатах работы она будет колоссальной. Сложный баг, непонятно как воспроизвести? У меня нет времени разбираться, я лучше 4 минора заведу, это будет выгоднее! Учитываем % отклонённых дефектов? Побоюсь заводить спорный баг. В итоге вы получите дубликаты, ниже качество дефектов, а потом и споры «нет, это не минор, это мажор, ты не объективен ко мне!» и «так я не 100% был занят на тестировании». То есть и объективность не получена, и демотивация, и конфликты.

3. Снижение качества работы

За счёт демотивации сотрудников и ориентации на циферки вместо истинных результатов вы 100% получите прирост по всем выбранным для измерения показателям, и 100% почувствуете в целом ухудшение работы команды. Но что нам чувства, если есть цифры, они-то объективны!

Сторонники числового измерения результатов работы в этом месте обычно объясняют проблему плохо подобранными метриками, не отображающими действительный результат. И впрямь, если метрики на 100% отображают качество работы, то такой проблемы не будет. Но, к огромному сожалению, в тестировании такие метрики невозможны.На заводе всё просто: сколько деталек в день, какой % брака. В тестировании, при всём желании, определить такие метрики невозможно.

Что делать, как жить?

Я не буду пускаться в долгую полемику на тему метрик, хотя с удовольствием отвечу на любые аргументированные комментарии в их пользу. В моей картине мира метрикам в тестировании места нет (опять же, на заводе – пожалуйста). Но описанные в начале статьи проблемы решать как-то всё же надо, если не метриками – то как?

1. Регулярная обратная связь

Сотрудники и без циферок должны знать, что их ждёт, какие их перспективы и куда они могут развиваться. По результатам исследований института Гэллапа люди, понимающие свои рабочие перспективы, работают в разы эффективнее и значительно более счастливы на работе (хотя далеко не все из них понимают важность обратной связи). Более того, многие большие боссы внедряют аттестации с метриками только для того, чтобы менеджеры наконец-то начали общаться со своей командой! А зря: я видела результаты таких «насильно» внедрённых регулярных аттестаций, толку от них всё равно нет. Просто старайтесь не реже раза в месяц общаться с каждым сотрудником тет-а-тет – это всем действительно необходимо!

2. Оперативная оценка задач

Чтобы сотрудники развивались, вы должны регулярно оценивать результаты их работы. Не раз в квартал и не сухими метриками. Делитесь с ними: что вам понравилось, что было не очень. При этом делайте эти оценки обязательно конструктивными! Слова из серии «ты молодец!» не просто не приносят пользы – они зачастую раздражают и вызывают недоверие и отдалённость от менеджера. А вот конкретная похвала заведению дефекта, найденному багу или интересному тесту – очень даже помогают вашим сотрудникам и дальше работать по высшим стандартам, понимая что именно от них требуется. Для критики правило своевременности ещё важнее – говорить «последний квартал ты работал на 22% хуже предыдущего» бесполезно, а вот своевременно комментировать плохо выполненные задачи – залог повышения качества работы.

3. Искренность в общении с сотрудниками и коллегами

Ваши циферки не нужны ни тестировщикам, ни сотрудникам из смежных отделов. Ваши сотрудники хотят искреннего общения, а ваши коллеги (разработчики, Рмы) – заинтересованности в общих проектных результатах. И если кто-то просит циферки – значит, просто не хватает правильного общения!

Остались вопросы? Вы всегда можете обсудить их на форуме!

Как измерить тестирование

Притча о KPI и отделе приемочного тестирования.

KPI в истории

KPI — Ключевые показатели эффективности (Key Performance Indicators) — показатели деятельности подразделения (предприятия), которые помогают организации в достижении стратегических и тактических (операционных) целей. ©Wikipedia

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

Можно много говорить о том, что важно не просто померить, а знать что и зачем мы мерим. Можно долго говорить… Можно даже быть уверенным в том, что мы проводим измерения того, что надо и так, как надо. Но почему-то уверенность остается в основном только в теории. На практике — беда-беда. Все вкривь и вкось.
Можно не говорить тем, кого измеряем, о том, что они под наблюдением. Можно. Но… Молчание будет не самым мудрым управленческим шагом — тайное всегда становится явным.  🙂

А теперь коротко и емко о том, почему KPI это не самое удачное решение в интеллектуальной среде.

Это на столько мощно, просто и изящно, что я не мог не скопировать. 🙂

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

В одной компании столкнулись с проблемой большого количества ошибок, пропускаемых в operation. На 10 ошибок, обнаруженных в процессе разработки, приходилось 10 ошибок, обнаруженных в процессе эксплуатации. Для борьбы с этой проблемой было принято решение об организации специального подразделения для проведения приемочного тестирования. Одним из KPI в рамках проекта создания такого подразделения, было требование снизить количество ошибок, всплывающих в процессе эксплуатации до 10% от суммарного количества ошибок. Т.е. 18 ошибок будет обнаруживаться в тестировании, и всего 2 будут приходить из эксплуатации.

После организации отдела и нескольких релизов неожиданно выяснилось, что эффективность тестирования не дотягивает до заданного KPI в 90%. В тестировании обнаруживалось 14 ошибок, но из эксплуатации приходило 8. Да, процент увеличился с 50% до 63%, но до заветных 90% оставалось еще очень далеко. А когда и очередной релиз ситуацию не улучшил, была проведена разъяснительная беседа с командой тестирования, о необходимости лучше относиться к своим обязанностям, ведь если цель не будет достигнута, может быть принято решение о расформировании свежесозданного подразделения. И отдел взялся за работу. Были найдены ошибки с присоединением файлов по 4 ГБ (система не предназначалась для хранения файлов, просто в одной из бизнес-операций необходимо было приложить скриншот), была обнаружена ошибка смещения на 4 пикселя текста подписи относительно элемента для ввода данных и т.д. Релиз всех впечатлил всего 9 ошибок из релиза против найденных в тестировании 42. А это уже 82%. Целевой KPI был все ближе.
Дальше уже можно и не рассказывать…
Когда девочка из отдела тестирования стала встречаться с мальчиком из отдела разработки, он не смог отказать любимой. Появилась куча мелких багов, за обнаружение которых девочку очень хвалили и ставили всем в пример.
После корпоратива, когда отдел тестирования нашел общий язык с ServiceDesk-ом, часть багов из релиза перестала фиксироваться в баг-трекере.
Так что, к дате отчета по проекту KPI был достигнут и даже немножко перевыполнен. А пользователи, ну что пользователи, в этом году всех интересовало успешное завершение проекта по внедрению приемочного тестирования.» © Алексей Лосев

PS. Это не единственное обоснование неуклюжести применения подхода на основе KPI.

Это Вам будет интересно:

12 ключевых показателей эффективности для менеджеров по контролю качества и тестирования

12 ключевых показателей эффективности для менеджеров по контролю качества и тестированию

Автор: Мэтт Ангерер

Как руководитель тестирования, вы сталкиваетесь с растущим требованием ускорять тестирование и выпускать программное обеспечение с меньшим количеством дефектов. Звучит просто, правда? Улучшение только этих двух факторов (скорости и эффективности обнаружения дефектов) требует сбалансированного сочетания людей, процессов и инструментов. При правильной организации любой может увеличить скорость тестирования своей команды и выявить больше дефектов до финального выпуска программного обеспечения.

Тем не менее, важно отметить, что множество поддерживающих ключевых показателей эффективности (KPI) помогут вам достичь вашей скорости и DDE. Соблюдая и превышая перечисленные ниже ключевые показатели эффективности, вы можете быть уверены, что продвинете свою организацию по обеспечению качества в сторону большей эффективности и оптимизации. Избавьтесь от мысли, что добавление дополнительных тестеров QA решит ваши проблемы. Часто даже автоматизация не является серебряной пулей, потому что она может привести к увеличению накладных расходов и обслуживания, чем это необходимо, наряду с долгосрочными затратами.Ответ, который вы ищете, кроется в данных.

Другими словами, закрепление вашей философии на оценочных картах QA и мониторинге KPI — это ключ к раскрытию всего потенциала вашей организации QA. В связи с празднованием праздничного сезона мы дарим вам 12 ключевых показателей эффективности (KPI) , которые ваша команда может отслеживать в 2016 году. Кстати, многие ключевые показатели эффективности легко настроить и отслеживать с помощью HP Application Lifecycle Management ( ALM) платформа.

1 — Активные дефекты

Отслеживание активных дефектов — довольно простой ключевой показатель эффективности, который вы должны отслеживать в любом случае.KPI активных дефектов лучше, когда значения ниже. Каждый программный ИТ-проект имеет свою долю дефектов. В зависимости от масштабов и сложности проекта я видел более 250 активных дефектов в любой момент времени. Слово «активный» для этого KPI может означать, что статус является новым, открытым или фиксированным (и ожидает повторного тестирования). В основном, если дефект «отработали», значит, он активен. Как менеджер тестирования, вы должны установить порог на основе исторических данных ИТ-проектов, над которыми вы контролируете.Будь то 100 дефектов, 50 дефектов или 25 дефектов — ваш порог определит, когда это нормально, а когда нет. Все, что превышает установленный вами порог, считается «Не в порядке» и должно быть отмечено для немедленных действий.

2 — Авторские тесты

Этот ключевой показатель эффективности важен для менеджеров по тестированию, потому что он помогает им отслеживать деятельность бизнес-аналитиков и инженеров по тестированию в процессе разработки тестов. По мере написания новых требований важно разработать соответствующие системные тесты и решить, следует ли помечать эти тестовые примеры для вашего набора регрессионных тестов.Другими словами, будет ли тест, который пишет ваш инженер-тестировщик, будет охватывать критически важную часть функциональности в вашем тестируемом приложении (AUT)? Если да, отметьте его для своего набора регрессионного тестирования и разместите для автоматизации. Если нет, то добавьте его в набор ручных тестов, которые при необходимости можно будет выполнять произвольно. Мы предлагаем отслеживать «Авторские тесты» по отношению к количеству требований для данного ИТ-проекта. Другими словами, если вы придерживаетесь философии, согласно которой каждое требование должно иметь тестовое покрытие (т.е.е., связанный тест), то вы должны установить порог для этого KPI, равный количеству требований или пользовательских историй, изложенных для спринта. Это равносильно одному (1) тесту для каждого требования в статусе «Готово».

3 — Автоматические тесты

Мы должны признать, что отслеживать этот KPI непросто. Существует множество мнений о том, что автоматизировать, а что не автоматизировать, а также о расходах, связанных с поддержанием автоматизации системных тестовых примеров.В целом, чем больше у вас автоматизированных тестов, тем больше вероятность того, что вы обнаружите критические дефекты, внесенные в поток поставки вашего программного обеспечения. Что мы бы посоветовали сделать с этим KPI, так это начать с малого и повышать его по мере развития и взросления вашей команды QA. Установите порог, при котором 20% тестовых случаев должны быть автоматизированы. Отследить это при тестировании HP ALM просто с помощью Project Planning and Tracking (PPT) — , а не , доступный в HP Quality Center Enterprise Edition.

4 — Охваченные требования

Как бывший менеджер по тестированию QA, это, безусловно, мой любимый KPI для отслеживания. Здесь мы будем отслеживать процент требований, удовлетворяемых хотя бы одним тестом. Стопроцентное покрытие тестами должно быть целью вашей организации по обеспечению качества в 2016 году. Обоснованность требования зависит от того, существует ли тест, чтобы доказать, работает он или нет. То же самое верно и для теста, который входит в ваш план тестирования. Достоверность этого теста зависит от того, был ли он разработан для проверки требования.Если это не прослежено до требования, зачем вам тест? Каждый день как менеджер тестирования вы должны отслеживать этот KPI, а затем подвергать сомнению ценность осиротевших требований и осиротевших тестов. Если они осиротели, найдите им дом, проследив за ними по конкретным требованиям.

5 — Дефекты, исправляемые за день

Не упускайте из виду, насколько эффективно ваши партнеры-разработчики работают над исправлением дефектов, на которые вы обратили их внимание.KPI «Исправление дефектов в день» гарантирует, что ваша команда разработчиков соблюдает «стандарт», когда дело доходит до исправления ошибок и продолжения сборки.

6 — Выполненные требования

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

7 — Пройденные тесты

Иногда вам нужно выйти за пределы уровня требований и внимательно изучить выполнение каждой конфигурации теста в рамках теста.Конфигурация теста — это в основном набор тестового примера, который вводит разные значения данных. KPI «Пройденные тесты» дополняет ваш KPI «Пройдено требований» и помогает понять, насколько эффективны ваши тестовые конфигурации для выявления дефектов. Имейте в виду, что с этим ключевым показателем эффективности вы можете быстро обмануть себя, если не будете хорошо разбираться в процессе разработки тестов. Тестовые примеры низкого качества часто дают удовлетворительные результаты, хотя на самом деле проблемы со сборкой все еще существуют.Убедитесь, что ваша команда усердно использует различные ветви логики при разработке тестовых примеров, и этот KPI будет более ценным.

8 — Отклоненные дефекты

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

9 — Проверенные требования

КПЭ проверенных требований — это скорее «КПЭ предотвращения», а не «КПЭ обнаружения». Если вы заметили, некоторые из перечисленных нами ключевых показателей эффективности ориентированы на обнаружение дефектов, а не на то, как их можно предотвратить при тестировании ALM. Однако этот KPI направлен на определение того, какие требования (или пользовательские истории) были проверены на предмет неоднозначности.Как мы знаем, неоднозначные требования приводят к неправильным проектным решениям и, в конечном итоге, к потере ресурсов. Как QA или менеджер по тестированию, вы обязаны следить за тем, было ли каждое из требований рассмотрено профильным экспертом (SME) в вашей организации, который действительно понимает бизнес-процесс, поддерживаемый технологией.

10 — Серьезные дефекты

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

11 — Экземпляры тестов выполнены

Этот ключевой показатель эффективности относится только к скорости выполнения вашего плана выполнения теста.Он не дает представления о качестве вашей сборки, вместо этого проливает свет на процент от общего числа экземпляров, доступных в тестовом наборе. Думайте об этом как о балансе для ваших тестовых экземпляров в ТЕСТ-ЛАБОРАТОРИИ тестирования HP ALM. Как менеджер тестирования, вы можете отслеживать этот KPI вместе с диаграммой выгорания при выполнении теста, чтобы определить, могут ли потребоваться дополнительные тестировщики для проектов с большим фокусом на ручное тестирование.

12 — Выполненные тесты

Построение этого KPI в HP ALM — это способ выйти за рамки тестовых экземпляров и контролировать все различные типы выполнения тестов, включая ручное, автоматическое и т. Д.Это не должно быть вашим единственным инструментом для отслеживания скорости во время заданного цикла выполнения спринта или теста. Также следует обратить пристальное внимание на описанные выше KPI. Этот KPI в большей или меньшей степени является KPI скорости, тогда как некоторые из перечисленных выше помогают отслеживать «профилактические меры», сравнивая их с «мерами обнаружения».

Мы надеемся, что наш список из 12 ключевых показателей эффективности поможет вам решить, что важно отслеживать в вашей организации по обеспечению качества и тестированию.Имейте в виду, что модуль планирования и отслеживания проектов (PPT) в HP ALM существенно отличается от HP Quality Center Enterprise Edition. Тестирование HP ALM позволяет оценить эффективность этих ключевых показателей эффективности, а также использовать динамическую систему показателей для отслеживания ключевых показателей в отношении конкретной версии.

Для получения дополнительной информации о передовых методах обеспечения качества и о том, как ResultsPositive может помочь, напишите нам по ссылке ниже:

.

7 самых важных ключевых показателей эффективности UX и способы их измерения

29. января 2019 ·
Время чтения 9 мин.

«То, что можно измерить, управляется, — сказал американский отец управленческого мышления Питер Друкер. К сожалению, эта мудрость еще не полностью проникла в общее сознание мира UX. Но без четких результатов и цифр вам будет сложно продвигать UX среди начальства и получать больше бюджета.

Хотели бы вы уйти от своей роли внутреннего Кларка Кента в своей компании и прекратить анонимно выполнять свои героические UX-дела для вашей организации, i.е. без явных доказательств? Вы хотите повысить признание и понимание UX? Если да, читайте дальше. UX часто ассоциируется со сложными анкетами и интервью с пользователями. Однако существует целый ряд ценных показателей эффективности UX, которые вы можете использовать, чтобы перевести успех и прогресс ваших усилий в области UX в осязаемые показатели.

Сделайте UX измеримым и укрепите UX-культуру своей компании

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

Скачать руководство

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

• Что такое KPI?
• В чем разница между KPI и ROI?
• Почему вы должны измерять KPI UX?
• Почему важно измерять правильные данные?

Готовы? Пошли!

Почему следует измерять KPI UX?

Медленно, но верно большинство компаний вступили в 21 век и ежедневно собирают большие объемы данных.Однако далеко не все данные относятся к делу: «В древние времена власть означала доступ к данным. Сегодня обладать властью означает знать, что игнорировать » , — пишет Юваль Ной Харари в своей книге« Homo Deus ». Многие организации используют такие показатели, как количество посетителей, для оценки успешности своего веб-сайта. Они думают: больше посетителей → больше успеха → все в порядке. Но действительно ли они измеряют KPI, которые эффективно «сдвигают иглу» и улучшают их чистую прибыль? Или они имеют дело с «показателями тщеславия», которые кажутся хорошими, но не приносят реальной пользы?

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

Что такое (UX) KPI?

KPI переводят факторы успеха вашего проекта, отдела или компании в числа, выявляя успехи и неудачи. Показатели эффективности обычно разные для каждого проекта и всегда должны определяться индивидуально.Например, KPI, относящиеся к Супермену, могут быть:

.

• Спасенных в час
• Время полета до прибытия на место преступления
• Время смены экипировки в наносекундах

Для отдела продаж компании коэффициент конверсии (например, 10 посещений клиентов → два заключения договора) часто очень важен. KPI UX отличаются от других KPI тем, что перед ними стоит сложная задача перевода человеческого поведения, мнений и чувств в числа. Поклонники UX различают поведенческих и установочных KPI UX:

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

KPI и ROI — в чем разница?

Используя ROI и KPI, компании могут измерить, насколько они успешно достигли определенной цели. ROI (возврат инвестиций) является чисто финансовым показателем и количественно определяет, насколько успешным был проект по отношению к его инвестициям. Например, если компания инвестирует 10 000 евро в UX-деятельность для улучшения своего интернет-магазина, а затем получает на 25 000 евро дополнительный доход в следующем году, это соответствует рентабельности инвестиций в 150%. KPI , с другой стороны, — это показатели, которые вы можете выбрать или определить самостоятельно, которые преобразуют успех проекта — как бы он ни определялся — в реальные цифры. Хотя рентабельность инвестиций — это только финансовый показатель, KPI актуальны практически для всех сотрудников организации — от сотрудников колл-центра до генеральных директоров — и могут применяться к различным процессам.

Зачем нужно измерять KPI UX?

Есть много причин для начала измерения KPI вашей организации.Это самые важные из них:

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

KPI помогают более успешно сообщать о проблемах UX и связанных с ними стратегических целях соответствующим лицам, принимающим решения в вашей компании. Больше не нужно очаровывать начальство расплывчатыми и качественными аргументами. Вместо этого вы можете основывать свои аргументы на холодных, неопровержимых фактах и ​​цифрах. Без этих показателей практически невозможно доказать до, во время или после проекта, были ли действия вашей UX-команды полезными и эффективными.Надежные данные также упрощают выдвижение аргументов, когда дело доходит до определения годового бюджета UX. Кроме того, если ваша зарплата включает бонус, связанный с производительностью, вам, вероятно, будет намного проще доказать свое «влияние» на чистую прибыль с помощью показателей KPI.

Тестирование UX

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

Система раннего предупреждения

KPI

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

Что следует измерять?

Ключом к успеху вашей UX-деятельности является измерение действительно актуальных KPI. Образно говоря, измерение окружности бедра пациента для лечения вывихнутой руки бесполезно. Лучше всего начать с измерения двух или трех наиболее важных ключевых показателей эффективности UX для вашей организации или проекта.Это поможет вам оставаться в курсе дел и с самого начала избежать ненужной путаницы. Для различных целей и проектов требуются определенные ключевые показатели эффективности UX, которые необходимо измерить. Вот два практических примера: Увеличение числа регистраций на веб-сайтах

• Время выполнения задачи (потока входа в систему)
• Частота ошибок пользователя

Больше продаж

• Уровень успешности задачи
• Количество кликов на покупку

Семь наиболее важных КПЭ UX

KPI UX делятся на поведенческие, и отношения, KPI:

Поведенческие KPI UX (что они делают)

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

1.1. Успешность задачи

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

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

• У пользователя 1 проблемы с оплатой кредитной картой
• Пользователь 2 не может найти желтые розы на сайте

В этом случае показатель успешности задачи рассчитывается следующим образом: 8/10 = 0,8 x 100 = 80% Совет эксперта: Также следует измерить TSR пользователей, выполняющих задачу первым. время. Это позволяет вам проверить, изменится ли эта метрика и как изменится, когда у пользователя больше опыта работы с услугой или продуктом.По сути, чем выше процент успеха, тем лучше пользовательский опыт.

2. Время выполнения задачи

Этот KPI описывает время (в минутах и ​​секундах), необходимое пользователю для успешного выполнения задачи. Среднее время выполнения задачи обычно указывается как окончательный KPI UX. По сути, чем короче время обработки, тем лучше для пользователя. Пример: Семи респондентам дается задание найти номер телефона службы поддержки на веб-сайте.На это у них уходит время:

В этом случае время выполнения задачи рассчитывается следующим образом: (22 + 15 + 60 + 24 + 18 + 31 + 17) / 7 = 26.71 секунда

3. Поиск и навигация

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

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

1 2 3 4 5 6 7 8 9 # %

Расчет соотношения поиск / навигация: Search 3/9 = 0.33 x 100 = 33% Навигация 6/9 = 0,66 x 100 = 66%

4. Частота ошибок пользователей

Коэффициент ошибок пользователя (UER) — это количество раз, когда пользователь делает неправильный ввод. Рассмотрим пример обычно безуспешной попытки ввести дату рождения пользователя в поле адреса. UER дает вам представление о том, насколько понятен и удобен ваш веб-сайт. Чем выше оценка UER, тем больше проблем с удобством использования. Опять же, важно заранее определить, какие действия представляют собой ошибку.Уровень ошибок пользователя можно рассчитать по-разному. Вот два наиболее распространенных типа измерения: Частота появления ошибок: Если задача допускает только одну потенциальную ошибку (или их несколько, и вы хотите измерить только одну из них), используйте эту метрику.

Пример: Пять из 100 пользователей неправильно вводят свой адрес электронной почты в поле «Повторить адрес электронной почты». Частота появления ошибок рассчитывается следующим образом: 5/100 = 0,05 x 100 = 5% Частота ошибок: Если для одной задачи возможно несколько ошибок (или вы хотите измерить несколько ошибок), вы можете сделать это, используя коэффициент ошибок.

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

Коэффициент ошибок рассчитывается следующим образом: (3 + 1 + 2 + 3 + 2 + 1) / 6 × 5 = 0.4 х 100 = 40%

Attitudinal UX KPI (что они говорят)

Этот тип UX KPI измеряет, как пользователи чувствуют или что они говорят до, во время или после покупки продукта. В этом разделе я представлю три ярких примера этого типа:

5. Шкала удобства использования системы (SUS)

По словам ее изобретателя Джона Брука, шкала удобства использования системы (SUS) — это «быстрый и грязный» инструмент, с помощью которого вы можете проверить удобство использования продукта.Шкала состоит из 10-балльной анкеты с пятью возможными ответами на каждый, от полностью согласен до полностью не согласен .

Пример: Вы хотите измерить ценность юзабилити своего веб-сайта. Используя результаты анкеты, вы можете рассчитать оценку «SUS» (от 0 до 100), которая в среднем составляет 68. Следовательно, если ваш веб-сайт имеет рейтинг ниже 68, он обычно имеет серьезные недостатки и нуждается в оптимизации.

6.Чистая оценка промоутера (NPS)

Показатель Net Promoter Score показывает удовлетворенность и лояльность клиентов с помощью одного простого показателя. Несколько исследований также подтвердили, что NPS является статистически значимым и коррелирует с ростом компании. Для определения NPS пользователю задается только один центральный вопрос: Насколько вероятно, что вы порекомендуете (бренд, веб-сайт, услугу и т. Д.) Другу или коллеге? Пользователь отвечает на этот вопрос по шкале от одного (очень маловероятно) до 10 (очень вероятно).Затем ответы сгруппированы по трем категориям, при этом «пассивы» не учитываются при расчетах:

• Противники: от 0 до 6
• Пассивные: от 7 до 8
• Промоутеры: от 9 до 10

Net Promoter Score: (Количество промоутеров — количество недоброжелателей) ÷ (количество респондентов) x 100 Пример: Опрос с 50 участниками дает следующие результаты:

Вот как рассчитывается Net Promoter Score: (30-10) ÷ 50 = 0.4 x 100 = 40% Дополнительную информацию о NPS и его расчетах можно найти здесь.

7. Удовлетворенность клиентов (CSAT)

CSAT — это еще один KPI UX, который выражает удовлетворенность клиентов в удобной метрике. У пользователей / тестировщиков спрашивают: Насколько вы удовлетворены (веб-сайтом, продуктом, услугой и т. Д.)? Результат представляет собой процент от 0 до 100, где 100 означает максимальное удовлетворение запросов клиентов. Шкала обычно включает пять вариантов оценок: от очень недоволен до очень доволен .Поскольку оценку CSAT можно определить быстро и легко, ее также можно измерить в нескольких точках взаимодействия с клиентом (например, на этапах TOFU, MOFU и BOFU). С помощью этого метода можно определить, в какой точке воронки клиент все еще может застрять. Удовлетворенность клиентов: (Количество довольных клиентов) / Количество респондентов x 100 =% довольных клиентов Результаты опроса затем классифицируются и оцениваются следующим образом:

1. 1. Очень не доволен
   2. Недоволен
   3. нейтральный
   4. Доволен
   5. Очень доволен

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

1 2 3 4 5 6 7 8 9 10

Оценка CSAT рассчитывается следующим образом: (5/10) = 0.5 x 100 = 50% Дополнительную информацию о рейтинге удовлетворенности клиентов можно найти здесь.

Сводка

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

Сделайте UX измеримым и укрепите UX-культуру своей компании

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

Скачать руководство

Вы уже определили ключевые показатели эффективности UX для своей организации? Если да, то какие показатели вы используете и почему? Что изменилось (положительно) с тех пор, как вы начали измерения? Как с тех пор развивалось ваше влияние в компании? Если нет, то что вам мешает измерить? Что должно произойти, чтобы вы начали измерения?

.