- Общие принципы
- Жизненный цикл
- Критерии приемки
- Непрерывная доставка и развертывание
- Стратегия Agile testing. Те самые квадранты
- Управление QA-процессами по Agile (на примере TestRail)
- Часто задаваемые вопросы
Главное
Тестирование по Agile — это несколько принципов:
Начать тестирование как можно раньше
Обычно баги на поздних этапах разработки глубоко связаны с бэкендом — это унаследованная проблема от водопадного цикла разработки, когда тестирование проводилось только после завершения разработки.
На этом этапе найти и отладить баги намного сложнее, поэтому для смягчения проблемы нужно привлекать QA-команду уже на этапе мозгового штурма и планирования. Agile-тестирование должно органично вписаться во все этапы жизненного цикла разработки, то есть проводиться на всем его протяжении.
Это означает, что каждый раз когда разработчики создают и пушат новый или скорректированный код, он должен быть протестирован. Нельзя интегрировать новый код в мастер-Git проекта, не подвергнув его многократному тестированию.
Частая доставка
В agile-тестировании продолжительность спринт-цикла варьируется в зависимости от требований и предпочтений команды и обычно составляет несколько недель (каждый спринт в проекте имеет одинаковую продолжительность).
Независимо от продолжительности цикла, тестировщики должны готовить отчеты о тестировании в конце каждого спринта.
Максимальная автоматизация
Автоматизация является неотъемлемой частью успеха, если вы тестируете по Agile. Выполнение тестов в каждом спринте при соблюдении сроков релиза — немыслимо без надежных инструментов автоматизации. Хотя ручное тестирование по-прежнему необходимо, эффективная стратегия, использующая такие концепции, как пирамида автоматизации Майка Кона, обеспечит должную эффективность без ущерба для качества.
Тесная коллаборация между командами
Надежность agile-разработки зависит от сотрудничества между командами в проекте, чему способствуют инструменты, обучение команд, и доброжелательная корпоративная культура. Ежедневные стендапы, еженедельные митинги со стейкхолдерами и инструменты мгновенной коммуникации способствуют командной работе. Культивируйте подход, основанный на единстве, когда каждый член команды, будь то разработчик, тестировщик или бизнес-аналитик, разделяет ответственность за качество продукта.
Вовлечение клиентов
Вовлечение потенциальных клиентов в процесс agile-тестирования имеет значение. Будучи конечными пользователями, они дают бесценную информацию о реальном удобстве использования. Работайте с ними постоянно и на протяжении всего цикла, используя онлайн-платформы и приглашая их к участию в совещаниях по планированию, проверке и ретроспективе. Поощряйте открытое общение, предлагая оставлять отзывы о продукте после каждого спринта — для итеративных улучшений.
Приоритет адаптивности
Каждый член команды в agile-проектах должен уделять внимание качеству на каждом этапе. Адаптация к ожиданиям пользователей требует гибкого мышления, открытого к быстрым изменениям в продукте по требованиям заказчика. Эта гибкость распространяется на всю команду, требуя коллективной готовности к совместной и быстрой работе над изменениями.
Жизненный цикл
Имейте в виду, что эти этапы выполняются итеративно. В каждом спринте команда проходит все эти этапы, а затем начинает с Этапа 1 в следующем спринте.
Оценка влияния фич
Тестировщики анализируют пользовательские истории и выясняют мнение стейкхолдеров, чтобы убедиться, что команде представили требования. После этого тестировщики могут разделить пользовательские истории на отдельные таски.
Планирование процессов
С учетом мнения стейкхолдеров составляются графики тестирования, планы тестирования, детали выполнения, и ожидаемые результаты.
План agile-тестирования описывает подход к тестированию, цели и объем. Планы должны быть достаточно гибкими, чтобы команда могла адаптироваться к изменениям требований. План также должен обязательно включать автоматизацию тестирования и детали ее применения в данном проекте.
На этом этапе есть два важных шага:
Тест-дизайн
Команда создает тест-кейсы и сценарии, а также продумывает детали тестов, исходя из требований и собираемых/генерируемых данных. Придется поработать с разработчиками, чтобы понять, как работает код приложения и что он должен делать.
Разработка тестов
Тестировщики создают и выполняют ручные и автоматизированные тесты. Некоторые специфические agile-тесты, которые основаны на методиках Test-Driven Development (TDD) и Behavior-Driven Development (BDD), могут появиться еще до написания непосредственно кода. Другие тесты типа исследовательских или сессионных «следуют за кодом», разработанным в течение каждого спринта.
Ежедневный скрам (дейлик)
Каждый день в спринте вся команда собирается на короткий «синхрон», чтобы обсудить предстоящие таски, прогресс, а также конфликты или недоразумения, если таковые возникают.
Готовность к релизу
Готов ли продукт к релизу? На этом этапе проводятся тесты, анализируются их результаты и устраняются баги. Часто продукт на этом этапе возвращается на предыдущие этапы разработки, потому что не готов.
Деплой и мониторинг
После того как продукт соответствует всем критериям приемки, он передается на прод. В зависимости от команды и компании, деплой может быть автоматическим или проходить окончательную проверку человеком.
Критерии приемки. Definition of Ready/Done
Как гарантировать, что фича успешно прошла тестирование и готова к передаче на следующий этап? Как узнать, действительно ли разрабатываемый продукт достаточно хорош, чтобы релизить его?
Для этого нужны критерии приемки.
Критерии приемки служат в качестве условий, определяющих готовность продукта к прохождению дальнейших этапов SDLC-цикла. В частности, на заключительном этапе SDLC эти критерии определяют, готово ли приложение к публичному релизу.
Они определяют функциональные возможности, которыми должен обладать продукт, чтобы получить одобрение клиентов или компаний-партнеров.
Эти критерии, разумеется, уникальны для каждого проекта, обычно берутся из пользовательских историй, и отображают желаемое поведение с точки зрения конечного пользователя.
Например, рассмотрим сценарий, в котором вам, например как руководителю QA-отдела, и вашей команде, поручено протестировать фичу, позволяющую пользователям искать товары по Категориям в книжном онлайн-магазине.
Хотя разработчики сделали строку поиска, позволяющую выбирать Категории и вводить слова, она не соответствует требованиям в документации. В документации сказано, что пользователи должны иметь возможность видеть все категории перед поиском в них. А в нашем случае пользователи могут выбрать Категорию, но вынуждены искать лишь по одному ключевому слову, не имея возможности просмотреть все доступные Категории.
Несмотря на то, что заявленная функциональность в принципе работает, она не соответствует требованиям и следующей из них user story. Следовательно, она не соответствует критериям приемки.
В данном контексте критерии приемки обязывают, что: «Пользователи должны получить доступ к Категориям, посмотреть их в главном окне, а затем выполнить поиск». Поскольку это ожидание не исполнено, то несмотря на возможность поиска по Категориям, критерии приемки считаются не выполненными.
Непрерывная доставка и развертывание
Agile-тестирование тесно связано с непрерывной интеграцией и непрерывным развертыванием (CI/CD).
В процессе непрерывной доставки изменения кода тщательно тестируются, таким образом код готовят к релизу. Чаще всего для релиза необходимо одобрение человека — кого-то, кто имеет полномочия пропустить код в продакшен.
Непрерывное развертывание делает практически то же самое без участия человека. Весь процесс автоматизирован, то есть код, протестированный в конвейере CI/CD, автоматически уходит на прод.
Стратегия Agile Testing
Классические квадранты Agile Testing Quadrants помогут QA-команде выбрать нужный тип и уровень тестирования в зависимости от контекста проекта и ресурсов. При планировании релизов и итераций не существует строгих правил относительно того, что должно быть в каждом квадранте. Можно считать их общей «рамкой» для начала планирования QA-процессов.
- Квадрант 1: В этот квадрант входят юнит- и компонентные тесты. Эти тесты проверяют качество билда на базовом уровне и обеспечивают интеграцию нового кода с существующей кодовой базой.
- Квадрант 2: этот квадрант включает тесты для проверки характеристик продукта, ориентированных на клиента и бизнес (customer-facing and business-driven). Они призваны помочь agile-командам добиться улучшения в контексте бизнес-ценности и потребительской ценности.
- Квадрант 3: В этом квадранте тесты не только проверяют качество кода, но и пользовательский опыт (user experience). Как правило, эти тесты выполняются вручную опытными тестировщиками. Тесты на этом уровне требуют таких качеств, как интуиция, визуальное мышление, субъективный анализ и понимание потребительской ценности.
- Квадрант 4: Этот квадрант подразумевает проведение нефункциональных тестов для проверки безопасности, производительности и приемлемости для пользователей. Здесь проверяется стабильность продукта, конфиденциальность данных и общая безопасность.
Можно использовать квадранты, выполняя следующие три шага:
- Определите, является ли выполняемая работа в большей степени ориентированной на бизнес, или на технологию (business-facing or technology-facing).
- Определите, будет ли тестирование направлять разработку или критиковать продукт, исходя из того, на каком этапе цикла разработки или спринта вы находитесь.
- Квадрант, в который вы работаете сейчас, определяет, какой тип (типы) тестирования вам следует провести в этом спринте.
Быстрый пример (финтех)
Пример сценария с использованием квадрантов agile-тестирования: Разработка мобильного банковского приложения
Квадрант 1: Тесты, ориентированные на технологию (поддержка команды)
Тип тестов: Модульные тесты
Цель: Обеспечение функциональности отдельных компонентов кода.
Сценарий: Команда разработчиков работает над новой функцией мобильного банковского приложения — обновлением баланса счета в режиме реального времени. Разработчики пишут юнит-тесты проверки точности расчета баланса, гарантируя, что депозиты, снятие средств и расчет процентов обрабатываются правильно. Эти тесты автоматизированы и запускаются при каждом добавлении нового кода, обеспечивая целостность существующих функций.
Квадрант 3: Тесты, ориентированные на бизнес (поддержка клиентов)
Тип тестов: Приемочное тестирование пользователей (UAT)
Цель: Убедиться, что система соответствует бизнес-требованиям и ожиданиям пользователей.
Сценарий: Перед запуском новой функции владелец продукта работает с конечными пользователями (клиентами банка), контролируя приемочное тестирование. Группа подобранных клиентов работает в тестовой версии приложения, проверяя обновление баланса в режиме реального времени. Они проверяют точность показываемого баланса по своим операциям, убеждаясь, что на балансе правильные суммы и баланс обновляется своевременно. Отзывы, полученные в ходе UAT, передаются командам для доработки функции перед ее официальным выпуском.
Сочетая юнит-тесты квадранта 1 с приемочным тестированием квадранта 3, команда обеспечивает надежный технический фундамент, а также проверяет удобство использования (юзабельность) функции и ее соответствие потребностям клиентов. Такой «дублированный» подход подтверждает точность расчета баланса и проверяет его удобство в реальном мире, повышает общее качество приложения.
Компоненты стратегии эджайл-тестирования
В отличие от водопадного тестирования и со всей его обильной документацией, agile-тестирование сосредоточено на доставке, а стратегия agile-тестирования должна быть направлена на гибкость и адаптацию к изменяющимся требованиям. Универсального подхода не существует, но вот несколько основных элементов:
Документация
Ключ к правильной документации в agile-тестировании — это достижение правильного баланса между достаточным количеством документации, чтобы она служила своей цели, но при этом не перегибать палку с лаконичностью, упуская важные детали. Содержание и структура плана тестирования «по Agile» будут отличаться в зависимости от контекста. Поскольку методология agile-тестирования является итеративной, QA-менеджер должен создавать и обновлять тест-план при каждой новой функции и спринте.
Вот пример шаблона одностраничного agile-плана тестов:
Название тест-плана
Подготовил: Иван Иванов
1. Введение
— Кратко изложена суть (должно быть кратким)
2. Ресурсы и люди
— Имя и роль тестировщика
3. Объем тестирования (Scope of testing)
— Область применения (•In scope): Модули, подлежащие тестированию
— За пределами области (Out of scope): Модули, исключенные из тестирования
4. Подходы к тестированию
— Подходы и методология
— Типы проводимого тестирования (например, функциональное, производительности, безопасности, удобства)
5. График
— Сроки выполнения каждого этапа
6. Риски и проблемы
— Риски, связанные с процессом тестирования
— Стратегии снижения выявленных рисков
Цель agile-плана — свести к минимуму лишнюю информацию и зафиксировать сведения, которые нужны заинтересованным сторонам и тестировщикам для выполнения плана.
Планирование спринтов
В agile-разработке очень важно планировать работу команды в рамках спринтов, ограниченных по времени. Спринты с временными рамками задают ритм команде, обеспечивая продвижение, приспособление (адаптивность) и структурную основу для итеративной разработки; а также способствуют созданию среды для сотрудничества и реагирования вовремя. По сути, это позволяет agile-тестированию «идти в ногу» с agile-разработкой.
Планирование спринта должно учитывать:
- Цели тестирования (Test objectives), основанные на пользовательских историях
- Область тестирования и сроки выполнения
- Типы тестов, применяемые техники, методы, тестовые данные, и тестовые окружения (среды)
Автоматизация в agile-тестировании
Автоматизация необходима для agile-тестирования, без нее QA-командам было бы практически невозможно идти со скоростью agile-разработки. Автоматизация играет ключевую роль следующим образом:
- Завершение (и ускорение в дальнейшем) статического регрессионного тестирования
- Обеспечение быстрой обратной связи по изменениям кода
- Обслуживание процессов непрерывной интеграции и доставки
- Снижение нагрузки на людей
- Более эффективное выполнение тестов
- Высвобождение времени «ручников» для работы над сложными сценариями и рискованными областями приложения
- Повышение тестового покрытия
Какие тесты следует автоматизировать в первую очередь
Как сказано выше, эффективное и масштабируемое agile-тестирование всецело опирается на автоматизацию, поэтому важно подходить к автоматизации стратегически. Первая и самая важная задача — решить, какие тесты автоматизировать. Вот несколько вопросов, которые помогут вам определить приоритеты, что автоматизировать в первую очередь:
- Будет ли тест повторяться много раз?
- Это высокоприоритетный тест (высокоприоритетная функция)?
- Нужно ли проводить тест с несколькими наборами данных или с разными путями?
- Это регрессионный или дымовой тест?
- Можете ли вы автоматизировать его с помощью существующего технологического стека?
- Подвержена ли частым изменениям тестируемая область приложения?
- Это рендомный негативный тест?
- Можно ли выполнять эти тесты параллельно или только в последовательном порядке?
- Насколько дорогая/сложная архитектура требуется для этого теста?
Когда следует автоматизировать тесты во время спринтов?
Существует два подхода:
- Выполнение задач по разработке и автоматизации тестирования одновременно, в спринте.
- Чередование усилий: автоматизация тестирования функций в следующем спринте, после их разработки в текущем спринте.
У обоих подходов есть свои преимущества и тонкости. Параллельный подход гарантирует, что тесты будут готовы к моменту разработки фичи, что способствует быстрой обратной связи и выявлению багов. С другой стороны, поочередный подход позволяет разработчикам не отвлекаться — но потенциально может задерживать автоматизацию.
Выбор между этими подходами зависит от различных факторов, таких как; динамика команды, сроки проекта, сложность функций, навыки команды и специфические требования проекта. Можно комбинировать эти подходы в зависимости от контекста проекта.
Управление рисками
Быстрая поставка продукта в сжатые сроки требует отдавать предпочтение одним тестам перед другими, что повышает потенциальные риски. Тесты с более высоким потенциалом рисков требуют больше внимания, времени и усилий со стороны QA-команды. Это учитывается при планировании спринтов.
Ознакомьтесь с этим видео о том, чем Agile-тестирование НЕ является, чтобы избавиться от распространенных заблуждений об agile-тестировании:
Управление QA-процессами на примере TestRail
Правильно подобранные QA-инструменты играют роль в создании эффективной, гибкой системы тестирования.
Эффективный инструмент должен без проблем интегрироваться с фреймворками автоматизации и платформами управления дефектами, такими как Jira, выступать в качестве централизованного хранилища всей информации связанной с тестированием, и упрощать отслеживание багов.
Часто задаваемые вопросы
Agile-тестирование vs. Непрерывное тестирование
Непрерывное тестирование — это специфический процесс в рамках Agile SDLC-цикла, который, по сути, прописывает автоматизированные тесты в рамки CI/CD-пайплайна. Каждый раз, когда новый код добавляется разработчиком, он должен пройти через серию автотестов, чтобы быть принятым в кодовую базу.
Непрерывное тестирование стало очень успешной методикой, которая позволила снизить бизнес-риски и аномалии.
Непрерывное тестирование требует налаженного сотрудничества между людьми, командами, системами и сервисами. Эти тестовые наборы служат защитой от багов, проникающих в финальную версию приложения, особенно по мере роста его размера и функциональности.
Сдвиг влево и сдвиг вправо
Представим себе жизненный цикл разработки в виде линии. Этапы SDLC начинаются слева (то есть в начале линии) и «движутся» вправо.
Тестирование со сдвигом влево
Тестирование со сдвигом влево подразумевает перемещение тестирования в «левую» часть линии SDLC. Другими словами, тестирование начинается раньше.
Команды планируют, создают и тестируют продукт как можно раньше. Тестировщики участвуют в мозговых штурмах, чтобы лучше понять требования. Затем они приступают к проектированию тестов одновременно с разработчиками, которые пишут код фич. Тесты создаются даже до или одновременно с кодированием.
Большим преимуществом здесь является то, что команды могут предсказать изменения, которые появляются в процессе разработки. Следовательно, они могут сразу же корректировать тесты, не дожидаясь пока будет написан весь код.
Приоритетным направлением в Shift-left-методике является проверка API, также конфигураций контейнеров, и взаимодействий между микросервисами.
Тестирование со сдвигом вправо
С другой стороны, сдвиг вправо подразумевает проверку качества и производительности программного обеспечения уже в реальных условиях.
Как правило, под «реальными условиями» подразумевается тестирование в реальном окружении. Идеальной практикой является тестирование продукта на реальных браузерах и девайсах. Если программа хорошо работает на реальном смартфоне, то, скорее всего, она будет хорошо работать на нем и после релиза.
Когда тестирование смещается в правую часть SDLC-цикла, приоритетом становится проверка: сможет ли продукт справиться с реальным пользовательским трафиком без ущерба для качества? Может ли приложение обслуживать 1000 пользователей так же хорошо как и 100?
Приоритетом при сдвиге вправо является производительность, надежность и отказоустойчивость. Тесты нацелены на поиск дефектов и runtime-проблем, также аномалий, которые обычно не проявляются во время разработки.
Модель тестовой пирамиды
Пирамида тестирования упрощает понимание процессов, создавая визуальную метафору для уровней тестирования. Тестовая пирамида также помогает тестировщику понять, какой объем тестирования должен быть выполнен на каждом уровне.
Пирамида тестирования в целом состоит из трех уровней:
- Модульные тесты — в самом низу
- Сервисные тесты — в середине
- Тесты интерфейса (UI) — в верхней части
Хотя традиционная трехслойная пирамида может показаться слишком упрощенной для современных SDLC-циклов, эта концепция «многослойности» тестов остается эффективной. Полезные советы:
- Пишите тестовые сценарии с разным уровнем детализации, в зависимости от уровня пирамиды
- Количество тестов должно уменьшаться, а охват каждого теста увеличиваться, по мере продвижения к более высоким уровням
- Пишите небольшие и быстрые юнит-тесты
- Пишите подробные высокоуровневые тесты для сквозного тестирования
- Адаптируйте свою пирамиду к требованиям конкретного проекта (например, замените слой тестов сервисов другими тестами, если это лучше соответствует требованиям проекта).
