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

Что такое Agile?

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

Если упростить, все типы проектов обычно реализуются примерно по такой схеме: «Оформление идеи и сбор требований  > Разработка > Проверка результата на соответствие ожиданиям». В рамках Agile мы стараемся сократить время, затрачиваемое на первую стадию оформления идеи, чтобы можно было скорее перейти к разработке, поэтому мы не ожидаем сразу идеального результата.

Рис. 1. Скромные ожидания помогают быстрее начать работу
Рис. 1. Скромные ожидания помогают быстрее начать работу

Стоит отметить, что при таком подходе мы можем доставить не то, что нужно... НО ЭТО НОРМАЛЬНО! Зато мы довольно быстро выходим на рынок и можем обратиться к клиентам за обратной связью, а затем также быстро внести изменения в продукт.

Разновидности Agile (простыми словами)

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

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

Scrummerfall — как в Scrum, только без итераций. В этом случае мы планируем доставить весь проект за один раз.

Что ж, хорошо… и как это работает?

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

Рис. 2. Agile-процесс для Scrum
Рис. 2. Agile-процесс для Scrum

Собираем требования к продукту

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

Приводим задачи к состоянию готовности взять их в работу

Чтобы над бэклогом можно было эффективно работать, он должен быть понятным. Мы проводим такие встречи, как Triforce (здесь можно почитать о них подробнее), чтобы привести запросы от бизнеса в состояние готовности к работе. Это означает, что бизнес ясно говорит нам, чего они хотят, а мы можем оценить, сколько времени это займет. Многие команды используют документ под названием Definition of Ready (DoR, «критерии готовности») — список критериев готовности задачи к взятию в работу.

Выбираем задачи, над которыми будем работать в течение спринта

Команда (или проектная группа) выбирает из бэклога задачи, над которыми она будет работать в течение спринта (заранее определенного периода времени). Мы проводим встречи: Backlog refinement — установочная встреча, на которой обсуждаем план работы на спринт, а также Sprint Kick-off — встреча, на которой финализируем список задач из бэклога, которые пойдут в спринт. Идея заключается в том, что команда сама выбирает, над чем и в каком объеме ей работать, на основании всех сделанных ею оценок объема работ.

Зачем работать по спринтам?

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

Работаем над задачами спринта

Затем команда работает над согласованным списком задач на спринт: выбирают задачи из бэклога, реализуют и доводят до готового состояния. Состояние готовности означает, что работа выполнена в достаточной степени, чтобы ее можно было доставить, а значит, мы должны обеспечить ее тестирование и понимать, как задача согласуется с финальным результатом. Многие команды используют критерии готовности (Definition of Done) — список требований, которым должна соответствовать задача, чтобы считаться завершенной (например, протестирован ли результат?)

В течение этого периода работы команды проводят ежедневные короткие встречи (daily stand up). На этих встречах члены команды рассказывают о текущих результатах и планах работы; а также обсуждают, нет ли каких-либо трудностей или проблем, для решения которых необходима помощь коллег.

Демонстрируем результаты работы

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

Как тестирование вписывается в процесс

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

Проводим раннее тестирование

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

  • Когда менеджер продукта говорит: «хочу это», мы тестируем идеи, чтобы добиться полного понимания того, что «это» значит.

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

  • В процессе сборки проводим тестирование посредством юнит-тестов, а также убеждаемся в том, что команда помнит о рисках.

  • Проводим тестирование, чтобы убедиться в готовности (в соответствии с нашим командным соглашением о том, как должен выглядеть финальный результат).

  • Анализируем работу после релиза и передаем команде полученные инсайты.

Тестируем быстро

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

  • Быть прагматичными и проводить «достаточное» тестирование, не позволяя своему эго настаивать на исчерпывающем тестировании.

  • Автоматизировать как можно больше тестов — это поможет сэкономить время и даст возможность заняться другими вопросами.

  • Отстаивать подход проведения тестирования на более ранних этапах — например, активное создание юнит-тестов, поскольку их быстрее внедрить и запустить.

  • Проводить тестирование на малых процессах (фичи и интеграции) вместо громоздких сквозных процессов.

  • Тестирование локально, не дожидаясь деплоя в больших средах.

  • Иметь доверие к тому, что уже протестировано другими людьми, и не проводить повторное тестирование.

