В этой статье я расскажу простыми словами об основных концепциях Agile и о том, какое место занимает тестирование в процессе разработки продукта. Материал будет полезен в первую очередь начинающим тестировщикам. Что такое Agile? Agile — это методология управления проектами. Основная суть agile заключается в том, чтобы помочь людям организоваться создавать что-то, а не бесконечно это что-то обсуждать. Если упростить, все типы проектов обычно реализуются примерно по такой схеме: «Оформление идеи и сбор требований  > Разработка > Проверка результата на соответствие ожиданиям». В рамках Agile мы стараемся сократить время, затрачиваемое на первую стадию оформления идеи, чтобы можно было скорее перейти к разработке, поэтому мы не ожидаем сразу идеального результата. Стоит отметить, что при таком подходе мы можем доставить не то, что нужно... НО ЭТО НОРМАЛЬНО! Зато мы довольно быстро выходим на рынок и можем обратиться к клиентам за обратной связью, а затем также быстро внести изменения в продукт. Разновидности Agile (простыми словами) Kanban — это когда бизнес постоянно просит что-то сделать, а команда для реализации просто берет последние пункты из списка задач. Такой подход предполагает постоянный выпуск релизов. Scrum — мы выделяем определенный период времени на разработку и фокусируемся на нескольких запросах, которые должны быть выполнены за это время. В этом случае получаются более структурированные релизы. Scrummerfall — как в Scrum, только без итераций. В этом случае мы планируем доставить весь проект за один раз. Что ж, хорошо… и как это работает? В этой части статьи я приведу высокоуровневое описание частей 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. В ходе этого занятия вы научитесь составлять баг-репорты для разных багов, найденных в разных обстоятельствах. Присоединяйтесь, будет полезно. Зарегистрироваться на урок