konechnoe rukovodstvo po metodologii agil’nogo testirovaniya

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

Ниже приведены некоторые принципы, которые лежат в основе процесса Agile-тестирования:

Меньше документации

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

Тестирование на основе TDD (Test-Driven)

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

Непрерывное тестирование

Команда Agile выполняет тесты постоянно, так как это единственный способ гарантировать непрерывное улучшение продукта.

Постоянная обратная связь

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

Участие всей команды в тестировании

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

Сокращение времени реакции на обратную связь

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

Простой и чистый код

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

Каков жизненный цикл Agile-тестирования?

Обычной отправной точкой для тестирования в Agile-командах является написание и внедрение множества планов. Каждый участник команды отвечает за полное понимание стратегии релиза и всех дополнительных пользовательских историй (user stories), включённых в спринты каждого релиза. На этом этапе создаётся документ, в котором подробно описаны все функции и элементы, которые будут включены в предстоящие релизы, и он отправляется команде Agile. После ознакомления всех участников с документом предоставляется план тестирования.

План тестирования

Что такое план тестирования? Это стратегия, разработанная для каждого нового релиза. После каждого релиза план необходимо обновлять. Основная цель создания плана тестирования перед запуском релиза точно определить объём работы, методы тестирования, а также элементы входа и выхода, связанные с каждым релизом.

Планирование спринтов

Далее идёт планирование спринтов. На этом этапе команда обсуждает в рамках спринтов всю работу по подготовке документа и рассматривает все зависимости, которые могут возникнуть во время разработки или тестирования. Для успешного выполнения этого этапа требуется активное взаимодействие участников команды и учёт всей необходимой скорости спринта. Команда также обсуждает прогресс по спринту, используя story points показатели объёма работы, затрачиваемой на тестирование и разработку. Таким образом, при планировании спринтов все оценки по тестированию и разработке предоставляются заранее.

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

Этапы реализации и выполнения

После завершения планирования спринта начинаются этапы реализации и выполнения.

На этом этапе разрабатываются тест-кейсы и связываются с соответствующими пользовательскими историями. Также на этом этапе могут быть добавлены новые user stories, и проводится peer review для оценки работы продукта.

Данные действия направлены на повышение осведомлённости QA-команды о функциях продукта, что помогает увеличить покрытие тестами. Каждый тест-кейс обязательно привязывается к соответствующей user story, чтобы убедиться, что тесты соответствуют нужным историям.

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

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

Все найденные дефекты в user stories и тест-кейсах регистрируются в инструменте управления багами и связываются с соответствующими элементами. Для обсуждения стратегии исправления дефектов проводится triage-встреча. После исправления баги повторно тестируются по всем историям и затем закрываются.

Деятельность по закрытию спринта

Пользовательские истории считаются завершёнными и готовы к утверждению Product Owner после того, как все дефекты, связанные с тест-кейсами, были устранены. Пользовательские истории повторно протестированы и закрыты. Проводится обзор спринта (sprint review), чтобы продемонстрировать результаты, достигнутые за время спринта. Если какие-либо истории, над которыми работали в спринте, не могут быть завершены из-за нерешённых багов или незавершённой разработки, эти истории переносятся в следующий спринт. Важно чётко понимать, что история считается доставленной только тогда, когда все связанные с ней тестовые активности завершены, а не только когда выполнена разработка.

Регрессия

Тестирование на регрессию проводится после завершения всех спринтов, связанных с релизом. Тест-кейсы функций, запланированных для включения в релиз, и тест-кейсы предыдущих релизов, на которые повлияли эти функции, объединяются в регрессионный набор. Product Owner утверждает этот регрессионный набор.

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

Деятельность по релизу

После релиза сборка передаётся в UAT (User Acceptance Testing) для ограниченного тестирования пользователями. Альфа-тестировщики проводят smoke-тест при получении релиза в UAT. Если smoke-тест пройден успешно, сборка передаётся бета-тестировщикам для дальнейшего тестирования перед выпуском в продакшен. После тестирования сборка отправляется в продакшен для тестирования конечными пользователями. Альфа-тестировщики повторяют процесс после smoke-тестирования. Все найденные ошибки в продакшен-релизе фиксируются немедленно; если это невозможно, выпускается точечный релиз для устранения проблем.

Подготовка к следующему релизу

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

Какие существуют методы Agile-тестирования?

Существует множество подходов к Agile-тестированию. Давайте рассмотрим их.

Методология Acceptance Test-Driven Development (ATDD)

ATDD делает упор на вовлечение участников команды, которые рассматривают проблему с разных точек зрения: клиента, разработчика и тестировщика. Для создания acceptance-тестов, учитывающих мнения клиента, команды разработчиков и команды тестирования, проводятся встречи под названием «Three Amigos». Клиент фокусируется на проблеме, которую необходимо решить, команда разработчиков на том, как эта проблема будет решена, а команда тестирования на возможных проблемах, которые могут возникнуть. Acceptance-тесты отражают точку зрения пользователя и описывают, как система будет работать в будущем. Также они помогают убедиться, что система функционирует должным образом. В некоторых случаях acceptance-тесты проводятся автоматизированным способом.

Behavior Driven Development (BDD)

Behavior Driven Development (BDD) направлен на улучшение коммуникации между различными заинтересованными сторонами проекта. Прежде чем начать активную разработку, все участники должны полностью понимать все функции продукта. Поэтому общение между разработчиками, тестировщиками и бизнес-аналитиками поддерживается постоянно и строится на примерах.

Эти примеры называются сценариями и оформляются в особом формате Gherkin (Given/When/Then). Каждый сценарий содержит ключевую информацию о том, как функция должна вести себя в различных контекстах и с различными входными параметрами. Такой подход называется «Исполняемые спецификации» (Executable Specifications). Документ Executable Specifications включает как саму спецификацию, так и входные данные для автоматизированных тестов.

Exploratory Testing (исследовательское тестирование)

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

Hire Agile testers India