Остаемся вовлеченным на всех этапах работы над продуктом

Будучи тестировщиками, мы должны отстаивать качество в Agile-команде. Это означает, что мы должны быть активными членами команды, не стесняться отстаивать свои идеи и не отходить на второй план.

  • Продвигайте идею QA: образовывайте коллег по части того, что такое тестирование, какую пользу оно несет и какие задачи в него входят.

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

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

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


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

Комментарии (2)


  1. astenix
    23.08.2023 08:13
    +1

    Эй, много пишущий и почти ничего не комментирующий мангуст,

    1) Agile — это НЕ методология управления проектами. Это фреймворк, который можно положить поверх какой-то методологии.

    Вообще agile — это прилагательное, которое не может существовать само по себе. Например, прилагательное «храбрый» или «озорной» нуждается в объекте. Поэтому сперва методология, затем «агиле» поверх.

    2) Scrum, если следовать вашему толкования, это «разновидность agile». Не будет ли корректнее назвать это системой управления в контексте фреймворка agile?

    Не будет ли разумно объяснить, почему это называется scrum?

    Не будет ли разумно объяснить, почему «заранее определенный период времени» называется спринтом?

    Есть на эту тему удивительно тонкая, но всё проясняющая книга «Clean Agile — Back to Basics» (Robert C. Martin). Её перевели в издательстве «Питер» на рус, но лучше, конечно, глянуть в оригинал. Будучи тестировщиками, мы должны понимать, что именно и в чём мы отстаиваем, не так ли?


  1. Mike-M
    23.08.2023 08:13

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

    Читается как "сначала делаем, потом думаем".


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

    В результате выпускаем продукт о-о-очень далекий от идеала.
    А потом удивляемся, почему всего 12% стартапов доживают до 5-летнего возраста?..


    при таком подходе мы можем доставить не то, что нужно… НО ЭТО НОРМАЛЬНО! Зато мы довольно быстро выходим на рынок и можем обратиться к клиентам за обратной связью, а затем также быстро внести изменения в продукт.

    О, да! Зачем платить зарплату штатным тестировщикам, если можно бесплатно тренироваться на кошечках клиентах…
    Но это ещё полбеды. Главная беда в том, что компании слишком редко прислушиваются к обратной связи, которую они якобы так ждут от клиентов. По личному многолетнему опыту, исправляется лишь 10, максимум 20 процентов обнаруженных багов.


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

    А то что без code freeze результаты тестирования могут отличаться — это никого не волнует.


    Быть прагматичными и проводить «достаточное» тестирование, не позволяя своему эго настаивать на исчерпывающем тестировании.

    Да-да, пресловутое good enough. Так и получаются продукты, которые, вроде бы, работают, но из-за "сырости" пользоваться ими не хочется.


    Автоматизировать как можно больше тестов

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


    Тестирование локально, не дожидаясь деплоя в больших средах.

    Основа основ — тестирование в условиях, максимально приближенных к production. Иначе багов класса "у меня работает, а у тебя нет" не избежать.


    Иметь доверие к тому, что уже протестировано другими людьми, и не проводить повторное тестирование.

    То есть код, покрытый юнит-тестами, на более высоких уровнях пирамиды тестирования можно не проверять? )


    Остаемся вовлеченным на всех этапах работы над продуктом

    Пожалуй, это то немногое, с чем я согласен в статье. Но и здесь есть нюанс.


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

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


    Подводя итог, за долгие годы работы в компаниях разных направлений и масштабов я пришел к простому выводу.
    Agile — это ни что иное как завуалированный способ мягкого контроля над сотрудниками, способ постоянно держать команду в тонусе, не давая ей расслабляться.
    Daily standup — краткий устный отчет о проделанной работе перед скрамоводом.
    Agile нужен бизнесу для быстрого выхода на рынок. Но рынку, то есть нам с вами — пользователям, "быстрые" продукты не нужны. По причинам, указанным выше.