Тема внедрения KPI в тестирование является актуальной уже много лет, этому вопросу посвящено немало исследований. В данной статье мы на примере реального проекта рассмотрим процесс внедрения KPI и методику оценки качества нашей работы.
Что такое KPI?
Итак, для начала обратимся к самому понятию KPI. KPI (Key Performance Indicator) – это показатель достижения успеха в определенной деятельности или в достижении определенных целей. Можно сказать, что KPI – это количественно измеримый индикатор фактически достигнутых результатов.
Зачем нам KPI?
Теперь давайте поговорим о том, зачем нам понадобились KPI на проекте, и почему мы решили их внедрить. Здесь все просто: мы хотели видеть состояние проекта в любой момент времени и принимать превентивные меры, дабы избежать проблем. Благодаря KPI руководитель направления тестирования на проекте не только видит сильные и слабые стороны проекта и всей своей команды, но и может отслеживать в динамике последствия своих собственных управленческих решений (что было сделано правильно, какие из принятых решений были удачными или неудачными), а в дальнейшем – корректировать их.
Кроме того, в KPI можно включить не только общепринятые количественные показатели, но и качественные (например, «уровень удовлетворенности заказчика»). Но давайте обо всем по порядку!
Откуда взять KPI?
Какие метрики подойдут проекту? Как их считать? Существует ли какая-то база с набором метрик, из которых сложатся KPI?
Как было у нас
Теперь я, как и обещала, расскажу о наших действиях на проекте.
Итак, моя команда тестировала внутреннее программное обеспечение заказчика, состоящее из нескольких больших функциональных блоков, а также интеграцию ПО с бэк-офисными системами хранения данных.
Сразу уточню, что под заказчиком в статье я буду понимать любое лицо, заинтересованное в тестировании продукта и стремящееся добиться того, чтобы продукт удовлетворил нужды конечных пользователей и отправился в промышленную эксплуатацию.
Сформировав ожидания (или опасения) нашего заказчика, мы должны трансформировать их в цель. Нетрудно догадаться, что целью нашего тестирования стало проведение комплексной оценки качества продукта путем интеграционного и функционального тестирования программного обеспечения заказчика.
Теперь нам предстояло провести процесс декомпозиции, то есть разбиения глобальной цели на небольшие решаемые задачи для проектной команды. Кстати, в этом мне помогла сама команда! Давайте посмотрим, как же это происходило, но для начала вновь уточним сам термин «декомпозиция», разложив все по полочкам.
Декомпозиция
Что такое декомпозиция? Декомпозиция – это научный метод, использующий структуру задачи и позволяющий заменить решение одной большой задачи решением серии меньших подзадач, пусть и взаимосвязанных, но более простых. Принцип декомпозиции состоит в том, что тестируемое приложение (отдельный его модуль или функционал) можно рассматривать как состоящий из относительно независимых друг от друга подсистем, каждую из которых тестировать гораздо проще и понятнее, чем всю систему сразу.
Если заказчик хочет получить тестирование интеграции – значит, нам нужно провести декомпозицию интеграционного функционального тестирования продукта. Для этого необходимо понять, из каких частей состоят системы заказчика, сколько вообще систем участвует в обмене данных, какие действия и над какими объектами могут совершать пользователи систем и т.д.
Принцип SMART
Вообще, SMART – это мнемоническая аббревиатура, которую используют управленцы разных уровней для запоминания принципов постановки задач. Каждая буква аббревиатуры имеет свою расшифровку:
- Specific – конкретный. Ставя задачу, мы должны четко понимать, какого результата хотим достичь. Результат должен быть однозначным и понятным всем участникам процесса – сотрудникам команды тестирования, заказчикам, руководителям разных уровней.
- Measurable – измеримый. Нам нужны задачи, которые могут быть измерены. Иными словами, измеримость предполагает наличие критериев – измерителей, показателей выполнения.
- Attainable – достижимый. В данном случае определение «достижимый» я бы переименовала в «доступный» (доступный для выполнения сотрудником с определенным уровнем подготовки и квалификации). Грамотный руководитель никогда не даст новичку сверхсложную задачу, так как понимает, что новичок с ней просто не справится, а время, затраченное на попытки решения, уже не вернуть. Учет личностных особенностей и качеств сотрудников команды тестирования на проекте позволит очень четко (а главное – равномерно и посильно) распределить нагрузку, дать новичкам несложные задачи, а «звездочкам» и профи – задачи со сложной логикой в соответствии с их силами и навыками.
- Relevant – актуальный, значимый. Действительно ли выполнение задачи так важно для нас? Является ли данная задача необходимой именно сейчас? Что мы получим, если решим эту задачу? А если не решим?
- Time-bound – ограниченный во времени. Любая задача должна иметь свой срок, в течение которого ее необходимо решить. Установление временных рамок и границ для выполнения задачи позволяет сделать процесс контролируемым и прозрачным. Руководитель в любой момент времени может увидеть прогресс выполнения задачи.
Итак, теперь у читателя есть понимание, по каким критериям можно декомпозировать большую задачу. Мы можем двигаться дальше.
- покрываем тестами весь основной функционал, задействованный в интеграции;
- разрабатываем тестовые сущности и данные;
- тестируем задачи по доработке функционала;
- заводим дефекты, найденные при тестировании;
- проверяем релизы и хот-фиксы;
- убеждаемся, что на каждой новой версии продукта из одной системы в другую возможно передать два приоритетных продукта.
Помимо этих основных подзадач я выделила еще несколько дополнительных:
- мы не хотим тратить время, объясняя разработчикам, «в чем тут баг, и как его можно воспроизвести», а поэтому будем заводить грамотные и понятные дефекты;
- наши работы по тестированию должны быть максимально прозрачными, поэтому мы будем предоставлять промежуточный статус по состоянию версии заказчику;
- мы хотим, чтобы заказчику понравилось с нами работать, и в следующий раз он снова обратился к нам.
- каково состояние версии;
- какие модули продукта являются самыми критичными и забагованными;
- на какие модули следует обратить особое внимание;
- какие показатели работают для приоритетных продуктов;
- можно ли отдавать продукт в промышленную эксплуатацию.
Теперь давайте вместе пройдемся по каждой подзадаче и рассмотрим измеримые показатели (метрики).
Метрики, из которых складываются KPI
Покрытие функционала тестами. Как мы его можем измерить? Мы остановились на метрике «% покрытия xx числа модулей продукта тестами» (более подробную информацию о том, как это посчитать, вы можете найти в статье Натальи Руколь «Оценка тестового покрытия на проекте»).
Разработка тест-кейсов и тестовых сущностей. Здесь мы решили работать с метрикой «количество модулей / функциональных блоков продукта, для которых разработано 100% сущностей».
Тестирование доработок заказчика. В данном случае мы просто посчитали число протестированных доработок на версии и среднее время, затраченное командой на проверку. Мы собрали эти показатели для того, чтобы оценить, на что была направлена версия (на багфиксинг или на внедрение новых функциональностей заказчика), а следовательно, укладываемся ли мы по срокам реализации определенных фич.
«Заведение дефектов». Мы решили воспользоваться несколькими метриками, которые бы давали нам информацию о состоянии версии: «количество дефектов, заведенных командой», «количество дефектов приоритета Blocker на версии».
Последнюю метрику мы считаем по формуле:
где P1 – passed-шаги по первому блоку,
P2 – passed-шаги по второму блоку,
Pn – passed-шаги по n-ному блоку,
A1 – число шагов по первому блоку,
А2 – число шагов по второму блоку,
An – число шагов n-ного блока,
N – общее число всех блоков продукта.
Aп1 – все значения для продукта один.
Разобравшись с основными задачами, мы перешли к дополнительным.
Для оценки «удовлетворенности заказчика» мы ввели три уровня – «все отлично», «есть небольшие замечания / вопросы к работе» и «все плохо, заказчик недоволен». Этот показатель, кстати, вообще очень помогает с оперативным принятием решений внутри проектной команды. Если заказчик чем-то недоволен или огорчен, мы по «горячим следам» проводим обсуждение: стараемся минимизировать риски, понять причины недовольства, в максимально короткие сроки проработать решение и представить его заказчику.
Что в итоге нам дают KPI
Подготовка KPI проекта – процедура затратная, но интересная и полезная, и вот почему.
Собирая перечисленные выше метрики, я могу получить ответы на вопросы: что именно моя команда сделала хорошо, по каким показателям мы выросли, были ли правильны и своевременны мои управленческие решения. В любой момент времени я могу ответить заказчику на следующие вопросы:
После внедрения метрик на моем проекте стало легче готовить промежуточную отчетность для заказчика, вся проектная команда (а у ребят есть доступ к KPI проекта) прикладывала максимум усилий для роста наших по
казателей, все стали более внимательными и сосредоточенными!
Вместо заключения
В «Лаборатории качества» мы пошли чуть дальше и все же решили собирать базу метрик, которые применимы на наших проектах. Нет, я не говорю, что можно брать готовый материал и работать с ним, но каждый менеджер, столкнувшийся с темой внедрения KPI на своем проекте, может обратиться к этой базе, посмотреть метрики, из которых собираются KPI на других проектах, и адаптировать эти метрики под свои нужды. Также мы подготовили внутренний регламент (своеобразную инструкцию по внедрению KPI на проектах), с помощью которого этот процесс проходит плавно и безболезненно.