Rabbit vs. Turtle

Основное направление деятельности Mygento - разработка и развитие eCommerce проектов. Как правило весь рабочий процесс сопряжен с рядом условий: сжатые сроки и отсутствие приличной документации, что вкупе с резко меняющимися требованиями заказчика создает гремучую смесь из срывов со сдачей релизов, неверной оценкой трудозатрат и внушительного баг-лога.

В связи с этим мы сделали попытку перейти на SCRUM в разработке и в целом добились не плохих результатов: проектная команда достигла дисциплины без детального надзора со стороны менеджера; задачи стали оцениваться более точно, потому что их оценка происходила не в начале проекта, а с учетом особенностей; со стороны заказчика стал поступать быстрый и качественный фидбек, скорость разработки сократилась в разы. Воодушевившись результатами наших нововведений мы взялись за этап тестирования, с целью наладить процесс и добиться похожих результатов.

Ключевые особенностей SCRUM, которые стали отправной точкой для улучшения нашего процесса тестирования релизов:

  • Процесс разбивается на равные по длительности промежутки времени — спринты. Один спринт занимает от одной до четырёх недель, а его длина устанавливается в начале проекта и практически не меняется до выхода релиза;
  • самоорганизующаяся команда, в которой нет проектного менеджера;
  • в команде есть человек со стороны заказчиков — product owner;
  • задачи (функциональные требования, баги, правки заказчика и т.п.) формируют пул работ — бэклог. Изначально в него входят только требования заказчика;
  • в начале спринта (и в любом его месте, если это нужно) проводится Backlog Grooming — обработка задач из бэклога. В результате получается проработанный бэклог на 2-3 будущих спринта (с учетом приоритетов задач). Затем команда формулирует цель спринта и ожидаемый результат, и команда составляет бэклог спринта;
  • после планирования спринта его состав не меняется. Если добавление новых задач всё же происходит, то из спринта исключаются старые и сопоставимые по ценности задачи. Если эти изменения привели к смене цели спринта, то спринт отменяется и планируется заново;
  • ежедневные короткие митинги. Они дают понять, как движется процесс, а команда в курсе того, идут ли они к цели спринта или нет;
  • в конце спринта выполненные задачи либо подтверждаются, либо отклоняются и возвращаются в бэклог;
  • по результатам спринта команда получает инкремент продукта - потенциально рабочий релиз, решающий бизнес-проблему.

Для чего мы решили перейти на SCRUM в тестировке?

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

Из-за особенностей направления разработки интернет-магазинов в организации тестирования возникает ряд сложностей, основная из которых — время. Если речь идет о большом eCommerce-проекте, то как правило к нему предъявляют огромное количество требований и по этой причине есть утвержденные этапы и детальная документация. Сроки как правило сжатые, но в рамках roadmap, утвержденной на ранних этапах и не подвергающийся корректировке. В случае небольших проектов (как правило это касается стартапов в ecommerce) все совершенно наоборот: времени нет, документации тоже, а количество участников со стороны клиента и количество ежедневных задач зашкаливает.

Отсюда вытекают следующие проблемы тестирования:

  • ТЗ не составляют из-за его быстрого устаревания. Следовательно, невозможно сразу составить и актуальный набор тест-кейсов. Изменения в заданиях происходят «на лету», поэтому смысла составлять ТЗ нет — больше времени уйдёт на его актуализацию, чем на разработку продукта. Также бывают проблемы в общении и информированности внутри команды: разработчик уточнил деталь у заказчика, но с остальными не поделился, или тестировщика не было на митинге, где принимались важные решения, не задокументированные из-за нехватки времени. И тому подобное. Как итог, у команды нет чёткого понимания проекта. Отсюда вытекает следующая проблема:
  • трудный вход в проект, когда часть функций уже реализована.Часто работа над продуктом организован так, что релиз проекта отдаётся на тестирование тогда, когда готова львиная доля функционала. Если тестировщик не следил за развитием процесса, то перед началом тестирования он должен потратить много времени на вникание в его работу.
  • как правило любой eCommerce проект взаимодействует с другими сервисами, отсюда сложность тестирования повышается.Когда интернет-магазин, к примеру, интегрирован с 1с или ERP/SAP сложность тестирования возрастает по экспоненте из-за различных вариантов взаимодействий и количества передаваемое информации.

К чему мы пришли?

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

  • Ежедневные встречи с ВП, который следит за статусом проекта;
  • тестировщику каждый день поступают сборки с частично готовыми функциями;
  • найденные баги отправляются в бэклог;
  • в начале спринта команда набирает себе пул задач из бэклога спринта. Добор задач в течении спринта может приводить к авральным режимам и задержкам со сдачей;
  • после начала спринта задачи в него не добавляются, но блокирующие баги чинятся и проверяются в этом же спринте, причём их приоритет повышен. Задачи можно добавлять только при условии, что изначальные задачи выполнены, оттестированы, и всё работает как надо.;
  • заказчик принимает сборку по итогам спринта, и есть жёсткий список задач (Sprint Backlog), которые в этом спринте обязательно нужно выполнить;
  • менеджер проекта в основном налаживает связь между разработчиками и ВП или частями команды, защищает команду от излишнего давления ВП, предлагает изменения процесса работы и т.п., то есть играет в процессе роль фасилитатора;
  • сборка попадает к ВП только через тестировщика;
  • разбиваем большие задачи на более мелкие и выдаем функционал на тесты как можно чаще. Чтобы избежать авральных режимов, у каждого члена команды не может одновременно находиться в работе, например, более двух задач, а общее число задач в тесте и готовых для проверки не может превышать (тоже например) шести в каждом случае, если в команде три разработчика.
  • никогда не ставим срок сдачи клиенту на пятницу, субботу или воскресенье. Иначе это сильно сказывается на качестве тестирования. Конец спринта лучше всего устанавливать во вторник-среду, тогда последние приготовления к сдаче будут проходить в штатном режиме.
  • критические решения принимаем коллегиально.
  • если кому-то нужно обсудить то или иное серьёзное изменение с ВП, желательно участие всей команды. Во-первых, это даёт взгляд со стороны, во-вторых, изменение может повлиять на рабочий процесс других членов команды, и в-третьих, так команда глубже понимает проект

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

Таким образом мы смогли прогнозировать нагрузки и плавно наращивать количество и сложность работы.