SCRUM — фреймворк управления проектами, в который наша команда попробовала внедрить этап тестирования. В этой статье мы хотим помочь не совершить наших ошибок тем командам, которые только начинают знакомиться со SCRUM. Участники же опытных SCRUM-команд приглашаются в комментарии, чтобы поделиться замечаниями и успехами. А в качестве иллюстраций — беговые дорожки, марафонцы, препятствия. Они тут неспроста. Да и Олимпиада же, в конце концов.
Начнём с перечисления ключевых особенностей SCRUM для тех, кто с ним не знаком:
- итеративно-инкрементальная разработка. Слово «итеративная» означает, что разработка разбивается на равные по длительности промежутки времени — спринты. Один спринт занимает от одной до четырёх недель. Слово «инкрементальная» подразумевает, что в результате итерации получается новый, потенциально рабочий продукт, решающий бизнес-проблему. Такой продукт называется инкрементом продукта;
- самоорганизующаяся команда, в которой нет проектного менеджера (в дальнейшем — ПМ);
- в команде присутствует SCRUM-master (в дальнейшем — СМ);
- в команде есть человек со стороны заказчиков — product owner, или владелец продукта (в дальнейшем — ВП);
- весь период разработки разбит на промежутки времени — спринты. Длина спринта устанавливается в начале проекта и меняется только в том случае, если всплывают неучтённые детали, мешающие уложиться в заданные рамки;
- задачи (функциональные требования, баги, правки заказчика и т.п.) формируют пул работ — бэклог. Изначально в него входят только требования заказчика;
- в начале спринта (и в любом его месте, если это нужно) проводится Backlog Grooming — обработка задач из бэклога. В результате получается проработанный бэклог на 2-3 будущих спринта. Затем ВП и SCRUM-команда формулирует цель спринта и ожидаемый результат, и команда составляет бэклог спринта;
- после планирования спринта его состав стараются не менять. Если добавление новых задач всё же происходит, то из спринта исключаются старые и сопоставимые по ценности задачи. Если эти изменения привели к смене цели спринта, то спринт отменяется и планируется заново;
- ежедневные короткие SCRUM-митинги. Они дают понять, как движется процесс, а команда в курсе того, идут ли они к цели спринта или нет;
- в конце спринта выполненные задачи либо подтверждаются, либо отклоняются и возвращаются в бэклог;
- по результатам спринта команда получает инкремент продукта.
Использование компанией Лайв Тайпинг SCRUM-методологии в некоторых продуктах впоследствии дало свои положительные плоды: команда достигала дисциплины без надзора со стороны менеджера; задачи оценивались точнее, потому что их оценка происходила не в начале проекта, а по ходу, когда было уже известно о некоторых подводных камнях; со стороны заказчика поступал быстрый и качественный фидбек. Но вместе с его успешным внедрением встал вопрос о том, как в рамки этой методологии встроить уже имевшийся процесс тестирования. Рефлексии отдела тестирования нашей компании легли в основу всего, что написано ниже.
На старт, внимание…
Проблемы
Приоритетный вектор компании — разработка мобильных приложений. Это часто создаёт специфические рабочие условия: сроки бывают сжатыми, нормальной документации (как это бывает в случае со стартапами) нет, а требования заказчика меняются часто и резко. Из-за этого в организации тестирования возникает ряд сложностей, основная из которых — время. Если сравнивать большой энтерпрайз-проект и мобильный стартап, то в первом случае к проекту предъявляется море требований, но работать проще — зачастую есть и утверждённая документация, и сроки не такие сжатые. В мобильной разработке проекты не всегда настолько же масштабны, но из-за специфики тестирования мобильных платформ, особых требований к приложениям и частого отсутствия технической документации фронт работ получается сопоставимым, а времени на тестирование выделяется меньше.
Отсюда вытекают следующие проблемы тестирования мобильных приложений:
- ТЗ не составляют из-за его быстрого устаревания. Следовательно, невозможно сразу составить и актуальный набор тест-кейсов.
Изменения в требованиях происходят «на лету», поэтому смысла составлять ТЗ нет — больше времени уйдёт на его актуализацию, чем на разработку продукта. Также бывают проблемы в общении и информированности внутри команды: разработчик уточнил деталь у заказчика, но с остальными не поделился, или тестировщика не было на митинге, где принимались важные решения, не задокументированные из-за нехватки времени. И тому подобное. Как итог, у команды нет чёткого понимания проекта. Отсюда вытекает следующая проблема:
- Трудный вход в проект, когда часть функций уже реализована.
Часто работа над продуктом организован так, что сборка отдаётся на тестирование тогда, когда готова львиная доля функций. Если тестировщик не следил за развитием продукта, то перед началом тестирования он должен потратить много времени на вникание в его работу.
- Если приложение взаимодействует с другими приложениями или сервисами, сложность его тестирования повышается.
Когда ваше приложение, к примеру, предоставляет интеграцию с календарём, использует самостоятельно разработанные чаты, получает данные из соцсетей и делится информацией через них же или взаимодействует с облачными сервисами вроде Google Drive, сложность тестирования возрастает по экспоненте из-за различных вариантов взаимодействий.
Опыт внедрения
Основной проблемой реализации тестирования в SCRUM была сложившаяся на тот момент практика тестирования. Она предполагала продолжительные этапы разработки, затем передачу сборки на тесты, приём баг-репортов, правки, опять тестирование, снова правки, и так до тех пор, пока заявленные на этом этапе функции не начинали работать правильно. Смысл же SCRUM — в относительно коротких спринтах, по окончанию которых у вас есть некоторый оформленный и рабочий инкремент продукта. В итоге у нас сложилось две схемы.
Схема 1. Назовем её «Однократное тестирование + проверка фиксов».
Ключевые моменты:
- ежедневные встречи с заказчиком, который знает о багах;
- в начале спринта каждый разработчик в команде набирает себе пул задач из бэклога, в том числе и баги;
- тестировщик обычно включался где-то к середине спринта. Это происходило из-за того, что мы неверно понимали SCRUM, и как следствие, по ходу всего спринта не всегда была задействована команда целиком;
- найденные баги отправляются в бэклог;
- после начала спринта задачи в бэклог уже не добавляются;
- итоговая приёмка заказчиком проводится по итогам этапа, а не спринта;
- В команде был ПМ и не было ВП и СМ.
Получалось, что найденные в текущем спринте баги исправлялись только в следующем. Но так как заказчик был в курсе статуса проекта, и итоговая приёмка проводилась только в конце этапа, в спринт закладывается больше времени на тесты и фиксы, и всё вроде бы нормально.
Плюсы данного подхода:
- в спринт не добавляются новые задачи;
- клиент понимает, из-за чего возникают подвижки сроков завершения этапов;
- последние спринты этапа преимущественно посвящены фиксам и тестированию.
Такой подход был очень похож на сложившийся в компании до перехода на SCRUM, что и позволило ознакомиться с методологией относительно безболезненно. Также к концу этапа сдавались полностью оттестированные функции, что освобождало от мук совести.
Минусы данного подхода:
- Получился ScrumBut — неполноценный SCRUM, особенно в плане общения в команде. Процессами сильно рулил ПМ, в команде не было ВП, и члены команды (в том числе тестировщик), работали так, как привыкли с менеджером в команде.
- Баги правились только на следующем спринте, а иногда и позже.
Порой заказчик сам любил тестировать продукт, а у команды не было жёсткого списка тех задач, которые должны быть выполнены в данный спринт, кроме списка задач на этап. Это оборачивалось следующим:
- разработчики набирают себе некоторое число задач;
- выполненные задачи передаются на тестирование;
- тестировщик находит баги;
- разработчики фиксят часть багов и берут новые задачи, так как оставшиеся баги имеют меньший приоритет, а впереди всё равно будет этап фиксов и итогового тестирования;
- заказчик видит, что некоторые функции частично уже готовы, начинает тестировать, находит баги и расстраивается.
Не ходите нашим тернистым путём — сразу возьмите за правило жёстко определять задачи на спринт и устранять критические баги в текущем спринте.
Итог работы по схеме: получился качественный продукт, но производственный процесс нельзя было полностью назвать SCRUM’ом. Заказчик был часто недоволен тем, что сам находил баги, хотя итоговый результат его вполне устроил.
Дышим ровно, бежим дальше.
Схема 2. Её назовём «Потоковое тестирование».
Ключевые моменты:
- ежедневные встречи с ВП, который следит за статусом проекта;
- тестировщику каждый день поступают сборки с частично готовыми функциями;
- найденные баги отправляются в бэклог;
- в начале спринта команда набирает себе пул задач из бэклога спринта;
- после начала спринта задачи в него не добавляются, но блокирующие баги чинятся и проверяются в этом же спринте, причём их приоритет повышен;
- заказчик принимает сборку по итогам спринта, и есть жёсткий список задач (Sprint Backlog), которые в этом спринте обязательно нужно выполнить;
- ПМ в данной схеме становится SCRUM-мастером и в основном налаживает связь между разработчиками и ВП или частями команды, защищает команду от излишнего давления ВП, предлагает изменения процесса работы и т.п., то есть играет в процессе роль фасилитатора;
- сборка попадает к ВП только через тестировщика;
- по окончанию спринта проводится ретроспектива и готовится демо для тестовой группы заказчика (Stakeholders).
Эта схема уже больше похожа на реальный SCRUM, хоть и имеет место добор задач в спринт, чья длительность несколько раз менялась.
Плюсы данного подхода:
- ежедневное тестирование новых функций. Количество и сложность работы наращиваются более плавно;
- ежедневные короткие SCRUM-митинги. Это позволяет её членам лучше понимать контекст продукта, что особенно полезно при распределенной по городам команде;
- максимально быстрое исправление блокирующих багов;
- сдача функций рабочими частями, которые приближают достижение цели спринта.
При соблюдении всех этих условий продуктивность работы растёт: каждый день примерно в одно время тестировщик получает сборки и даёт отчёт, чтобы команда при необходимости поправила критические вещи. Это позволяет ему лучше спланировать рабочее время и быть уверенным, что его не выдернут на другой проект.
Минусы данного подхода:
- далеко не всегда сборки приходят ежедневно, что приводит к резкому авралу в конце спринта;
- добор задач после начала спринта может привести к задержкам. Это происходит в том случае, если в начале спринта разработчик взял хороший темп, сделал много задач и решил добрать новые, не закончив все текущие. В таком случае обязательно вылезет проблема, которая не позволит завершить все работы в срок.
Характерная черта данной схемы ещё и в том, что если обнаруживается баг, связанный с какой-либо задачей, но баг этот не критический и не блокирующий, то задача всё равно помечается как выполненная. Однако же в комментариях баг снабжается описанием (либо на него даётся ссылка в баг-трекере), а ВП просматривает его и окончательно решает, принять или отклонить эту задачу. Плюс фоном есть чувство неловкости от того, что ты отдаешь заказчику сборку с багами.
Итог работы по схеме: значительно лучше первой схемы, но не без недостатков. Чтобы сгладить их, мы выделили для себя некоторые дополнительные правила.
Cейчас у вас откроется второе дыхание — мы выходим на финишную прямую.
Работа над ошибками
Эти приёмы в ведении проектов по SCRUM-методологии мы вывели для себя в процессе работы и продолжаем их оттачивать. Надеемся, что они будут полезны и вам:
- брать на спринт фиксированное число задач.
Единственные задачи, которые можно и нужно добавлять — это починка блокирующих багов. Также позволительно добавлять задачи поверх изначальных, но только при условии, что изначальные задачи выполнены, оттестированы, и всё работает как надо.
- Разбивать большие задачи на более мелкие и выдавать сборки для тестов как можно регулярнее. Так можно избежать простоя тестировщика в начале спринта и аврала в конце.
- Делать по ходу спринта несколько версий сборок. Например, три.
Каждая из сборок должна являться инкрементом продукта. Если после добавления очередной фичи всё поломается, и решение проблемы окажется долгим и сложным, можно отправить ВП одну из предыдущих сборок — уж одна-то из них окажется рабочей.
- Для мобильной разработки: определить список устройств, гарантирующих хорошую работу продукта.
Если вы успешно протестируете сборку на Nexus 5, Galaxy S7 и Xperia Z3, то заказчик может взять свой LG G3, на котором всё окажется плохо. Рынок мобильных устройств (особенно Android) разнообразен, и сложно подстроиться под весь, поэтому надо задать границы.
- НИКОГДА не ставьте крайний срок сдачи сборки на пятницу, субботу или воскресенье.
Баги могут вылезти в последний момент, и вы обрекаете себя работать в выходные и таскать за собой кучу тестовых устройств, куда бы вы ни пошли. Это сильно скажется на качестве тестирования. Конец спринта лучше всего устанавливать во вторник-среду, тогда последние приготовления к сдаче будут проходить в штатном режиме.
- Настроить баг-трекер так, чтобы созданные баги проходили через тестировщика.
- Так баг-репорты станут унифицированными, что облегчает понимание, а сам тестировщик в курсе того, как обстоят дела с ошибками на проекте.
- Критические решения должны приниматься коллегиально.
- Если кому-то нужно обсудить то или иное серьёзное изменение с ВП, желательно участие всей команды. Во-первых, это даёт взгляд со стороны, во-вторых, изменение может повлиять на рабочий процесс других членов команды, и в-третьих, так команда глубже понимает проект.
- Ограничить число задач в работе, готовых к тестированию и проверке.
Также внутри своей команды мы ввели небольшой элемент канбана. Возможны ситуации, когда список задач для теста растёт, а разработчики не отдают сборку тестировщику, потому что хотят сделать и отдать на тест побольше задач за раз; или когда к проверке готово много задач, а тестировщик не отдаёт сборку ВП, потому что хочет отдать максимально большую часть протестированного продукта. В итоге страдают все: у тестировщика аврал — времени до конца спринта мало, а задач на тест много; у разработчиков аврал — времени до конца спринта мало, а тестировщик прикатил вагон багов; у ВП аврал — времени до конца спринта мало, а команда всё чинит да тестирует, чинит да тестирует. Чтобы этого избежать, у каждого члена команды не может одновременно находиться в работе, например, более двух задач, а общее число задач в тесте и готовых для проверки не может превышать (тоже например) шести в каждом случае, если в команде три разработчика.
Решаемые проблемы
В первую очередь SCRUM сглаживает проблему отсутствующей документации и налаживает общение в команде: задачи ставятся постепенно и формулируются понятно, постоянно поддерживается связь с представителем заказчика, и разобраться в проекте гораздо легче. Параллельно с этим можно составлять тестовую документацию.
Тестирование начинается чуть позже разработки, что позволяет быть в контексте проекта с самого его начала и значительно упрощает работу. Все стремительно меняющиеся пожелания заказчиков оперативно обсуждаются с командой и принимаются (или не принимаются) коллегиально, так как ВП находится в тесном контакте с командой и со временем понимает, что реально сделать, а что нет.
Вывод
Следование этим приёмам хоть и не гарантирует успешного завершения проекта, но как минимум поможет в этом. Надеемся, что они окажутся полезными. Если у вас есть свои примеры внедрения SCRUM, то мы будем рады увидеть их в комментариях.
Автор: Лайв Тайпинг
