Наш блок разработки планировал цикл «программирование — тестирование — внедрение» только исходя из доступности своих ресурсов. А проектов было много. Тестировщиков ставили перед фактом: мол, есть задача, проверить нужно вчера — погнали. В итоге задачи наслаивались, тестировщики фигачили без перерыва, роптали и сбегали в другие компании. Надо было это прекращать — и мы вышли из положения с помощью Excel. И вот как нам это удалось.
![](https://habrastorage.org/getpro/habr/upload_files/804/7fa/840/8047fa8402514a3df31914fe8afccf3f.png)
Мы решили написать приложение, позволяющее равномерно планировать нагрузку на тестировщиков и, если что, быстро её корректировать. Изучив разные инструменты планирования, поняли, что подойдёт обычный Excel. Это быстро и функционально. А проверив работоспособность идеи “в бою”, уже можно переложить ее в код.
Как вообще устроено тестирование в банках?
Если ты функциональный тестировщик в вакууме банке, то первое, с чем сталкиваешься — надо каждый день разбираться с логикой базовых бизнес-процессов. Если на уровне потребителя ты знаешь, что можешь открыть депозит в банке и получать проценты на свои кровные, то при работе тестировщиком погружаешься в кухню и понимаешь, где зашита логика расчёта этих самых процентов.
При составлении своего плана тестирования ты в первую очередь опираешься на базовую функциональность процесса и на неё наращиваешь кейсы по проверке новой фичи. Ну и как истинный тестировщик изобретаешь: как сломать систему так, чтобы ошибка заинтриговала разработчика и он дал тебе пятюню.
Как прошаренная IT-компания мы понимаем, что проводить проверки доработок на одном тестовом стенде и выпускать их в релиз — недостаточно. Поэтому разные этапы тестирования проводятся на отдельных тестовых стендах для выявления максимального количества уязвимостей, в том числе для проверки того, что новые фичи встраиваются в сложный интеграционный процесс.
И вишенка: перед выпуском в релиз мы проводим смоук-тест всех новых фич, то есть проверку работоспособности основных бизнес-цепочек и новых доработок. Параллельно с нашими коллегами проводится регресс базового функционала. Смоук и регресс проводятся на отдельном стенде регрессионного тестирования.
Итак, у тестирования много взаимозависимых этапов, планирование которых требует чёткости и прозрачности по каждому из направлений. Собственно, именно этот вопрос мы хотели решить с помощью удобного инструмента планирования ресурсов, которым оказался банальный Excel.
Ожидание vs реальность
Наш планировщик должен:
вычислять трудоёмкость задач, которые может переварить каждое отдельное функциональное направление за расчётный период;
оперативно определять распределение задач на каждого тестировщика для выявления его загрузки;
быстро балансировать загрузку в случае необходимости, исходя из специализации тестировщиков и приоритета задач.
Так как все задачи по реализации проектов у нас ведутся в Jira, нужно было, чтобы все изменения по планированию фиксировались там и оперативно выгружались в планировщик-калькулятор. Проанализировав готовые решения, мы пришли к выводу, что разработка автоматизированного инструмента планирования займёт время, и в ожидании реализации решили настроить выгрузку в Excel, а уже в нём настраивать всё как душе угодно.
В результате мы смогли получить:
быстрый расчёт загрузки по разнообразным формулам (в разрезе конкретного тестировщика, функционального направления, ресурсного пула, по всему блоку тестирования в целом и т. д.);
удобное графическое отображение информации (типа диаграммы Ганта), в том числе лёгкую и быструю фильтрацию нужных данных;
гибкость/лёгкость доработки/изменения инструмента при необходимости.
![](https://habrastorage.org/getpro/habr/upload_files/6d0/b82/f66/6d0b82f66cd6c3eac2fd90f9fb6b0439.png)
Как это работает
Общая концепция планировщика-калькулятора загрузки такова: сначала из Jira в Excel выгружается выборка данных, т. е. список задач по фильтру с необходимой структурой. Далее эта выгрузка вставляется в планировщик-калькулятор, и на основании выгрузки рассчитываются дополнительные параметры. К примеру, проверяется корректность заполнения процента загрузки, подсвечиваются просроченные даты, выделяются незаполненные поля и тому подобное. При внесении изменений в задачи Jira выгрузка первичных данных для планировщика занимает всего несколько минут. Частота выгрузки зависит от глубины планирования.
Ресурсы
На листе «Ресурсы» заполняются данные по доступным к планированию ресурсам, указывается принадлежность к функциональному направлению/команде, ресурсному пулу и т. д.
![](https://habrastorage.org/getpro/habr/upload_files/095/7a5/200/0957a520035ef1cf1a3a3fcdb5d13ba2.png)
На этом же листе в отдельной таблице рассчитывается параметр «Капаситет пула, доступный к планированию» в разрезе Ресурсных пулов. Для этого берутся строки тестировщиков, которые принадлежат к рассчитываемому пулу, и по ним считается сумма по столбцу «Доступный к планированию капаситет». Также в этой таблице считается общая емкость пула (количество тестировщиков, принадлежащих к ресурсному пулу с учётом и без учёта вакансий).
Так как планирование ведется на горизонте 2-3 месяца, то листов «Ресурсы» может быть несколько – по отдельному на каждый планируемый месяц. Тут же учитывается план/факт приёма новых сотрудников, увольнения, плановые отпуска, ротация между направлениями. В результате при планировании учитывается тот факт, что ёмкость групп от месяца к месяцу меняется. Это позволяет видеть картину в разрезе каждого месяца.
Затем данные с листа «Список задач» тянутся на лист «Планирование».
Планирование
![](https://habrastorage.org/getpro/habr/upload_files/2fa/e08/a6b/2fae08a6bfd5ba10d9007939c8966e8a.png)
Здесь визуализируются:
1. Данные о длительности и трудоёмкости задач графически (в виде диаграммы Ганта). В результате мы наглядно видим, в какие даты/периоды и с какой загрузкой запланированы задачи.
Логика заложена следующая: на пересечении столбцов даты и строк задач заполняется значение процента загрузки, если выполняются следующие условия:
дата попадает в период между датой начала и сроком исполнения задачи;
дата попадает на рабочий день (проводится проверка: Дата НЕ попадает на выходной день и НЕ попадает в Список выходных дней);
статус задачи не равен Отложено.
В случае, если условия не выполняются, в ячейке выставляется значение “0”.
2. Расчёт суммарной загрузки по всем задачам в разрезе функциональных направлений и ресурсных пулов.
Ниже на листе рассчитываются и заполняются 3 таблицы в виде той же диаграммы Ганта на основании «ленты» дат:
В первой таблице рассчитываются суммарные плановые трудозатраты в разрезе ресурсных пулов за каждую дату. В строках таблицы отображается наименование ресурсного пула и далее расчёт по формуле: =СУММЕСЛИ(диапазон из столбца «Ресурсный пул» из таблицы задач; Наименование ресурсного пула; диапазон процента загрузки за Дату).
Во второй таблице рассчитываются суммарные плановые трудозатраты в разрезе функц. направлений за каждую дату. В строках таблицы наименование функц. направления и далее расчёт по формуле: =СУММЕСЛИ(диапазон из столбца «Функц.направление» из таблицы задач; Наименование функц.направления; диапазон процента загрузки за Дату).
В третьей таблице рассчитываются суммарные плановые трудозатраты в разрезе тестировщиков за каждую дату. В строках таблицы ФИО тестировщика и далее расчёт по формуле: =СУММЕСЛИ(диапазон из столбца «Исполнитель» из таблицы задач; ФИО тестировщика; диапазон процента загрузки за Дату).
В результате мы видим, в какие даты/периоды команды перегружены/недозагружены. Плюс, аналогичный анализ в разрезе каждого тестровщика.
Затем с листов «Планирование» и «Ресурсы» данные тянутся на лист «Капасити».
Емкость (Капасити)
На нем расположены 2 таблицы, в которых рассчитываются итоговые данные по загрузке в разрезе месяцев по направлениям и по ресурсным пулам. Здесь мы получаем ответ на главный вопрос жизни, вселенной и всего такого, удастся ли в расчётном месяце переварить тот объем задач, который сами же и напланировали.
![](https://habrastorage.org/getpro/habr/upload_files/19d/942/a2b/19d942a2bedf4c4c5328db767143618c.jpg)
В таблицах используются следующие поля: Функц.направление (ЦК разработки) /Ресурсный пул, Месяц, Количество рабочих дней, Чистое капасити (ч/д), Проектное капасити (ч/д), Объём плановых трудозатрат (ч/д), Фактическое капасити, «Объём план.трудозатрат проходит по капасити тестирования?».
В полях Функц. направление/Ресурсный пул заполняется наименование Функционального направления/Ресурсного пула.
В поле Месяц заполняется дата = первое число месяца, за который идёт расчёт капасити. Например, 01/12/2021.
В поле Количество рабочих дней идёт расчёт по следующему алгоритму:
если дата из поля Месяц < Сегодня (т .е. текущий месяц), то берётся количество раб. дней, оставшихся до конца текущего месяца, с учётом праздничных дней, заполненных в отдельном диапазоне;
если дата из поля Месяц > или = Сегодня, то берётся количество раб. дней за весь рассчитываемый месяц, с учётом праздничных дней, заполненных в отдельном диапазоне.
Формула:
=ЕСЛИ(Месяц<СЕГОДНЯ();ЧИСТРАБДНИ(СЕГОДНЯ();КОНМЕСЯЦА(Месяц;0); Список выходных дней);ЧИСТРАБДНИ(Месяц;КОНМЕСЯЦА(Месяц;0); Список выходных дней))
В поле Чистое капасити идёт расчёт по следующей формуле:
= «Количество рабочих дней» * «Капаситет пула/функц.направления, доступный к планированию» (тянется с листа «Ресурсы»).
В поле Проектное капасити рассчитываем 80% от Чистого капасити, т. е. с поправкой на различные риски: внеплановые трудозатраты + больничные/отгулы/отпуска. В итоге получаем, сколько ресурсов мы имеем в распоряжении на рассчитываемый месяц по данному функц. направлению/ресурсному пулу с учётом рисков. А они, черт возьми, случаются.
В поле Объем плановых трудозатрат идёт расчёт по следующему алгоритму:
с листа «Планирование» по суммарным плановым трудозатратам берутся и суммируются данные только за нужный месяц (проводится проверка, входит ли дата в рассчитываемый месяц).
Формула:
=СУММПРОИЗВ(--(МЕСЯЦ(Планирование!Весь диапазон дат)=МЕСЯЦ(Месяц));Планирование!Диапазон суммарных трудозатрат)
Таким образом, в итоге мы узнаем, какой объём плановых трудозатрат получаем на рассчитываемый месяц по данному направлению/ресурсному пулу.
В поле Фактическое капасити идёт расчёт по формуле:
Проектное капасити минус Объём план.трудозатрат. Т. е. разность между имеющимися ресурсами и запланированным объёмом трудозатрат.
В поле «Объём план. трудозатрат проходит по капасити тестирования?» мы получаем итоговый ответ. Используется формула: =ЕСЛИ(Фактическое капасити>=0;"Да";"Нет").
Если Проектное капасити полностью покрывает Объём план. трудозатрат, то «всё хорошо», текущий план на рассчитываемый месяц подтверждаем. Если в поле Фактическое капасити получаем отрицательное число, т. е. объем планируемых трудозатрат превышает количество доступных ресурсов, то «всё плохо», идем «перетряхивать» текущий план на рассчитываемый месяц и перепланировать часть задач на более поздние сроки с учетом приоритетов.
Также идет проверка на недозагрузку функц. направления/ресурсного пула: если значение, полученное в поле Фактическое капасити, больше определённого значения (например, >5), то оно подсвечивается – «обрати внимание!» (подсветка реализована через Условное форматирование). В таком случае можно либо догрузить направление задачами, либо перераспределить ресурсы на этот месяц на другое направление, более загруженное.
Чего мы добились
Мы ведём планирование раз в неделю: проводим встречу с разработчиками и планируем загрузку тестировщиков по всем накопленным за неделю новым/перепланируемым задачам. Наш экселевский планировщик-калькулятор позволяет наглядно оценить, успеваем ли мы с тестом конкретных фич или их релиз стоит перенести на более поздний срок.
Более того, сейчас сразу видно, если какое-то функциональное направление или ресурсный пул перегружены или, наоборот, недозагружены. Плюс мы видим изменения загрузки в разрезе разных периодов. В таком случае мы перераспределяем тестировщиков с соответствующими навыками между функциональными направлениями на нужный период и выравниваем загрузку.
Также наш планировщик-калькулятор наглядно показывает направления, требующие ресурсного усиления, и мы запрашиваем дополнительные вакансии.
Что дальше
Изначально мы рассматривали разработку планировщика-калькулятора как MVP, то есть некий костыль с быстрой функциональностью для локального решения назревшей проблемы. Но после цикла разработки и доведения до ума бизнес-логики наш Excel-планировщик прижился и активно используется менеджментом. Другими словами, мы на собственном примере увидели, что базовая функциональность может быть реализована на чём угодно, а потом — вместе с заслуженной любовью пользователей — её уже можно переносить на продуманную архитектуру.
Сейчас главная проблема нашего MVP — невозможность обратного «затягивания» изменений из Excel в Jira. То есть запланированные данные (сроки, тестировщика) нужно вручную внести в Jira, что не очень приемлемо в век активной цифровизации. Мы запланировали несколько спринтов для разработки автоматизированного планирования команды с обязательной двусторонней синхронизацией с Jira. Начинаем планировать тестирование.