Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Привет, Хабр! Меня зовут Артур Кашбуллин, я работаю в РСХБ‑Интех исполнительным директором в Блоке обеспечения и контроля качества выпуска изменений ПО. Наш Блок занимается тестированиям доработок перед их выпуском в промышленную среду и отвечает за качество продуктов, выпускаемых банком. Сегодня расскажу об отчетности, которую мы используем для контроля текущей деятельности, ее корректировки, в случае необходимости, и совершенствования процессов работы в целом.
В Блоке мы используем два вида отчетности: оперативную и управленческую.
Оперативная отчетность позволяет наблюдать за ходом производственных процессов тестирования и является инструментом для контроля текущих задач и выполнения отдельных работ в моменте, т. е. «здесь и сейчас», с возможностью ее коррекции.
Цель — получение возможности проведения оперативного анализа и принятия решений по управлению ходом работ, а также для формирования статистических данных. Оперативная отчетность у нас собирается еженедельно и при необходимости мы к ней обращаемся, чтобы оценить текущее состояние дел, понять движение работ по релизу, равномерность загрузки сотрудников и не требуется ли вмешательство в процесс тестирования.
Управленческая отчетность представляет собой набор взаимосвязанных показателей, характеризующих результаты деятельности ЦК в отдельности или Блока в целом за некий период времени. Она состоит из обобщенных итоговых показателей, которые формируются по итогу выпуска релиза. Интеграционные релизы у нас осуществляются ежемесячно, соответственно данные по такой отчетности собираются после выпуска релиза + 2 недели для оценки показателей качества тестирования и накопления данных.
Вся отчетность консолидируется в Confluence для удобного доступа не только руководителями ЦК, но также руководителей Блока и других подразделений.
Теперь расскажу о показателях, которые мы используем, и для чего они нужны.
Оперативная отчетность
Такая отчетность предназначена для операционных руководителей — это руководители центров компетенций. Основными параметрами анализа являются:
«Текущие задачи ЦК в разрезе сотрудников»,
«Дефекты блокирующего, критичного и высокого приоритета в разрезе статусов»,
«Нарушение/выполнение SLA исправления дефектов»,
«Готовность функционала к выпуску (в разрезе тестового покрытия)».
Параметр «Текущие задачи ЦК в разрезе сотрудников» дает представление о загруженности, плановых работах, а также дает возможность обратить внимание на задачи в статусе, например, «Отложено», и оперативно выяснить причины перегрузов сотрудников, проблемы с «зависшими» задачами и, в случае необходимости, оперативно произвести перепланирование задач для устранения возможных рисков дальнейшего перегруза либо срыва запланированных сроков передачи задачи на следующий этап работ.
Например, если мы в моменте времени видим, что у Иванова, Петрова и Сидорова в работе 2–3 задачи, а у Хачатуряна 10 задач, это должно вызвать у руководителя вопрос, почему так, так как видно, что сотрудник излишне перегружен и необходимо принимать меры по перераспределению задач. Большое количество задач в статусе «Отложено», также вызывает опасение, так как нет понимания причин этого явления. Задачи могут быть отложены по конкретным причинам, например, со стороны тестирования, разработки или они требуют дальнейших работ. Соответственно, и большое количество задач, запланированных на тех или иных сотрудников, требует анализа достаточности ресурсов специалиста.
Параметр «Дефекты блокирующего, критичного и высокого приоритета в разрезе статусов» дает представление о количестве имеющихся дефектов, и в каком статусе они находятся. Либо мы их нашли и уже исправили, либо они находятся в работе. Также по этому параметру можно отследить, нет ли нарушений по исправлению, так как дефекты должны быть доработаны до окончания релиза. Акцент мы делаем на приоритеты дефектов: например, доработку с приоритетами дефектов «Средний» и «Низкий» мы можем выпустить по согласованию с заказчиком, а вот критичные дефекты могут блокировать работу не только тестируемого ПО и взаимосвязанных систем.
Данный параметр необходимо рассматривать в совокупности с «Нарушение/выполнение SLA по исправления дефектов», так как он напрямую влияет на срок тестирования, ограниченный плановыми датами релизного цикла. Этот параметр дает представление, нарушаются ли сроки исправления выявленных дефектов или все идет по плану. Для каждого приоритета установлены свои сроки исправления: для блокирующих это 5 часов, для критических — 10, для высоких — 14. Соответственно, если дефекты были выявлены и исправлены в срок, в этом случае мы сможем соблюсти плановые релизные сроки. Но если есть нарушения SLA, уже стоит начинать бить тревогу, так как любые задержки при тестировании могут привести к сдвигам сроков работ по задаче, а соответственно выхода модификации к конечному пользователю/клиенту.
Все вышеперечисленные параметры формируются автоматически, на основе данных из JIRA: либо это сформированные фильтры, либо разработанные отчеты, либо настроенные дашборды.
Параметр «Готовность функционала к выпуску (в разрезе тестового покрытия)» формируется на основе данных в Test IT (тест‑планов). Мы формируем тест‑планы в разрезе задач по релизу, что позволяет контролировать статус готовности к выпуску: процент пройденных проверок, проваленных и пропущенных тест‑кейсов. Это также позволяет в моменте выявить возможные риски и проблемы, отставание по срокам, снижение охвата тестирования и т. д., а также оперативно вмешаться при необходимости и устранить проблемы. Из практики использования это дает представление, на сколько процентов задача готова к релизу, если при анализе выясняется, что до выпуска остается неделя, а процент прохождения кейсов составляет например 50%. По такой задаче осуществляется дополнительный анализ и, возможно, корректировка состава релиза и дальнейшее детальное выяснение возникших проблем с выпуском компенсационных мер для устранения в будущем таких ситуаций.
Управленческая отчетность
Управленческая отчетность предназначена для руководителя Блока и управленческого состава организации. Каждый отчет собирается по отдельной системе. Она имеет обобщенный характер и несет итоговую информацию по выпущенному релизу, на основе которого можно сделать выводы по его качеству и «тонким» местам для будущих улучшений работы Блока. Формат сводных таблиц содержит достаточно большое количеством параметров. Одна из таких таблиц — «Сводные показатели KPI».
Эта таблица состоит из параметров таких как:
Релиз/Месяц — указывается месяц рассматриваемого релиза.
Вид тестирования — указывается вид проводимого тестирования.
Количество БИ в релизе/месяце — Заполняется количеством БИ, вошедших в релиз по конкретной системе.
Охват тестирования релиза (%) — Заполняется отношением общего количества БИ, вошедших в релиз, к БИ, в тестировании которых принимали участие специалисты Блока качества. Этот показатель стремится к 100%, но по тем или иным причинам есть такие задачи, которые проходят мимо нас, соответственно, если процент низкий, то стоит обратить внимание и выяснять, почему задачи не попали к нам на тестирование.
Выполнение сроков тестирования в релизе (%) — Заполняется отношением количества БИ, вошедших в релиз, к БИ, в которых плановая дата начала имеет расхождение с фактической датой начала на более чем 1 день. Конечно, ситуации бывают разные, но низкий процент этого показателя также должен насторожить. Тут следует понимать: либо поставка по доработке к нам пришла не вовремя, либо специалист по тестированию не смог приступить к работе в срок. В любом конкретном случае необходимо разбираться индивидуально.
Тестовое покрытие релиза (%) — Заполняется отношением количества БИ, вошедших в релиз, к БИ без тестовой документации. Подразумевается, что все задачи должны быть описаны и для выпуска в прод содержать артефакты тестирования, отклонение этого показателя от 100%, фактически, не допустимо.
Выполнение плановой длительности этапов (%) — Заполняется отношением фактической длительности тестирования релиза к плановой длительности тестирования релиза. Заполняется для регрессионного тестирования и нагрузочного тестирования. На РТ и НТ у нас отведено определенное количество дней, и если этот показатель имеет отклонение от 100%, то нужно выяснять, где и что пошло не по плану.
Фактическая длительность этапов (дн.) — Указывается фактическая длительность этапов регрессионного и нагрузочного тестирования в ч/д.
Количество БИ с задержкой поставки — Указывается количество БИ, в которых плановая дата поставки имеет расхождение с фактической датой поставки на более чем 1 день.
Задержки поставок в днях — Заполняются минимальное значение, максимальное значение и среднее значение расхождений по всем БИ в ч/д. Эти два показателя нам дают понимание, сколько же всего было проблемных задач. В идеале их конечно же должно быть 0, но, как мы знаем, мир не совершенен, а если бы был совершенен, зачем нужны были бы тестировщики.
Следующая таблица — это таблица с дефектами, которая содержит информацию о выявленных дефектах в процессе тестирования, а также информацию о дефектах прода.
Релиз — Указывается месяц рассматриваемого релиза.
Количество БИ выпускаемых в релиз (шт.) — Заполняется количеством БИ, вошедших в релиз по конкретной системе.
Всего дефектов на всех этапах тестирования — Заполняется общим количеством дефектов на всех этапах тестирования, ФТ+РТ+ПСИ.
Всего дефектов на этапе функционального тестирования (ФТ) — Заполняется общим количеством дефектов, выявленных на этапе функционального тестирования, вне зависимости от приоритета.
ФТ приоритет Блокирующий и Критический — Заполняется количеством дефектов, выявленных на этапе функционального тестирования, и имеющих приоритет Блокирующий и Критический.
Качество заведения дефектов ФТ (%) — Заполняется отношением общего количества дефектов, выявленных на этапе функционального тестирования, к ошибкам, имеющим статус «Отклонено», выявленных на этапе функционального тестирования. Соответственно дефекты в статусе «отклонено» — это ошибочно заведенные дефекты, например, человек не разобрался с функционалом и начинает заводить все подряд как ошибку.
Всего дефектов на этапе приемочного тестирования (ПриемТ) — Заполняется общим количеством дефектов, выявленных на этапе приемо‑сдаточных испытаний вне зависимости от приоритета.
ПСИ приоритет Блокирующий и Критический — Заполняется количеством дефектов, выявленных на этапе приемо‑сдаточных испытаний, и имеющих приоритет Блокирующий и Критический.
Всего дефектов на этапе регрессионного тестирования (РТ) — Заполняется общим количеством дефектов, выявленных на этапе регрессионного тестирования, вне зависимости от приоритета.
РТ приоритет Блокирующий и Критический — Заполняется количеством дефектов, выявленных на этапе регрессионного тестирования и имеющих приоритет Блокирующий и Критический.
Качество заведения дефектов РТ (%) — Заполняется отношением общего количества дефектов, выявленных на этапе регрессионного тестирования, к ошибкам, имеющим статус «Отклонено», выявленных на этапе регрессионного тестирования.
Кол‑во ошибок на проде, связанных с релизом (шт.) — Заполняется общим количеством дефектов, выявленных в промышленной среде, вне зависимости от приоритета.
Кол‑во ошибок блокирующего, критического приоритета на проде (шт.) — Заполняется количеством дефектов, выявленных в промышленной среде и имеющих приоритет блокирующий и критический.
Кол‑во ошибок высокого приоритета на проде (шт.) — заполняется количеством дефектов, выявленных в промышленной среде, и имеющих приоритет высокий.
Следующая таблица более интересная. Она включает в себя детальный анализ ошибок прода. Каждая ошибка, относящаяся к релизу, разбирается досконально, вплоть до специалиста, действие которого привело к той или иной ошибке. Это необходимо для понимания уровня зрелости команд и специалистов в них, чтобы можно было в дальнейшем поднять их компетенции.
Релиз/Месяц — указывается месяц рассматриваемого релиза.
Количество БИ выпускаемых в релиз (шт.) — Заполняется количеством БИ, вошедших в релиз по конкретной системе.
Количество БИ тестируемых Блоком — Заполняется количеством БИ релиза, в тестировании которых принимали участие специалиста Блока.
Кол‑во ошибок на проде, связанных с релизом (шт.) — Заполняется общим количеством дефектов, выявленных в промышленной среде, вне зависимости от приоритета.
Кол‑во ошибок блокирующего, критического приоритета на проде (шт.) — Заполняется количеством дефектов, выявленных в промышленной среде, и имеющих приоритет блокирующий и критический.
Кол‑во ошибок прома с типом «Ошибка установки» — Заполняется количеством дефектов, выявленных в промышленной среде, с типом «Ошибка установки».
Номер найденного дефекта на проде — Заполняется номером дефекта прода из HPSM с приоритетом блокирующий, критический, высокий.
Вид тестирования — Заполняется видом тестирования, на этапе проведения которого был пропущен дефект.
Была ли ошибка найдена на этапе тестирования (Да/Нет)
Номер дефекта, найденного на этапе тестирования — Заполняется номером дефекта из JIRA, если ошибка была ранее найдена при тестировании.
Номер BIQ, которому относится дефект — Заполняется номеров BIQ, в процессе тестирования которого относится найденный дефект (заполняется при виде тестирования ФТ).
Система найденного дефекта — Заполняется наименованием системы, при тестировании которой был пропущен дефект.
ЦК тестирования пропустившего дефект — Заполняется наименование ЦК, проводившего тестирование.
Система найденного дефекта — Заполняется наименованием системы, при тестировании которой был пропущен дефект.
Название команды пропустившей дефект (КФК/Waterfall) — Заполняется наименованием команды, в процессе тестирования которой был пропущен дефект.
Количество тестировщиков Блока участвующих в команде — Заполняется количеством тестировщиков Блока, входящих в команду.
Грейд тестировщика Блока пропустившего дефект — Заполняется грейдами тестировщиков, входящих в команду тестирования.
ФИО специалиста команды, отвечающего за тестирование — Указывается ФИО специалиста команды, отвечающего за тестирования BIQ, в процессе тестирования которого был пропущен дефект.
Грейд специалиста команды, отвечающего за тестирование — Заполняется грейдом тестировщика команды, пропустившего дефект.
Таблица огромная, поэтому пример вставлять не буду. :) Выше указаны все параметры, которые перечислены в таблице, каждый параметр это отдельный столбец.
Ну и последняя и не такая большая и страшная таблица — SLA по дефектам тестовой среды. Она дает нам представление, насколько соблюдаются сроки исправления дефектов. Как я ранее говорил, любые задержки могут привести к срывам выпуска доработок в прод. Соответственно, если эти показатели имеют значительные отклонения от регламентных сроков, то тут уже требуется детальный разбор с командой разработки на предмет нарушения сроков.
Месяц/SLA по приоритетам — указывается месяц рассматриваемого релиза.
Вид тестирования — указывается вид тестирования.
Средний SLA по дефектам (расчетный/регламентный (ч)).
Так что же нам дало внедрение этой отчетности?
Во‑первых, у руководителей ЦК появился инструмент, позволяющий оперативно находить и устранять проблемные места.
Во‑вторых, руководитель Блока или ИТ департамента в целом имеет наглядное представление о ситуации с выпущенным релизом, и какие проблемы возникли в процессе работы над ним.
В‑третьих, собираемая статистика по этим отчетам дала представление о тех самых «тонких» местах, требующих улучшения, за счет этого ряд проблем был устранен, а над другими ведутся планомерные работы по улучшению процесса.
Все это в совокупности привело к улучшению качества тестирования и к сокращению выявленных на промышленной среде дефектах.
