Процесс тестирования
Agile, Scrum и Kanban для тестировщика: роли, события, артефакты
Agile – подход к разработке, записанный в манифесте 2001 года: четыре ценности и двенадцать принципов, по которым продукт делают короткими итерациями и меняют по ходу работы. Scrum считается одним из самых популярных фреймворков Agile, в нём работа идёт спринтами не длиннее месяца, есть три зоны ответственности (владелец продукта, Scrum-мастер и разработчики, к которым относится и тестировщик), пять событий и три артефакта. В Kanban нет спринтов и обязательных ролей, задачи непрерывным потоком двигаются по доске, а число задач в работе ограничено.
- 4 ценности
- и 12 принципов в манифесте Agile 2001 года
- Тестировщик
- в Scrum входит в число разработчиков (Developers)
- Бесплатно
- урок с заданиями в моём базовом курсе
Что такое Agile и манифест гибкой разработки
Agile – это набор ценностей и принципов гибкой разработки. В 2001 году семнадцать разработчиков собрались на горнолыжном курорте Сноуберд в штате Юта и записали, что объединяет их способы работы. Так появился манифест Agile: четыре ценности и двенадцать принципов, которые эти ценности уточняют. Scrum и Kanban относят к гибким подходам, потому что они воплощают ценности манифеста в конкретных правилах.
В водопадной модели этапы идут друг за другом: идея, требования, разработка, тестирование, и вернуться на пройденный этап без перезапуска нельзя. Гибкие методы разрешают менять требования и возвращаться к сделанному. Продукт собирают короткими итерациями, и каждая заканчивается работающей частью, которую можно показать заказчику.
Каждая ценность сравнивает две вещи, и правая половина при этом не отменяется: процессы, документация и контракты на проекте остаются, просто при выборе левая половина весит больше.
Люди и взаимодействие важнее процессов и инструментов
Если какой-то процесс или инструмент мешает команде работать, от него избавляются. Способ работы выбирают сами люди, и процессы должны им помогать.
Работающий продукт важнее исчерпывающей документации
Документация на проекте есть, но избыточной её не делают и много времени на неё не тратят. Задача номер один – доставить заказчику работающую функциональность.
Сотрудничество с заказчиком важнее согласования условий контракта
Договоры и соглашения с заказчиком существуют ради нормальной совместной работы, и цепляться за пункт договора в ущерб отношениям незачем.
Готовность к изменениям важнее следования первоначальному плану
Даже чётко прописанное требование со временем меняется. У бизнеса появляются новые потребности, и функцию, сделанную в прошлой итерации, приходится расширять. Ради таких изменений гибкие методы и придуманы.
Scrum-команда и место тестировщика в ней
Scrum – это фреймворк, то есть набор правил для управления проектом. Слово здесь не про библиотеки для программирования: Scrum описывает, как команда планирует работу, сверяет ход и подводит итоги. Правила записаны в руководстве Scrum Guide Кена Швабера и Джеффа Сазерленда, и действующая версия вышла в ноябре 2020 года.
Scrum-команда по руководству 2020 года – это владелец продукта, Scrum-мастер и разработчики, обычно не больше 10 человек. Руководство называет их зонами ответственности (accountabilities), хотя на работе по-прежнему говорят "роли". Подкоманд и иерархии внутри нет. Команда кроссфункциональна, то есть вместе умеет всё, что нужно для результата, и сама решает, кто, что и как делает.
Отдельной роли тестировщика в Scrum нет. Тестировщик входит в число разработчиков, так руководство называет всех, кто делает инкремент, будь то код, проверки или требования. Отсюда коллективная ответственность за качество, о которой я говорю в уроке. Если баг дошёл до пользователя, отвечает вся команда: разработчик допустил ошибку, тестировщик её не поймал, а найти все дефекты невозможно в принципе. В идеале каждый может подменить коллегу, например на время болезни, но на практике большую часть проверок всё равно делает тестировщик.
Мой урок записан за несколько дней до выхода руководства 2020 года, поэтому в нём звучат формулировки версии 2017 года: команда разработки (Development Team) из 3–9 человек и три обязательных вопроса на ежедневном скраме. На этой странице устройство Scrum описано по версии 2020 года.
Владелец продукта (Product Owner)
Отвечает за ценность продукта и ведёт бэклог продукта. Он формулирует цель продукта, описывает элементы бэклога, расставляет их по порядку и следит, чтобы команде было понятно, что там лежит. Это всегда один человек, даже если пожелания приходят от многих. Отдельного бизнес-аналитика в Scrum нет, и часть его работы делает владелец продукта, хотя во многих компаниях аналитик в команде всё же есть.
Scrum-мастер (Scrum Master)
Отвечает за то, чтобы Scrum работал так, как он описан в руководстве, и за эффективность команды. Он знает правила, учит им, помогает убирать препятствия и следит, чтобы события проходили и укладывались во время, но сам инкремент не делает. Новичку в компании обычно именно Scrum-мастер объясняет, как здесь устроен процесс.
Разработчики (Developers)
Все, кто делает инкремент: программисты, тестировщики, аналитики, дизайнеры. Они составляют план спринта, держат качество по критериям готовности и каждый день сверяют, как работа движется к цели спринта.
События Scrum: спринт, планирование, дейли, обзор и ретроспектива
Спринт – это отрезок фиксированной длины не больше месяца, на практике обычно 2–4 недели. Он вмещает остальные четыре события, и следующий спринт начинается сразу после предыдущего. За спринт команда делает инкремент, готовую к использованию часть продукта.
По ходу спринта не вносят изменений, которые ставят под угрозу его цель, и не снижают качество. Состав работы можно уточнять с владельцем продукта по мере того, как команда узнаёт новое. Длительность ниже указана по руководству для месячного спринта, у коротких спринтов события обычно короче.
Планирование спринта (Sprint Planning)
Вся команда собирается в начале спринта и отвечает на три вопроса: зачем нужен этот спринт, что из бэклога продукта можно сделать и как это сделать. Из бэклога продукта получается бэклог спринта, а у спринта появляется цель. Занимает до 8 часов.
Ежедневный Scrum (Daily Scrum, дейли, стендап)
Пятнадцатиминутная встреча разработчиков каждый день, на которой сверяют движение к цели спринта и поправляют план. Раньше руководство предлагало три вопроса, и многие команды отвечают на них до сих пор: что сделал вчера, что буду делать сегодня, что мешает. Мой пример: "Вчера описал тест-кейсы для одной пользовательской истории, сегодня пишу для следующей. Неясно, как разработчики будут её реализовывать, поэтому свяжусь с тем, на кого она назначена". Если препятствие не снимается само, команда подсказывает, чем помочь.
Обзор спринта (Sprint Review)
Команда показывает результат заинтересованным лицам, вместе с ними смотрит, достигнута ли цель и закрыты ли пользовательские истории, и решает, что делать дальше. Руководство просит не сводить обзор к презентации. Во многих компаниях демонстрацию (демо) владельцу продукта или заказчику проводят отдельно, после обзора или сразу, как готова очередная история. Занимает до 4 часов.
Ретроспектива спринта (Sprint Retrospective)
Завершает спринт. Обзор смотрит на продукт, ретроспектива – на то, как работала команда. В моих командах расчерчивают доску: что шло хорошо, какие были проблемы, как их решить. Из проблем выбирают главные, придумывают по ним action items с ответственными и переносят в следующий спринт, а на следующей ретроспективе проверяют, помогло ли. Занимает до 3 часов.
Артефакты Scrum и критерии готовности
В руководстве 2020 года у каждого артефакта есть обязательство (commitment), по которому видно, движется ли работа к цели. Бэклог продукта постоянно пополняется новыми функциями, пользовательскими историями и требованиями. Уточнение бэклога (refinement) руководство относит к постоянной работе, и отдельного события для него нет. Владелец продукта приносит новые истории, команда задаёт вопросы, истории переписывают, пока они не станут понятны, а разработчики оценивают их размер. Тестировщик смотрит на историю как на требование: полна ли она, однозначна ли и можно ли её проверить.
Пример с уточнения бэклога интернет-магазина. История "Как покупатель, я хочу оплатить заказ сохранённой картой, чтобы не вводить данные заново" пришла без критериев приёмки, и тестировщик спрашивает, что увидит покупатель, если срок карты истёк, можно ли удалить сохранённую карту и сколько карт можно хранить. Ответы записывают в историю критериями приёмки, и по ним потом пишут тест-кейсы. Без этого разработчик и тестировщик поняли бы историю по-разному, и спор о том, баг это или нет, начался бы в конце спринта.
Инкремент – это всё, что сделано за спринт, вместе со всем, что было сделано раньше. По руководству каждый новый инкремент добавляется к прежним и проверен так, чтобы всё работало вместе, а за спринт их может получиться несколько. Работа, которая не прошла критерии готовности, в инкремент не входит и возвращается в бэклог продукта.
Критерии готовности (Definition of Done) описывают, когда работа считается законченной. Пример из урока: написаны модульные и интеграционные тесты и все проходят, а критических багов меньше оговорённой доли. Критериев подготовленности (Definition of Ready) в руководстве нет, их вводят сами команды. Они относятся к бэклогу и отвечают на вопрос, можно ли брать историю в спринт: понятна ли она и отвечает ли свойствам хороших требований.
Бэклог продукта (Product Backlog) и цель продукта
Упорядоченный список всего, что нужно сделать в продукте. Ведёт его владелец продукта, и порядок элементов задаёт тоже он.
Бэклог спринта (Sprint Backlog) и цель спринта
Цель спринта, элементы, выбранные под неё на планировании, и план, как их сделать. Его ведут разработчики и обновляют по ходу спринта.
Инкремент (Increment) и критерии готовности
Готовая к использованию часть продукта вместе со всем, что сделано раньше. Частью инкремента работа становится только после того, как выполнены критерии готовности.
Пользовательские истории, стори-поинты и метрики команды
Пользовательская история (user story) коротко формулирует, что система должна сделать для пользователя: "Как <роль>, я хочу <действие>, чтобы <ценность>". Пример из урока: "Как новый пользователь, я хочу купить телефон, чтобы порадовать себя". Под формулировкой пишут критерии приёмки (acceptance criteria), и для тестировщика это главный материал. Каждый критерий покрывают позитивными тест-кейсами, а к ним добавляют негативные и расширенные проверки.
Пользовательских историй, стори-поинтов, покера планирования и velocity в руководстве Scrum нет. Это практики, которые команды добавляют сами, и встречаются они часто, поэтому их стоит знать к первому рабочему дню.
Стори-поинты (story points)
Условные единицы сложности истории. Время они не означают, хотя их часто путают с часами. Историю сравнивают с уже сделанной: если страница регистрации в прошлом спринте получила 1 поинт, то сброс пароля, где критериев приёмки больше, оценят выше.
Покер планирования (planning poker)
Каждый участник выбирает число из ряда Фибоначчи, где каждое следующее число равно сумме двух предыдущих: 1, 2, 3, 5, 8, 13. Когда все проголосовали, оценки сравнивают. Если они сильно расходятся, например 1 и 13, участники объясняют свои доводы и голосуют заново, пока оценки не сойдутся. Вместо чисел иногда берут размеры футболок от XS до XL или даже собак от чихуахуа до тибетского мастифа.
Velocity (скорость команды)
Среднее число стори-поинтов, которое команда закрывала в прошлых спринтах. У новой команды его ещё нет, поэтому первые спринты берут объём на глаз и смотрят, сколько удалось сделать. Когда статистика накопится, становится ясно, например, что в спринт помещается 30 поинтов, и больше на планировании не берут.
Capacity (ёмкость)
Сколько рабочих часов есть у команды в спринте. Пример из урока: в итерации 10 дней, из них 2 выходных, остаётся 8 дней по 8 часов, то есть 64 часа на одного человека, и это число умножают на размер команды. Из ёмкости вычитают праздники и закладывают риск, что кто-то заболеет.
Диаграмма сгорания и накопительная диаграмма потока
Обе есть в отчётах Jira. Диаграмма сгорания (burndown chart) показывает, сколько поинтов осталось до конца спринта, рядом с идеальной линией. Накопительная диаграмма потока (cumulative flow diagram) показывает, сколько задач в статусах To Do, In Progress и Done. Отклонения разбирают Scrum-мастер и менеджмент, а тестировщику полезно туда заглядывать, чтобы понимать, успевает ли команда.
Scrum и Kanban: в чём разница
Обе системы относят к гибким, и на собеседовании их нередко просят сравнить. Я разбираю различия в отдельном ролике 2025 года. По чистому Scrum или чистому Kanban работают редко: команды подстраивают правила под себя, так что на новом месте стоит спросить, как устроен процесс именно здесь.
Пример из команды приложения доставки. У столбца "Тестирование" WIP-лимит 3, и в нём уже три задачи. Разработчик закончил четвёртую, но передвинуть её некуда, поэтому вместо новой задачи он помогает проверить готовые или чинит баги, найденные в них. Если задачи раз за разом скапливаются перед тестированием, доска показывает узкое место, и команда решает, как его расширить, например автоматизирует часть регрессии.
Что это
Scrum – фреймворк, то есть структура с набором правил. Kanban называют методом управления работой, который делает упор на визуализацию и постепенное улучшение процесса. Я считаю Scrum более строгим.
Ритм работы
В Scrum работа идёт спринтами фиксированной длины. В Kanban спринтов нет, и задачи непрерывным потоком двигаются по доске от первого столбца к последнему.
Роли
В Scrum есть владелец продукта, Scrum-мастер и разработчики. Kanban обязательных ролей не вводит.
Планирование
В Scrum планирование проходит в начале каждого спринта. В Kanban обязательной встречи для этого нет, и задачу берут в работу, когда для неё освободилось место.
Ограничения
В Kanban у столбцов доски есть лимиты на число задач в работе (WIP-лимиты), и взять больше нельзя. В Scrum объём спринта ограничивают velocity и capacity команды.
Изменения
В Scrum состав спринта стараются не менять, а изменения, которые угрожают цели спринта, не допускаются. В Kanban задачи можно добавлять и менять в любой момент, если есть свободные люди.
Видеоуроки, шпаргалки и задания
Agile и Scrum я разбираю в 27-м уроке курса "Тестировщик с нуля" на YouTube и показываю в Jira бэклог, спринт, доску с историями и отчёты. В ролике 2025 года "Scrum и Kanban для тестировщика" я сравниваю два подхода. В бесплатном базовом курсе по тестированию тема идёт уроком "Scrum", и после теории в нём есть задания.
Из первоисточников стоит прочитать манифест Agile, руководство Scrum Guide и руководство по Kanban. Шпаргалка по Scrum проводит по дням спринта и показывает, что в каждый из них ждут от тестировщика. В шпаргалке по Kanban есть доска, на которой можно нарушить WIP-лимит и посмотреть, что станет со временем поставки.
Курсы по теме
Вопросы и ответы
Чем Agile отличается от Scrum?
Agile – это ценности и принципы гибкой разработки из манифеста 2001 года, и какие встречи проводить, он сам по себе не говорит. Scrum уже конкретный фреймворк, который воплощает эти ценности: спринты, три зоны ответственности, пять событий и три артефакта. Другой гибкий подход, Kanban, обходится без спринтов и обязательных ролей.
Какие роли есть в Scrum?
По руководству Scrum Guide 2020 года в Scrum-команде три зоны ответственности: владелец продукта, Scrum-мастер и разработчики. Отдельной роли тестировщика нет, он входит в число разработчиков, а за качество отвечает вся команда.
Какие события есть в Scrum?
Пять: спринт, который вмещает остальные события, планирование спринта, ежедневный Scrum на 15 минут, обзор спринта и ретроспектива. Уточнение бэклога событием не считается, это постоянная работа в течение спринта.
Какие артефакты есть в Scrum?
Бэклог продукта, бэклог спринта и инкремент, и у каждого есть своё обязательство. Бэклог продукта ведут к цели продукта, бэклог спринта собирают под цель спринта, а инкремент проверяют по критериям готовности (Definition of Done).
Чем Scrum отличается от Kanban?
Scrum работает спринтами фиксированной длины, с ролями и планированием в начале каждого спринта, и состав спринта по ходу стараются не менять. В Kanban нет спринтов и обязательных ролей, задачи идут непрерывным потоком по доске, число задач в работе ограничено WIP-лимитами, а новые задачи можно добавлять в любой момент.
Что делает тестировщик в Scrum-команде?
На уточнении бэклога и планировании задаёт вопросы к пользовательским историям и участвует в оценке. По ходу спринта пишет тест-кейсы по критериям приёмки и проверяет сделанное, на дейли рассказывает о своих задачах и препятствиях, а на ретроспективе предлагает, как улучшить процесс.
Стори-поинты – это часы?
Нет. Стори-поинт – условная единица сложности истории, её задают сравнением с уже сделанными историями, чаще всего на покере планирования. Сколько поинтов команда успевает за спринт, показывает velocity.
Посмотреть программы курсов
Программа каждого курса открыта целиком: видны все модули, уроки и число шагов.