Наш блок разработки планировал цикл «программирование — тестирование — внедрение» только исходя из доступности своих ресурсов. А проектов было много. Тестировщиков ставили перед фактом: мол, есть задача, проверить нужно вчера — погнали. В итоге задачи наслаивались, тестировщики фигачили без перерыва, роптали и сбегали в другие компании. Надо было это прекращать — и мы вышли из положения с помощью Excel. И вот как нам это удалось.

Мы решили написать приложение, позволяющее равномерно планировать нагрузку на тестировщиков и, если что, быстро её корректировать. Изучив разные инструменты планирования, поняли, что подойдёт обычный Excel. Это быстро и функционально. А проверив работоспособность идеи “в бою”, уже можно переложить ее в код. 

Как вообще устроено тестирование в банках?

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

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

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

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

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

Ожидание vs реальность

Наш планировщик должен:

• вычислять трудоёмкость задач, которые может переварить каждое отдельное функциональное направление за расчётный период;

• оперативно определять распределение задач на каждого тестировщика для выявления его загрузки;

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

Так как все задачи по реализации проектов у нас ведутся в Jira, нужно было, чтобы все изменения по планированию фиксировались там и оперативно выгружались в планировщик-калькулятор. Проанализировав готовые решения, мы пришли к выводу, что разработка автоматизированного инструмента планирования займёт время, и в ожидании реализации решили настроить выгрузку в Excel, а уже в нём настраивать всё как душе угодно.

В результате мы смогли получить:

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

• удобное графическое отображение информации (типа диаграммы Ганта), в том числе лёгкую и быструю фильтрацию нужных данных;

• гибкость/лёгкость доработки/изменения инструмента при необходимости.

Как это работает

Общая концепция планировщика-калькулятора загрузки такова: сначала из Jira в Excel выгружается выборка данных, т. е. список задач по фильтру с необходимой структурой. Далее эта выгрузка вставляется в планировщик-калькулятор, и на основании выгрузки рассчитываются дополнительные параметры. К примеру, проверяется корректность заполнения процента загрузки, подсвечиваются просроченные даты, выделяются незаполненные поля и тому подобное. При внесении изменений в задачи Jira выгрузка первичных данных для планировщика занимает всего несколько минут. Частота выгрузки зависит от глубины планирования.

Ресурсы

На листе «Ресурсы» заполняются данные по  доступным к планированию ресурсам, указывается принадлежность к функциональному направлению/команде, ресурсному пулу и т. д.

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

Так как планирование ведется на горизонте 2-3 месяца, то листов «Ресурсы» может быть несколько – по отдельному на каждый планируемый месяц. Тут же учитывается план/факт приёма новых сотрудников, увольнения, плановые отпуска, ротация между направлениями. В результате при планировании учитывается тот факт, что ёмкость групп от месяца к месяцу меняется. Это позволяет видеть картину в разрезе каждого месяца.

Затем данные с листа «Список задач» тянутся на лист «Планирование».

Планирование

Здесь визуализируются:

1.    Данные о длительности и трудоёмкости задач графически (в виде диаграммы Ганта). В результате мы наглядно видим, в какие даты/периоды и с какой загрузкой запланированы задачи.

Логика заложена следующая: на пересечении столбцов даты и строк задач заполняется значение процента загрузки, если выполняются следующие условия:

• дата попадает в период между датой начала и сроком исполнения задачи;

• дата попадает на рабочий день (проводится проверка: Дата НЕ попадает на выходной день и НЕ попадает в Список выходных дней);

• статус задачи не равен Отложено.

В случае, если условия не выполняются, в ячейке выставляется значение “0”.

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

Ниже на листе рассчитываются и заполняются 3 таблицы в виде той же диаграммы Ганта на основании «ленты» дат:

• В первой таблице рассчитываются суммарные плановые трудозатраты в разрезе ресурсных пулов за каждую дату. В строках таблицы отображается наименование ресурсного пула и далее расчёт по формуле: =СУММЕСЛИ(диапазон из столбца «Ресурсный пул» из таблицы задач; Наименование ресурсного пула; диапазон процента загрузки за Дату).

• Во второй таблице рассчитываются суммарные плановые трудозатраты в разрезе функц. направлений за каждую дату. В строках таблицы наименование функц. направления и далее расчёт по формуле: =СУММЕСЛИ(диапазон из столбца «Функц.направление» из таблицы задач; Наименование функц.направления; диапазон процента загрузки за Дату).

• В третьей таблице рассчитываются суммарные плановые трудозатраты в разрезе тестировщиков за каждую дату. В строках таблицы ФИО тестировщика и далее расчёт по формуле: =СУММЕСЛИ(диапазон из столбца «Исполнитель» из таблицы задач; ФИО тестировщика; диапазон процента загрузки за Дату).

