|
 Автор: Нина Агеева, тест-менеджер компании "Лаборатория качества"
Оригинальная публикация: http://quality-lab.ru/kpi-in-testing/
Тема внедрения 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 на проекте: эти затраты полностью окупятся! Ваш заказчик будет удовлетворен проведенными работами и отличным качеством продукта. Он вновь и вновь обратится к вам за помощью!
|
