что такое спринт в тестировании

Будь гибким: как понять Scrum и создать agile-команду

Scrum — методология гибкого процесса разработки программного обеспечения. Сейчас этот метод управления популярен и активно применяется.

Прежде чем разобраться, что такое Scrum и как внедрить эту методологию, давайте посмотрим на предпосылки её возникновения.

Как и зачем появилась Scrum-методология

До появления Scrum в мире разработки программного обеспечения было принято использовать «водопадный подход». Работа над продуктом велась по следующему плану.

Разработчики согласовывали план работы с заказчиком и чётко следовали техническому заданию. Когда продукт был готов, его тестировали, но уже не было возможности что-то поменять. Поэтому, если выявлялись ошибки, приходилось начинать всё сначала, а сроки работы увеличивались.

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

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

Манифест гибкой разработки ПО

1. Люди важнее инструментов.
2. Качество продукта важнее документации.
3. Взаимодействие с заказчиком важнее контракта.
4. Готовность к изменениям важнее установленного плана.

Эти четыре пункта стали основой для появления Agile, гибкого процесса разработки программного обеспечения. Позже были созданы 12 принципов, которые и сейчас используются в любой Agile-методологии.

12 принципов Agile

1. Главное — хорошее ПО и довольный заказчик.
2. Готовность к изменениям в любой момент.
3. Полностью рабочее ПО — как можно чаще.
4. Встреча команды — лучше всего для обмена информацией.
5. Заказчик и команда разработки должны работать вместе.
6. Доверять людям делать свою работу.
7. Есть рабочее ПО — есть прогресс.
8. Гибкие процессы — непрерывное развитие.
9. Внимание к качеству способствует гибкости.
10. Простота процесса позволяет не делать лишней работы.
11. Самоорганизующаяся команда лучше работает.
12. Постоянное стремление к большей эффективности.

Одна из методологий гибкого процесса разработки программного обеспечения, которая базируется на agile-принципах, — Scrum.

Создатели Scrum Джефф Сазерленд и Кен Швабер долгие годы наблюдали за работой американских военных, спецназовцев и даже регбистов. И заметили, что их успех основан на взаимодействии и командной работе. Сазерленд и Швабер поняли, что этого как раз и не хватает разработчикам программного обеспечения. Так появилась методология Scrum.

Принципы Scrum

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

Работа короткими циклами (спринтами)

Планируйте один спринт, а не весь проект сразу. Каждый спринт — период, в который команда работает над полностью законченной частью продукта.

Гибкость. «Проверять и адаптироваться»

Гибкость процесса и тестирование продукта после каждого спринта. Если что-то идёт не так, команда всегда готова сменить стратегию разработки или пересмотреть бэклог продукта.

Участие заказчика и пользователей в создании продукта

Заказчик не стоит в стороне, а полностью задействован в работе. Для этого существует роль владельца продукта, которую выполняет сам заказчик или его представитель. Именно через него команда взаимодействует с пользователями. Так как разработка ведётся короткими этапами, пользователи подключаются к тестированию почти сразу.

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

Scrum-команда — это несколько человек, которые работают на один результат и как единое целое. Каждый стремится к общей цели.

О важности scrum-команды

Scrum-команда — это чаще всего группа из пяти-девяти человек. Это оптимальное количество, но иногда встречаются команды и из трёх человек. Если людей больше, то им становится сложнее взаимодействовать между собой, что мешает работе и снижает продуктивность.

Состав команды

Принципы работы scrum-команды

Чтобы работать по методологии Scrum, команда разработчиков должна соблюдать три основных принципа.

Совершенствование продукта за счёт самосовершенствования сотрудника.

Каждый член команды отвечает за свою часть работы и за общий результат.

Каждая команда самодостаточна, так как в ней собраны люди с разными навыками.

Процесс работы scrum-команды

Процесс работы scrum-команды проходит в несколько обязательных этапов.

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

Дальше команда оценивает объём работ, оговаривает длительность спринта, в конце которого должен появиться результат, то есть готовый продукт.

Каждый день вся команда проводит короткую встречу, не более 15 минут. Scrum-мастер и владелец продукта тоже участвуют. Суть встречи — получить от каждого члена команды ответ на три вопроса:

Задача scrum-мастера — понять, если что-то идёт не так, и помочь команде справиться с трудностями.