В результате мы видим, в какие даты/периоды команды перегружены/недозагружены. Плюс, аналогичный анализ в разрезе каждого тестровщика.

Затем с листов «Планирование» и «Ресурсы» данные тянутся на лист «Капасити».

Емкость (Капасити)

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

В таблицах используются следующие поля: Функц.направление (ЦК разработки) /Ресурсный пул, Месяц, Количество рабочих дней, Чистое капасити (ч/д), Проектное капасити (ч/д), Объём плановых трудозатрат (ч/д), Фактическое капасити, «Объём план.трудозатрат проходит по капасити тестирования?».

В полях Функц. направление/Ресурсный пул заполняется наименование Функционального направления/Ресурсного пула.

В поле Месяц заполняется дата = первое число месяца, за который идёт расчёт капасити. Например, 01/12/2021.

В поле Количество рабочих дней идёт расчёт по следующему алгоритму:

• если дата из поля Месяц < Сегодня (т .е. текущий месяц), то берётся количество раб. дней, оставшихся до конца текущего месяца, с учётом праздничных дней, заполненных в отдельном диапазоне;

• если дата из поля Месяц > или = Сегодня, то берётся количество раб. дней за весь рассчитываемый месяц, с учётом праздничных дней, заполненных в отдельном диапазоне.

Формула:
=ЕСЛИ(Месяц<СЕГОДНЯ();ЧИСТРАБДНИ(СЕГОДНЯ();КОНМЕСЯЦА(Месяц;0); Список выходных дней);ЧИСТРАБДНИ(Месяц;КОНМЕСЯЦА(Месяц;0); Список выходных дней))

В поле Чистое капасити идёт расчёт по следующей формуле:
= «Количество рабочих дней» * «Капаситет пула/функц.направления, доступный к планированию» (тянется с листа «Ресурсы»).

В поле Проектное капасити рассчитываем 80% от Чистого капасити, т. е. с поправкой на различные риски: внеплановые трудозатраты + больничные/отгулы/отпуска. В итоге получаем, сколько ресурсов мы имеем в распоряжении на рассчитываемый месяц по данному функц. направлению/ресурсному пулу с учётом рисков. А они, черт возьми, случаются.

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

Формула: 
=СУММПРОИЗВ(--(МЕСЯЦ(Планирование!Весь диапазон дат)=МЕСЯЦ(Месяц));Планирование!Диапазон суммарных трудозатрат)

Таким образом, в итоге мы узнаем, какой объём плановых трудозатрат получаем на рассчитываемый месяц по данному направлению/ресурсному пулу.

В поле Фактическое капасити идёт расчёт по формуле:
Проектное капасити минус Объём план.трудозатрат. Т. е. разность между имеющимися ресурсами и запланированным объёмом трудозатрат.

В поле «Объём план. трудозатрат проходит по капасити тестирования?» мы получаем итоговый ответ. Используется формула: =ЕСЛИ(Фактическое капасити>=0;"Да";"Нет").

Если Проектное капасити полностью покрывает Объём план. трудозатрат, то «всё хорошо», текущий план на рассчитываемый месяц подтверждаем. Если в поле Фактическое капасити получаем отрицательное число, т. е. объем планируемых трудозатрат превышает количество доступных ресурсов, то «всё плохо», идем «перетряхивать» текущий план на рассчитываемый месяц и перепланировать часть задач на более поздние сроки с учетом приоритетов.

Также идет проверка на недозагрузку функц. направления/ресурсного пула: если значение, полученное в поле Фактическое капасити, больше определённого значения (например, >5), то оно подсвечивается – «обрати внимание!» (подсветка реализована через Условное форматирование). В таком случае можно либо догрузить направление задачами, либо перераспределить ресурсы на этот месяц на другое направление, более загруженное.

Чего мы добились

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

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

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

Что дальше

Изначально мы рассматривали разработку планировщика-калькулятора как MVP, то есть некий костыль с быстрой функциональностью для локального решения назревшей проблемы. Но после цикла разработки и доведения до ума бизнес-логики наш Excel-планировщик прижился и активно используется менеджментом. Другими словами, мы на собственном примере увидели, что базовая функциональность может быть реализована на чём угодно, а потом — вместе с заслуженной любовью пользователей — её уже можно переносить на продуманную архитектуру.

Сейчас главная проблема нашего MVP — невозможность обратного «затягивания» изменений из Excel в Jira. То есть запланированные данные (сроки, тестировщика) нужно вручную внести в Jira, что не очень приемлемо в век активной цифровизации. Мы запланировали несколько спринтов для разработки автоматизированного планирования команды с обязательной двусторонней синхронизацией с Jira. Начинаем планировать тестирование.