Rabbit vs. Turtle

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

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

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

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

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

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

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

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

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

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

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