Scrum-команда вешает в помещении для совещаний доску с разноцветными стикерами. Она делится на части, где отражается весь процесс работы над проектом. Тут могут быть варианты, но обязательно присутствуют три части. Первая — «Что нужно сделать», вторая — «В работе», третья — «Сделано». Этот простой способ помогает всем членам команды следить за общим ходом работы.

Если кто-то из членов команды понимает, что не укладывается в спринт, он сообщает владельцу продукта, а тот распределяет время иначе. То же самое происходит, если команда понимает, что справится с задачей досрочно, — тогда можно добавить дополнительных задач из бэклога продукта.

Когда задачи спринта выполнены, команда должна продемонстрировать полностью работающую демоверсию той части ПО, над которой велась работа в спринте.

Как внедрить scrum-методологию

Сейчас методология Scrum находится на пике популярности. Вопрос о её пользе уже почти не звучит. Но как внедрить Scrum правильно, чтобы заметно улучшить ситуацию с продуктивностью и качеством итогового продукта?

Кажется, что всё просто. Нужны несколько последовательных действий.

Это первый и основной шаг. Именно от слаженной работы команды зависит качество будущего продукта. Но не так легко собрать кросс-функциональную команду.

2. Назначить владельца продукта

Это может быть заказчик или его представитель. Владелец продукта будет отвечать за взаимодействие с заказчиком и работать с пользователями на всех этапах разработки.

3. Выбрать scrum-мастера

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

4. Создать список требований к продукту

Прежде чем начать разработку, стоит подумать над списком требований и согласовать их. Получится своего рода техническое задание, которое будет направлять работу.

5. Спланировать спринт

Разделить всю работу на периоды. Планировать каждый спринт. Не весь процесс разработки сразу, а только ближайший цикл.

6. Постоянно анализировать и оценивать результат

Подводить итоги после каждого спринта и оценивать результат. Переходить к следующему спринту, только если довольны результатом предыдущего.

Вот они — шесть шагов, которые ведут к увеличению продуктивности разработчиков, сокращению сроков работы и качественному программному обеспечению. Но так ли это просто, как кажется на первый взгляд? Как понять, успешно ли внедрён Scrum, и сделать так, чтобы не испортить показатели ещё больше?

Сейчас много scrum-теоретиков, которые плохо понимают, как работать с реальным продуктом. Поэтому важно учиться только у тех, кто знает, что такое Scrum, на практике, разбирается во всех тонкостях не только методологии, но и её внедрения в конкретную область. Ведь этот процесс сильно зависит от продукта, который вы собираетесь создавать с помощью Scrum.

Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства CRM-маркетинга Out of Cloud.

Упорядоченный список задач, над которыми scrum-команда работает при создании продукта.

Источник

Тестирование в рамках SCRUM. Тернии, грабли и успехи

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

Начнём с перечисления ключевых особенностей SCRUM для тех, кто с ним не знаком:

Проблемы

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

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

Опыт внедрения

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

Схема 1. Назовем её «Однократное тестирование + проверка фиксов».

Плюсы данного подхода:

Минусы данного подхода:

Порой заказчик сам любил тестировать продукт, а у команды не было жёсткого списка тех задач, которые должны быть выполнены в данный спринт, кроме списка задач на этап. Это оборачивалось следующим:

Итог работы по схеме: получился качественный продукт, но производственный процесс нельзя было полностью назвать SCRUM’ом. Заказчик был часто недоволен тем, что сам находил баги, хотя итоговый результат его вполне устроил.

Дышим ровно, бежим дальше.

Схема 2. Её назовём «Потоковое тестирование».

Плюсы данного подхода:

Минусы данного подхода:

Итог работы по схеме: значительно лучше первой схемы, но не без недостатков. Чтобы сгладить их, мы выделили для себя некоторые дополнительные правила.

Cейчас у вас откроется второе дыхание — мы выходим на финишную прямую.

Работа над ошибками

Эти приёмы в ведении проектов по SCRUM-методологии мы вывели для себя в процессе работы и продолжаем их оттачивать. Надеемся, что они будут полезны и вам:

Решаемые проблемы

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

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

Источник

Что такое спринты в программировании

Это время, за которое команда успевает решить какую-то часть задач.

Когда вы попадёте на работу в ИТ-компанию, вы обязательно услышите одну из этих фраз:

Разберём, что это за спринты такие и зачем они нужны.

Ситуация

У команды разработчиков есть большой проект, где нужно сделать много разных вещей:

Времени на всё — 6 месяцев, и кажется, что этого достаточно. Но это может быть обманчиво, потому что команда расслабляется, каждый начинает делать что-то своё, а за месяц до финала выясняется, что вместе эти отдельные части работать не будут. Например, сервер не отдаёт данные в нужном формате для веб-страницы, приложения хранят данные только у себя и не умеют отправлять их на сервер, а авторизация в соцсетях работает только на Андроиде.

Чтобы этого не произошло, используют спринты.

Что такое спринт

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

Задача спринта — чтобы по его итогу что-то работало. Например, если мы взяли в спринт единую авторизацию в сервисе, то к концу спринта она должна работать и быть протестированной. Нельзя к концу спринта сказать «Ой, ну ничего, в следующий раз доделаем». К концу спринта должно быть готово.

Что делают в спринте

Цели у спринта могут быть общими для всей команды. Например:

А могут быть для каждого свои:

Кто именно и что делает — это определяет кто-то из руководителей, например, тимлид или менеджер проекта. У него в голове цельная картинка проекта, которую он раскладывает на конкретные маленькие шаги. Менеджер отвечает за корректную постановку задач, а разработчик — за то, чтобы эта задача была выполнена в срок.

Что после спринта

После спринта проводят ретроспективу — это встреча, на которой команда сама оценивает свой результат. Например, они могут обсудить такое:

Цель ретроспективы — подвести итоги спринта и понять, как лучше строить работу в следующем спринте, чтобы всё получалось лучше и интереснее, чем в этом.

После ретроспективы всё по новой.

Где нужны спринты

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

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

Если же задача решается за пару дней или пару недель, то спринты не нужны — нужно просто собраться и сделать.

Все знают, что компьютеры состоят из единиц и нулей. Но что это значит на самом деле?

Если ты можешь сделать страницу о себе, ты можешь сделать всё.

Ваш пропуск в мир винтажных приставок и хакерских игрушек

Это когда старая игра запускается на новой приставке

Фраза из лексикона сильных профессионалов

И что это вообще такое

Это когда программисты делают то, что скажут дизайнеры, или наоборот.

Это маленькие программы, которые работают в фоновом режиме

Это время, за которое команда успевает решить какую-то часть задач.

С чего начать, на что не тратить время, кому уже поздно.

Это виртуальная инструкция к любому «железу» в компьютере

Источник

Спринты

Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы.

Просмотр тем

Что такое спринты?

Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы. Спринты лежат в основе методологий scrum и agile, и правильный выбор спринтов поможет вашей agile‑команде выпускать более качественное программное обеспечение без лишней головной боли.

«При использовании scrum продукт разрабатывается в ходе нескольких итераций с фиксированной продолжительностью, которые называются спринтами и разбивают большие сложные проекты на небольшие задачи», — говорит Меган Кук, менеджер группы товаров для Jira Software в Atlassian.

Многие ассоциируют Scrum-спринты с Agile-разработкой программного обеспечения настолько часто, что Scrum и Agile принимают за синонимы. Однако это не так. Agile — это набор принципов, а Scrum — методика для активного решения задач.

Многочисленные сходства между глобальными задачами agile и процессами scrum вполне справедливо приводят к тому, что эти два понятия ассоциируются друг с другом. Благодаря спринтам команды могут следовать agile‑принципу «частой поставки рабочего программного обеспечения», а также реализовать agile‑задачу «реагирования на изменения в соответствии с планом». Установки scrum — прозрачность, проверка и адаптация — дополняют agile‑методику и играют главную роль в концепции спринтов.

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

Как планировать и выполнять спринты в scrum

Авторы Scrum действительно все предусмотрели. Чтобы запланировать предстоящий спринт, нужно провести собрание по планированию спринта. Планирование спринта — это мероприятие, на котором команда сообща отвечает на два основных вопроса: какую работу можно выполнить в этом спринте и как она будет выполняться?

Выбором подходящих рабочих задач для спринта занимаются совместно владелец продукта, Scrum-мастер и команда разработчиков. Владелец продукта определяет цель спринта и задачи из бэклога продукта, при выполнении которых она будет достигнута.

Затем команда создает план, согласно которому будут выполняться задачи бэклога, чтобы к окончанию спринта вся работа была завершена. Выбранные рабочие задачи и план по их выполнению называется бэклогом спринта. К концу совещания по планированию спринта команда готова приступить к работе. Для этого необходимо просто выбирать задачи из бэклога спринта и менять их статус с «В работе» на «Готово» по мере завершения работы.

В течение спринта команда собирается на ежедневные Scrum‑совещания (стендапы), чтобы обсудить ход работы. Такие совещания нужны, чтобы выявить блокеры и проблемы, которые могут повлиять на достижение цели спринта.

По окончании спринта команда показывает выполненную работу на обзоре итогов спринта. Здесь можно продемонстрировать итоги работы заинтересованным сторонам и другим участникам команды до того, как они попадут в рабочую среду.

Завершите цикл спринтов на моем любимом собрании — ретроспективе спринта. Здесь команда может определить области, требующие улучшения в следующем спринте. С этими сведениями можно начинать следующий цикл спринта. Вперед!

Что стоит и не стоит делать

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

И если уж вы работаете над тем, чтобы стать сильным специалистом по scrum, выполняя рекомендации, ознакомьтесь также с действиями, которые выполнять не следует.

Чего не стоит делать.

Оптимизируйте спринты с помощью автоматизации

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

Эти и сотни других правил автоматизации можно найти в библиотеке шаблонов Jira Automation.

Подробнее о спринтах

Спринты настолько известны (и настолько эффективны), что их часто считают первым шагом на пути к повышению гибкости. Но мы выяснили, что для освоения спринтов необходимо овладеть некоторыми взаимосвязанными понятиями Scrum и Agile. Изучите остальные статьи по Scrum, чтобы расширить знания и стать еще на шаг ближе к счастью от использования Scrum.

Источник

Автоматизация тестирования по методологии Scrum

Все больше и больше набирает обороты использование методологий семейства Agile, так называемых гибких методологий, в сфере IT. К этому семейству, как вы знаете, относятся такие методологии, как Kanban, XP, Scrum и прочие, менее известные методологии.

Напомню в чем смысл каждой из них по версии ISTQB:

Отличительными особенностями Kanban являются:

Отличительными особенностями Scrum являются:

А как построен Scrum у нас?

Команда состоит из PO (Product owner), Scrum Master и Developing Team, которая в свою очередь состоит из 1 QA Automation, 1 Backend developer, 1 Frontend developer, 1 UX и 1 верстальщика. Разработка идет итерационно, спринтами по 2 недели. Во время каждого спринта проводится несколько типов встреч:

Как пример для автоматизатора — внедрение Allure отчетов, для девелопера — оптимизация работы запросов.

Тестирование в Scrum

В начале процесса автоматизации тестирования необходимо настроить CI, чтобы проводить регрессионное тестирования автоматически. Цель — свести ручную работу к минимуму. Потому что времени ни на что нет, нужно работать быстро. После этого стоит заняться репозиторием, настроить запуск сборки по Merge request. Если кто-то из разработчиков отправил что то в основную ветку проекта, запускается сборка и по ее результатам можно понять корректны ли внесенные изменения.

Перед тем как приступить к написанию тестов, необходимо разобраться в основной бизнес-идее проекта, чтобы определить области высокого риска на которые обращается внимание в первую очередь. Все таки будем реалистами, полностью покрыть тестами приложение, пусть оно и маленькое, не получится. Сазерленд писал, что на реализацию всего Бэклога никогда нет времени, поэтому он всегда применял к Backlog принцип Парето. Пишем 20% автотестов, покрывающих 80% возможных дефектов.

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

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

Необходимые качества автоматизатора тестирования

Автоматизатор, а в Scrum особенно, должен быть технически подкован, чтобы понимать как работает приложение так сказать “под капотом”. Важно уметь быстро и легко переходить с одной технологии на другую. Например, при изменении базы данных, нужно быть готовым изменить способ подключения к ней. Стек технологий должен быть как можно шире.

Scrum предполагает быструю реакцию на изменения, срочное внесение исправлений. Предположим, что пользователи обнаружили некое несоответствие в работе приложения, команда разработки должна как можно быстрее отреагировать и выпустить патч. Для этого важно уметь очень точно локализовать проблему. В этом очень хорошо помогает автотестирование. Допустим у нас есть трехуровневое web-приложение: есть DB, frontend, backend. Где то в приложении есть баг. При использовании ручного тестирования поиск проблемы может занять не один день, затем проблему нужно будет исправить и вновь протестировать. При автотестировании мы запускаем регрессоное тестирование и в течение пары часов получаем полный отчет, в котором отражено точное местоположение бага.

Источник