Agile Testing — Обзор

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

Agile Manifesto

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

Agile Manifesto — это

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

• Люди и взаимодействия по процессам и инструментам.
• Рабочая программа над исчерпывающей документацией.
• Сотрудничество с клиентом по договору.
• Реагировать на изменения в соответствии с планом.

То есть, хотя в элементах справа есть ценность, мы слева оцениваем элементы больше.

Что такое Agile Testing?

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

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

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

Agile Testing охватывает все уровни тестирования и все виды тестирования.

Agile Testing Vs. Водопад Тестирование

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

Ниже приведены основные отличия Agile Testing и Waterfall Testing —

Agile Testing	Водопад Тестирование
Тестирование не является отдельной фазой и происходит одновременно с разработкой.	Тестирование — это отдельная фаза. Все уровни и виды тестирования могут начинаться только после завершения разработки.
Тестеры и разработчики работают вместе.	Тестеры работают отдельно от разработчиков.
Тестеры участвуют в разработке требований. Это помогает в сопоставлении требований к поведению в сценарии реального мира, а также в формировании критериев приемлемости. Кроме того, логические Приемочные тестовые случаи будут готовы вместе с требованиями.	Тестеры могут быть не вовлечены в фазу требований.
Приемочное тестирование проводится после каждой итерации и запрашивается обратная связь с клиентом.	Приемочные испытания проводятся только в конце проекта.
Каждая итерация завершает свое собственное тестирование, что позволяет проводить регрессионное тестирование каждый раз, когда выпускаются новые функции или логика.	Регрессионное тестирование может быть реализовано только после завершения разработки.
Никаких задержек между кодированием и тестированием.	Обычные задержки между кодированием и тестированием.
Непрерывное тестирование с перекрывающимися уровнями тестирования.	Тестирование — это заданное по времени действие, и уровни тестирования не могут перекрываться.
Тестирование — это лучшая практика.	Тестирование часто пропускается.

Принципы гибкого тестирования

Принципы гибкого тестирования:

• Тестирование продвигает проект вперед. Непрерывное тестирование — единственный способ обеспечить непрерывный прогресс. Agile Testing обеспечивает обратную связь на постоянной основе, и конечный продукт отвечает требованиям бизнеса.

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

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

• Сокращение циклов обратной связи — В Agile Testing бизнес-команда узнает о разработке продукта для каждой итерации. Они участвуют в каждой итерации. Непрерывная обратная связь сокращает время отклика обратной связи, и, следовательно, затраты на его устранение уменьшаются.

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

• Облегченная документация — вместо исчерпывающей документации по тестированию Agile Testers —

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

  • Сосредоточьтесь на сути теста, а не на случайных деталях.

  • Используйте легкие стили документации / инструменты.

  • Запишите идеи испытаний в чартеры для пробных испытаний.

  • Используйте документы для нескольких целей.

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

• «Готово Готово», а не просто выполнено — говорят, что в Agile функция выполняется не после разработки, а после разработки и тестирования.

• Test-Last против Test Driven — Тестовые случаи пишутся вместе с требованиями. Следовательно, развитие может быть обусловлено тестированием. Этот подход называется разработкой, управляемой тестированием (TDD), и разработкой, основанной на приемочных испытаниях (ATDD). Это в отличие от тестирования в качестве последнего этапа в тестировании водопад.

Тестирование продвигает проект вперед. Непрерывное тестирование — единственный способ обеспечить непрерывный прогресс. Agile Testing обеспечивает обратную связь на постоянной основе, и конечный продукт отвечает требованиям бизнеса.

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

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

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

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

Облегченная документация — вместо исчерпывающей документации по тестированию Agile Testers —

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

Сосредоточьтесь на сути теста, а не на случайных деталях.

Используйте легкие стили документации / инструменты.

Запишите идеи испытаний в чартеры для пробных испытаний.

Используйте документы для нескольких целей.

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

«Готово Готово», а не просто выполнено — говорят, что в Agile функция выполняется не после разработки, а после разработки и тестирования.

Test-Last против Test Driven — Тестовые случаи пишутся вместе с требованиями. Следовательно, развитие может быть обусловлено тестированием. Этот подход называется разработкой, управляемой тестированием (TDD), и разработкой, основанной на приемочных испытаниях (ATDD). Это в отличие от тестирования в качестве последнего этапа в тестировании водопад.

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

Проведение Agile-тестирования на уровне проекта —

• Планирование выпуска (план тестирования)

  • Для каждой итерации

  • Операции гибкого тестирования во время итерации

• Регрессионное тестирование

• Действия по выпуску (связанные тесты)

Планирование выпуска (план тестирования)

Для каждой итерации

Операции гибкого тестирования во время итерации

Регрессионное тестирование

Действия по выпуску (связанные тесты)

Операции гибкого тестирования во время итерации включают в себя:

• Участие в итерационном планировании
• Оценка задач с точки зрения тестирования
• Написание тестовых случаев с использованием описаний функций
• Модульное тестирование
• Интеграционное тестирование
• Тестирование функций
• Исправление дефектов
• Интеграционное тестирование
• Приемочное тестирование
• Отчет о состоянии процесса тестирования
• Отслеживание дефектов

Agile Testing — Методологии

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

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

Непрерывная интеграция, постоянное качество

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

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

Agile методологии

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

Scrum

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

XP

Программирование eXtreme ориентировано на клиента и ориентировано на постоянно меняющиеся требования. С частыми выпусками и отзывами клиентов, конечный продукт будет иметь качество, отвечающее требованиям клиентов, которые становятся понятнее в процессе.

кристалл

Кристалл основан на фрахтовании, циклической доставке и упаковке.

• Фрахтование включает в себя формирование команды разработчиков, проведение предварительного технико-экономического обоснования, составление первоначального плана и методологии разработки.

• Циклическая доставка с двумя или более циклами доставки фокусируется на этапе разработки и окончательной комплексной доставки продукта.

• Во время завершения работы выполняется развертывание в пользовательской среде, анализ и анализ после развертывания.

Фрахтование включает в себя формирование команды разработчиков, проведение предварительного технико-экономического обоснования, составление первоначального плана и методологии разработки.

Циклическая доставка с двумя или более циклами доставки фокусируется на этапе разработки и окончательной комплексной доставки продукта.

Во время завершения работы выполняется развертывание в пользовательской среде, анализ и анализ после развертывания.

FDD

Feature Driven Development (FDD) включает в себя проектирование и сборку элементов. Разница между FDD и другими методологиями гибкой разработки заключается в том, что функции разрабатываются отдельно и на коротких этапах.

DSDM

Метод динамической разработки программного обеспечения (DSDM) основан на быстрой разработке приложений (RAD) и соответствует Agile Framework. DSDM фокусируется на частой поставке продукта, активно вовлекая пользователей и давая возможность командам быстро принимать решения.

Бережливая разработка программного обеспечения

В Lean Software Development основное внимание уделяется устранению потерь и повышению ценности для клиента. Это приводит к быстрому развитию и продукту ценности.

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

Бережливые принципы —

• Ликвидировать отходы
• Усиление обучения
• Задержка обязательств
• Расширение возможностей команды
• Доставить быстро
• Создать целостность в
• Увидеть весь

Kanban

Kanban сосредотачивается на управлении работой с акцентом на своевременную доставку (JIT), не перегружая членов команды. Задачи отображаются для просмотра всеми участниками, а члены команды — для извлечения работы из очереди.

Канбан основан на —

• Канбан Правление (Визуальный и Постоянный через Развитие)
• Предел незавершенного производства (WIP)
• Время выполнения заказа

Методики гибкого тестирования

Методы тестирования четко определены для каждого проекта, будь то Agile или нет, для предоставления качественных продуктов. Традиционные принципы тестирования довольно часто используются в Agile Testing. Одним из них является Раннее тестирование, которое фокусируется на —

• Написание тестовых случаев для выражения поведения системы.

• Ранняя профилактика, обнаружение и устранение дефектов.

• Обеспечение того, чтобы правильные типы тестов выполнялись в нужное время и как часть правильного уровня тестирования.

Написание тестовых случаев для выражения поведения системы.

Ранняя профилактика, обнаружение и устранение дефектов.

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

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

В этом уроке мы сосредоточимся на Scrum как на методологии Agile-тестирования.

Другие обычно используемые методики тестирования Agile —

• Разработка через тестирование (TDD) — Разработка через тестирование (TDD) основана на кодировании, основанном на тестах.

• Разработка на основе приемочных испытаний (ATDD) — Разработка на основе приемочных испытаний (ATDD) основана на коммуникации между заказчиками, разработчиками и тестировщиками и основана на заранее определенных критериях приемки и приемочных тестах.

• Разработка на основе поведения (BDD). В разработке на основе поведения (BDD) тестирование основывается на ожидаемом поведении разрабатываемого программного обеспечения.

Разработка через тестирование (TDD) — Разработка через тестирование (TDD) основана на кодировании, основанном на тестах.

Разработка на основе приемочных испытаний (ATDD) — Разработка на основе приемочных испытаний (ATDD) основана на коммуникации между заказчиками, разработчиками и тестировщиками и основана на заранее определенных критериях приемки и приемочных тестах.

Разработка на основе поведения (BDD). В разработке на основе поведения (BDD) тестирование основывается на ожидаемом поведении разрабатываемого программного обеспечения.

Agile Testing Lifecycle

В Scrum тестирование включает в себя:

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

• Планирование выпуска, основанное на усилиях по тестированию и дефектах

• Планирование спринта на основе пользовательских историй и дефектов

• Выполнение спринта с непрерывным тестированием

• Регрессионное тестирование после завершения спринта

• Отчет о результатах теста

• Автоматизация тестирования

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

Планирование выпуска, основанное на усилиях по тестированию и дефектах

Планирование спринта на основе пользовательских историй и дефектов

Выполнение спринта с непрерывным тестированием

Регрессионное тестирование после завершения спринта

Отчет о результатах теста

Автоматизация тестирования

Тестирование является итеративным и основано на спринтах, как показано на диаграмме, приведенной ниже —

Agile Testing — тестер в команде

Agile Development ориентирована на команду, и разработчики и тестировщики принимают участие во всех проектах и ​​разработках. Командная работа максимизирует успех тестирования в Agile проектах.

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

Проворный тестировщик должен иметь традиционные навыки тестирования. Кроме того, Agile Tester нуждается в:

• Хорошие навыки межличностного общения.

• Способность действовать позитивно и ориентированно на решение с членами команды и заинтересованными сторонами.

• Способность показывать критическое, ориентированное на качество, скептическое мышление о продукте.

• Способность быть активным, чтобы активно получать информацию от заинтересованных сторон.

• Умение эффективно работать с клиентами и заинтересованными сторонами в определении тестируемых пользовательских историй, критериев принятия.

• Талант быть хорошим членом команды, работающей с разработчиками в создании качественного кода.

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

• Способность оценивать и сообщать о результатах испытаний, ходе испытаний и качестве продукции.

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

• Потенциал для самоорганизации работы.

• Энтузиазм к постоянному росту навыков.

• Компетентность в автоматизации тестирования, разработке на основе тестов (TDD), разработке на основе приемочных тестов (ATDD), разработке на основе поведения (BDD) и тестировании на основе опыта.

Хорошие навыки межличностного общения.

Способность действовать позитивно и ориентированно на решение с членами команды и заинтересованными сторонами.

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

Способность быть активным, чтобы активно получать информацию от заинтересованных сторон.

Умение эффективно работать с клиентами и заинтересованными сторонами в определении тестируемых пользовательских историй, критериев принятия.

Талант быть хорошим членом команды, работающей с разработчиками в создании качественного кода.

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

Способность оценивать и сообщать о результатах испытаний, ходе испытаний и качестве продукции.

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

Потенциал для самоорганизации работы.

Энтузиазм к постоянному росту навыков.

Компетентность в автоматизации тестирования, разработке на основе тестов (TDD), разработке на основе приемочных тестов (ATDD), разработке на основе поведения (BDD) и тестировании на основе опыта.

Роль тестера в Agile Team

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

Деятельность Agile Tester включает в себя —

• Обеспечение правильного использования инструментов тестирования.

• Конфигурирование, использование и управление тестовыми средами и тестовыми данными.

• Менторство других членов команды в соответствующих аспектах тестирования.

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

• Понимание, внедрение и обновление тестовой стратегии.

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

• Выполнение правильных тестов в нужное время и на правильных тестовых уровнях.

• Отчетность о дефектах и ​​работа с командой по их устранению.

• Измерение и составление отчета о тестовом покрытии по всем применимым параметрам покрытия

• Участие в ретроспективах спринта, активное предложение и внедрение улучшений.

Обеспечение правильного использования инструментов тестирования.

Конфигурирование, использование и управление тестовыми средами и тестовыми данными.

Менторство других членов команды в соответствующих аспектах тестирования.

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

Понимание, внедрение и обновление тестовой стратегии.

Сотрудничество с разработчиками, заказчиками и заинтересованными сторонами в уточнении требований с точки зрения тестируемости, согласованности и полноты.

Выполнение правильных тестов в нужное время и на правильных тестовых уровнях.

Отчетность о дефектах и ​​работа с командой по их устранению.

Измерение и составление отчета о тестовом покрытии по всем применимым параметрам покрытия

Участие в ретроспективах спринта, активное предложение и внедрение улучшений.

В Agile Lifecycle тестер играет важную роль в —

• Работа в команде
• Планирование испытаний
• Спринт Ноль
• интеграция
• Методы гибкого тестирования

Работа в команде

В Agile Development командная работа является фундаментальной и, следовательно, требует следующего:

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

• Самоорганизация — Планирование и организация в рамках спринтов для достижения целей тестирования путем объединения опыта других членов команды.

• Расширение возможностей — принятие соответствующих технических решений в достижении целей команды.

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

• Прозрачный — открытый, общительный и подотчетный.

• Достоверность — обеспечение достоверности стратегии тестирования, ее реализации и выполнения. Информирование клиентов и заинтересованных сторон о стратегии тестирования.

• Открыто для обратной связи — участие в ретроспективах спринта, чтобы учиться на успехах и неудачах. Ищите отзывы клиентов и действуйте быстро и надлежащим образом для обеспечения качественных результатов.

• Эластичный — реагирует на изменения.

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

Самоорганизация — Планирование и организация в рамках спринтов для достижения целей тестирования путем объединения опыта других членов команды.

Расширение возможностей — принятие соответствующих технических решений в достижении целей команды.

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

Прозрачный — открытый, общительный и подотчетный.

Достоверность — обеспечение достоверности стратегии тестирования, ее реализации и выполнения. Информирование клиентов и заинтересованных сторон о стратегии тестирования.

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

Эластичный — реагирует на изменения.

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

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

• Определение объема тестирования, степени тестирования, целей тестирования и спринта.

• Выбор среды тестирования, инструментов тестирования, данных тестирования и конфигураций.

• Назначение тестирования функций и характеристик.

• Планирование тестовых заданий и определение частоты тестов.

• Определение методов испытаний, методов, инструментов и данных испытаний.

• Определение предпосылок, таких как задачи предшественника, экспертиза и обучение.

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

• Установление приоритетов с учетом важности и зависимости клиента / пользователя.

• Прибытие в срок и усилия, необходимые для тестирования.

• Определение задач на каждом спринте.

Определение объема тестирования, степени тестирования, целей тестирования и спринта.

Выбор среды тестирования, инструментов тестирования, данных тестирования и конфигураций.

Назначение тестирования функций и характеристик.

Планирование тестовых заданий и определение частоты тестов.

Определение методов испытаний, методов, инструментов и данных испытаний.

Определение предпосылок, таких как задачи предшественника, экспертиза и обучение.

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

Установление приоритетов с учетом важности и зависимости клиента / пользователя.

Прибытие в срок и усилия, необходимые для тестирования.

Определение задач на каждом спринте.

Спринт Ноль

Спринт Ноль включает в себя подготовительные мероприятия перед первым спринтом. Тестировщик должен сотрудничать с командой в следующих действиях:

• Определение объема
• Разделение пользовательских историй на спринты
• Создание архитектуры системы
• Планирование, приобретение и установка инструментов (включая инструменты тестирования)
• Создание начальной стратегии тестирования для всех уровней тестирования
• Определение тестовых показателей
• Указание критериев приемки, также называемое определением «Готово»
• Определение критериев выхода
• Создание Scrum-доски
• Установка направления для тестирования на протяжении всего спринта

интеграция

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

Для этого тестеру необходимо:

• Понять стратегию интеграции.
• Определите все зависимости между функциями и функциями.

Методы гибкого тестирования

Agile-тестер должен адаптировать Agile-методы для тестирования в Agile-проекте.

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

  • Один тестер и один разработчик

  • Один тестер и один бизнес-аналитик

  • Два тестера

• Инкрементальный дизайн тестов. Тестовые наборы создаются на основе пользовательских историй, начиная с простых тестов и заканчивая более сложными тестами.

• Mind Mapping — Mind Map — это схема, позволяющая визуально организовать информацию. Mind Mapping можно использовать в качестве эффективного инструмента Agile-тестирования, с помощью которого можно организовать информацию, касающуюся необходимых сеансов тестирования, стратегий тестирования и данных тестирования.

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

Один тестер и один разработчик

Один тестер и один бизнес-аналитик

Два тестера

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

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

Agile Testing — Отслеживание деятельности

Статус теста можно сообщить —

• Во время ежедневных встреч
• Использование стандартных инструментов управления тестами
• Через мессенджеров

Состояние теста, определяемое состоянием прохождения теста, имеет решающее значение при решении вопроса о том, «выполнена» ли задача. Выполнено означает, что все тесты для выполнения задачи пройдены.

Прогресс теста

Прогресс теста можно отслеживать с помощью —

• Скрам Доски (Agile Task Boards)
• Графики Burndown
• Автоматизированные результаты испытаний

Test Progress также оказывает непосредственное влияние на ход разработки. Это связано с тем, что пользовательскую историю можно перевести в состояние « Готово» только после достижения критериев принятия. Это, в свою очередь, определяется статусом теста, а критерии приемки — статусом теста.

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

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

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

Качество продукта

Метрики качества продукции включают в себя —

• Тесты пройдены / не пройдены
• Дефекты найдены / исправлены
• Тестовое покрытие
• Test Pass / Fail Rates
• Скорость обнаружения дефектов
• Плотность дефектов

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

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

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

Ключевые факторы успеха

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

Следующие пункты должны быть рассмотрены для успеха Agile тестирования —

• Гибкое тестирование основано на тестировании в первую очередь и непрерывном тестировании. Следовательно, традиционные инструменты тестирования, основанные на подходе «последний тест», могут не подходить. Следовательно, при выборе средств тестирования в Agile проектах необходимо проверить соответствие тестированию Agile.

• Сократите общее время тестирования за счет автоматизации тестов на ранних этапах жизненного цикла разработки.

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

• Ручное тестирование составляет до 80% тестирования в проектах. Следовательно, тестеры с опытом должны быть частью Agile команды.

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

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

  • Определение критериев приемлемости на уровне истории пользователя / задачи согласно ожиданиям клиентов.

  • Оценка усилий и продолжительности испытаний.

  • Планирование работ по тестированию.

  • Сотрудничество с командой разработчиков для обеспечения производства кода, соответствующего требованиям, с предварительным дизайном тестирования.

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

  • Обеспечение тестирования на всех уровнях в спринте.

  • Регрессионное тестирование в конце каждого спринта.

  • Сбор и анализ метрик продукта, которые полезны для успеха проекта.

  • Анализ дефектов позволяет определить, какие из них необходимо исправить в текущем спринте, а какие можно отложить до последующих спринтов.

  • Ориентация на то, что важно с точки зрения Заказчика.

Гибкое тестирование основано на тестировании в первую очередь и непрерывном тестировании. Следовательно, традиционные инструменты тестирования, основанные на подходе «последний тест», могут не подходить. Следовательно, при выборе средств тестирования в Agile проектах необходимо проверить соответствие тестированию Agile.

Сократите общее время тестирования за счет автоматизации тестов на ранних этапах жизненного цикла разработки.

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

Ручное тестирование составляет до 80% тестирования в проектах. Следовательно, тестеры с опытом должны быть частью Agile команды.

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

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

Определение критериев приемлемости на уровне истории пользователя / задачи согласно ожиданиям клиентов.

Оценка усилий и продолжительности испытаний.

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

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

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

Обеспечение тестирования на всех уровнях в спринте.

Регрессионное тестирование в конце каждого спринта.

Сбор и анализ метрик продукта, которые полезны для успеха проекта.

Анализ дефектов позволяет определить, какие из них необходимо исправить в текущем спринте, а какие можно отложить до последующих спринтов.

Ориентация на то, что важно с точки зрения Заказчика.

Лиза Криспин определила семь ключевых факторов успеха Agile-тестирования —

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

• Agile Testing Mindset — тестировщики активно улучшают качество и постоянно сотрудничают с остальной командой.

• Автоматизированное регрессионное тестирование — Дизайн для тестируемости и разработки дисков с тестами. Начните с простого и позвольте команде выбрать инструменты. Будьте готовы дать совет.

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

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

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

• Посмотрите на общую картину — стимулируйте разработку с помощью бизнес-тестов и примеров с использованием реальных данных испытаний и размышлений о воздействии на другие области.

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

Agile Testing Mindset — тестировщики активно улучшают качество и постоянно сотрудничают с остальной командой.

Автоматизированное регрессионное тестирование — Дизайн для тестируемости и разработки дисков с тестами. Начните с простого и позвольте команде выбрать инструменты. Будьте готовы дать совет.

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

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

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

Посмотрите на общую картину — стимулируйте разработку с помощью бизнес-тестов и примеров с использованием реальных данных испытаний и размышлений о воздействии на другие области.

Agile Testing — Значимые атрибуты

В этой главе мы увидим некоторые важные атрибуты Agile Testing.

Преимущества гибкого тестирования

Преимущества Agile тестирования —

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

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

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

• Проворные тестеры участвуют в оценке, оценивая усилия и время тестирования.

• Дизайн ранних испытаний, отражающий критерии приемки.

• Требования к тестированию консолидированы всей командой, избегая недостатков.

• Постоянное внимание всей команды уделяется качеству продукта.

• Определение статуса « Готово», отражающее прохождение тестов, гарантирует выполнение требования.

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

• Быстрое реагирование на изменяющиеся требования и их быстрое решение.

• Регрессивное тестирование на основе непрерывной интеграции.

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

• Автоматизированное тестирование реализовано на ранних этапах жизненного цикла разработки, что сокращает общее время и усилия на тестирование.

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

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

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

Проворные тестеры участвуют в оценке, оценивая усилия и время тестирования.

Дизайн ранних испытаний, отражающий критерии приемки.

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

Постоянное внимание всей команды уделяется качеству продукта.

Определение статуса « Готово», отражающее прохождение тестов, гарантирует выполнение требования.

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

Быстрое реагирование на изменяющиеся требования и их быстрое решение.

Регрессивное тестирование на основе непрерывной интеграции.

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

Автоматизированное тестирование реализовано на ранних этапах жизненного цикла разработки, что сокращает общее время и усилия на тестирование.

Лучшие практики гибкого тестирования

Следуйте лучшим практикам, приведенным ниже —

• Включение тестеров с опытом во всех видах тестирования на всех уровнях.

• Тестировщики участвуют в определении требований, сотрудничая с заказчиками в отношении ожидаемого поведения продукта.

• Тестеры постоянно делятся отзывами с разработчиками и заказчиками.

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

• Отслеживание статуса тестирования и прогресса тестирования быстро и постоянно с акцентом на поставку качественного продукта.

• Автоматизация тестирования в начале жизненного цикла разработки для сокращения времени цикла.

• Для проведения регрессионного тестирования используйте автоматизированное тестирование как эффективный способ.

Включение тестеров с опытом во всех видах тестирования на всех уровнях.

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

Тестеры постоянно делятся отзывами с разработчиками и заказчиками.

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

Отслеживание статуса тестирования и прогресса тестирования быстро и постоянно с акцентом на поставку качественного продукта.

Автоматизация тестирования в начале жизненного цикла разработки для сокращения времени цикла.

Для проведения регрессионного тестирования используйте автоматизированное тестирование как эффективный способ.

Проблемы в гибком тестировании

В Agile тестировании существуют следующие проблемы:

• Непонимание Agile-подхода и его ограничений со стороны бизнеса и менеджмента может привести к недостижимым ожиданиям.

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

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

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

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

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

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

Непонимание Agile-подхода и его ограничений со стороны бизнеса и менеджмента может привести к недостижимым ожиданиям.

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

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

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

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

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

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

Руководство по гибкому тестированию

При выполнении Agile-тестирования используйте следующие рекомендации.

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

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

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

• Примите участие в каждом совещании по планированию спринта, чтобы понять объем и обновить план тестирования.

• Непрерывно сотрудничайте с командой разработчиков во время Sprint, чтобы сделать тестирование и кодирование успешными в рамках Sprint.

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

• Регулярно отслеживайте и сообщайте о состоянии испытаний, ходе испытаний и качестве продукции.

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

• Участвуйте в Ретроспективах Спринта, чтобы понять и поделиться передовым опытом и извлеченными уроками.

• Сотрудничать в получении отзывов клиентов на каждом спринте.

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

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

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

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

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

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

Регулярно отслеживайте и сообщайте о состоянии испытаний, ходе испытаний и качестве продукции.

Будьте готовы принять изменения, отвечая изменениями в тестовых случаях, тестовых данных.

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

Сотрудничать в получении отзывов клиентов на каждом спринте.

Agile Testing — Квадранты

Как и в случае традиционного тестирования, гибкое тестирование также должно охватывать все уровни тестирования.

• Модульное тестирование
• Интеграционное тестирование
• Тестирование системы
• Пользовательское тестирование

Модульное тестирование

• Сделано вместе с кодированием, разработчиком
• При поддержке Tester, который пишет тестовые сценарии, обеспечивающие 100% покрытие проекта
• Случаи модульного тестирования и результаты модульного тестирования необходимо пересмотреть
• Неразрешенные серьезные дефекты (по приоритету и серьезности) не остаются
• Все юнит-тесты автоматизированы

Интеграционное тестирование

• Сделано вместе с непрерывной интеграцией по мере продвижения спринтов
• Готово в конце после завершения всех спринтов
• Все функциональные требования проверены
• Все интерфейсы между блоками проверены
• О всех дефектах сообщается
• Тесты автоматизированы, где это возможно

Тестирование системы

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

Пользовательское тестирование

• Сделано в конце каждого спринта и в конце проекта

• Сделано Заказчиком. Обратная связь принимается командой

• Обратная связь будет входом в последующие спринты

• Пользовательские истории в спринте предварительно проверяются на возможность тестирования и имеют определенные критерии приемки

Сделано в конце каждого спринта и в конце проекта

Сделано Заказчиком. Обратная связь принимается командой

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

Пользовательские истории в спринте предварительно проверяются на возможность тестирования и имеют определенные критерии приемки

Типы испытаний

• Тестирование компонентов (модульные тесты)
• Функциональные тесты (тесты пользовательских историй)
• Нефункциональные тесты (производительность, нагрузка, стресс и т. Д.)
• Приемочные испытания

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

Поддержка программирования и критических тестов продукта

Тесты могут быть для —

• Поддержка разработки (Support Programming) — Программисты поддерживают тесты программирования.

  • Чтобы решить, какой код они должны написать, чтобы выполнить определенное поведение системы

  • Какие тесты необходимо выполнить после кодирования, чтобы новый код не препятствовал остальному поведению системы

• Только проверка (продукт Critique) — тесты продукта Critique используются для выявления недостатков в готовом продукте

Поддержка разработки (Support Programming) — Программисты поддерживают тесты программирования.

Чтобы решить, какой код они должны написать, чтобы выполнить определенное поведение системы

Какие тесты необходимо выполнить после кодирования, чтобы новый код не препятствовал остальному поведению системы

Только проверка (продукт Critique) — тесты продукта Critique используются для выявления недостатков в готовом продукте

Деловые и технологические испытания

Чтобы решить, какие тесты следует выполнять, когда вам нужно определить, является ли тест:

• Бизнес, или
• Облицовка технологий

Бизнес-тесты

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

Передовые технологии

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

Эти два аспекта типов тестов можно просмотреть с помощью Agile Quadrants Testing, определенных Брайаном Мариком.

Agile Testing Quadrants

Объединяя два аспекта типов тестирования, Брайан Марик получил следующие квадранты гибкого тестирования:

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

• Квадрант Q1 — Unit Level, Technology Facing, и поддерживает разработчиков. Модульные тесты принадлежат этому квадранту. Эти тесты могут быть автоматизированными тестами.

• Квадрант Q2 — Системный уровень, отношение к бизнесу и соответствие поведения продукта. Функциональные тесты относятся к этому квадранту. Эти тесты либо ручные, либо автоматизированные.

• Квадрант Q3 — уровень приемлемости системы или пользователя, бизнес-ориентация и ориентация на сценарии в реальном времени. Пользовательские приемочные тесты принадлежат этому квадранту. Эти тесты являются ручными.

• Квадрант Q4 — уровень приемлемости системы или эксплуатации, технологический анализ и тестирование производительности, нагрузки, стресса, ремонтопригодности, масштабируемости. Для этих испытаний могут использоваться специальные инструменты, а также тестирование автоматизации.

Квадрант Q1 — Unit Level, Technology Facing, и поддерживает разработчиков. Модульные тесты принадлежат этому квадранту. Эти тесты могут быть автоматизированными тестами.

Квадрант Q2 — Системный уровень, отношение к бизнесу и соответствие поведения продукта. Функциональные тесты относятся к этому квадранту. Эти тесты либо ручные, либо автоматизированные.

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

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

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

Agile Testing — Scrum

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

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

Совместное создание пользовательских историй

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

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

Тестировщики способствуют созданию тестируемых пользовательских историй.

Планирование релиза

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

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

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

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

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

Тестеры должны —

• Определить тестируемость пользовательских историй, выбранных для спринта
• Создать приемочные тесты
• Определить тестовые уровни
• Определить автоматизацию тестирования

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

Тестовый анализ

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

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

Все члены команды Scrum должны участвовать в тестировании.

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

• Тестеры выполняют функциональные и нефункциональные функции пользовательских историй.

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

• В конце спринта клиент и / или конечные пользователи проводят приемочное тестирование пользователя и предоставляют обратную связь команде разработчиков. Это формирует как вход к следующему спринту.

• Результаты испытаний собраны и поддерживаются.

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

Тестеры выполняют функциональные и нефункциональные функции пользовательских историй.

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

В конце спринта клиент и / или конечные пользователи проводят приемочное тестирование пользователя и предоставляют обратную связь команде разработчиков. Это формирует как вход к следующему спринту.

Результаты испытаний собраны и поддерживаются.

Автоматизация тестирования

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

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

Автоматизация тестовой деятельности

Автоматизация процессов тестирования снижает нагрузку на повторную работу и приводит к экономии средств. автоматизировать

• Генерация тестовых данных
• Загрузка тестовых данных
• Построить развертывание в тестовой среде
• Управление тестовой средой
• Сравнение вывода данных

Регрессионное тестирование

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

Управление конфигурацией

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

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

Методы гибкого тестирования

Тестеры в Scrum Team могут следовать следующим Agile практикам —

• Соединение — два члена команды сидят вместе и работают вместе. Два человека могут быть двумя тестерами или одним тестером и одним разработчиком.

• Инкрементальный дизайн теста — тестовые случаи разрабатываются по мере постепенного развития спринта и добавления пользовательских историй.

Соединение — два члена команды сидят вместе и работают вместе. Два человека могут быть двумя тестерами или одним тестером и одним разработчиком.

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

Agile Metrics

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

Для разработки Scrum предлагается несколько метрик. Значимые показатели —

• Соотношение успешных спринтов — (количество успешных спринтов / общее количество спринтов) * 100 . Успешный спринт — это тот, в котором команда может выполнить свои обязательства.

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

• Фактор фокуса — (скорость / работоспособность команды) / 100 . Фактор фокуса — это процент усилий команды, который приводит к законченным историям.

• Точность оценки — (Расчетное усилие / Фактическое усилие) / 100 . Точность оценки — это способность команды точно оценивать усилия.

• Спринт Burndown — работа (в пунктах истории или в часах), которая остается против. Работа, которая должна оставаться в идеале (согласно оценке).

  • Если это больше, то это означает, что команда взяла на себя больше работы, чем они могут сделать.

  • Если оно меньше, значит, команда не оценила точно.

• Количество дефектов — количество дефектов в спринте. Количество дефектов — это количество дефектов в программном обеспечении по сравнению с отставанием.

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

Соотношение успешных спринтов — (количество успешных спринтов / общее количество спринтов) * 100 . Успешный спринт — это тот, в котором команда может выполнить свои обязательства.

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

Фактор фокуса — (скорость / работоспособность команды) / 100 . Фактор фокуса — это процент усилий команды, который приводит к законченным историям.

Точность оценки — (Расчетное усилие / Фактическое усилие) / 100 . Точность оценки — это способность команды точно оценивать усилия.

Спринт Burndown — работа (в пунктах истории или в часах), которая остается против. Работа, которая должна оставаться в идеале (согласно оценке).

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

Если оно меньше, значит, команда не оценила точно.

Количество дефектов — количество дефектов в спринте. Количество дефектов — это количество дефектов в программном обеспечении по сравнению с отставанием.

Серьезность Дефектов — Дефекты могут быть классифицированы как незначительные, основные и критические по степени их серьезности. Тестеры могут определять категоризацию.

Спринт Ретроспективы

В Ретроспективе Спринта будут участвовать все члены команды. Они делятся —

• Вещи, которые шли хорошо
• метрика
• Возможности для улучшений
• Элементы действий для применения

Agile Тестирование — Методы

В Agile Testing обычно используются методы тестирования, основанные на традиционных методах и основанные на принципе — Test Early. Тестовые случаи пишутся до написания кода. Основное внимание уделяется предотвращению, обнаружению и устранению дефектов, при проведении правильных типов испытаний в нужное время и на нужном уровне.

В этой главе вы получите представление о методах —

• Разработка через тестирование (TDD)
• Acceptance Test Driven Development (ATDD)
• Развитие, управляемое поведением (BDD)

Разработка через тестирование

В методе Test Driven Development (TDD) код разрабатывается на основе подхода Testfirst, направленного автоматизированными тестовыми примерами. Вначале написано, что тест не пройден, на основе этого разрабатывается код, обеспечивающий прохождение теста. Метод повторяется, рефакторинг осуществляется посредством разработки кода.

TDD можно понять с помощью следующих шагов —

• Шаг 1 — Напишите контрольный пример, чтобы отразить ожидаемое поведение функциональности кода, который должен быть написан.

• Шаг 2 — Запустите тест. Тест не пройден, так как код еще не разработан.

• Шаг 3 — Разработка кода на основе тестового примера.

• Шаг 4 — Запустите тест снова. На этот раз тест должен пройти, поскольку функциональность закодирована. Повторите шаг (3) и шаг (4), пока тест не пройдет.

• Шаг 5 — Рефакторинг кода.

• Шаг 6 — Запустите тест снова, чтобы убедиться, что он прошел.

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

Шаг 2 — Запустите тест. Тест не пройден, так как код еще не разработан.

Шаг 3 — Разработка кода на основе тестового примера.

Шаг 4 — Запустите тест снова. На этот раз тест должен пройти, поскольку функциональность закодирована. Повторите шаг (3) и шаг (4), пока тест не пройдет.

Шаг 5 — Рефакторинг кода.

Шаг 6 — Запустите тест снова, чтобы убедиться, что он прошел.

Повторите Шаг 1 — Шаг 6, добавив контрольные примеры для добавления функциональности. Добавленные тесты и более ранние тесты запускаются каждый раз, чтобы гарантировать, что код работает должным образом. Чтобы сделать этот процесс быстрым, тесты автоматизированы.

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

Acceptance Test Driven Development

В методе Acceptance Test Driven Development (ATDD) код разрабатывается на основе подхода, основанного на первых тестах, на основе сценариев приемочных испытаний. Основное внимание уделяется критериям приемки и Приемочным тестам, написанным тестировщиками во время создания пользовательской истории в сотрудничестве с заказчиком, конечными пользователями и соответствующими заинтересованными сторонами.

• Шаг 1 — Напишите примеры приемочных испытаний вместе с пользовательскими историями в сотрудничестве с заказчиком и пользователями.

• Шаг 2 — Определите соответствующие критерии приемки.

• Шаг 3 — Разработка кода на основе приемочных испытаний и критериев приемки.

• Шаг 4 — Запустите приемочные тесты, чтобы убедиться, что код работает должным образом.

• Шаг 5 — Автоматизация приемочных испытаний. Повторите Шаг 3 — Шаг 5, пока все пользовательские истории в итерации не будут реализованы.

• Шаг 6 — Автоматизация регрессионных тестов.

• Шаг 7 — Запустите автоматизированные регрессионные тесты, чтобы обеспечить непрерывную регрессию.

Шаг 1 — Напишите примеры приемочных испытаний вместе с пользовательскими историями в сотрудничестве с заказчиком и пользователями.

Шаг 2 — Определите соответствующие критерии приемки.

Шаг 3 — Разработка кода на основе приемочных испытаний и критериев приемки.

Шаг 4 — Запустите приемочные тесты, чтобы убедиться, что код работает должным образом.

Шаг 5 — Автоматизация приемочных испытаний. Повторите Шаг 3 — Шаг 5, пока все пользовательские истории в итерации не будут реализованы.

Шаг 6 — Автоматизация регрессионных тестов.

Шаг 7 — Запустите автоматизированные регрессионные тесты, чтобы обеспечить непрерывную регрессию.

Развитие, управляемое поведением (BDD)

Разработка на основе поведения (BDD) аналогична разработке на основе тестирования (TDD), и основное внимание уделяется тестированию кода для обеспечения ожидаемого поведения системы.

В BDD используется такой язык, как английский, чтобы он имел смысл для пользователей, тестеров и разработчиков. Это обеспечивает —

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

Agile Тестирование — Методы

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

Тестовая Основа

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

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

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

Определение Готово

Определение выполненного (DoD) — это критерий, который используется в Agile проектах для обеспечения выполнения операции в журнале ожидания Sprint. DoD может варьироваться от одной команды Scrum к другой, но она должна быть согласованной в пределах одной команды.

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

Типичный DoD для пользовательской истории может содержать —

• Подробные тестируемые критерии приемки
• Критерии обеспечения согласованности пользовательской истории с другими в итерации
• Особые критерии, связанные с продуктом
• Функциональные аспекты поведения
• Нефункциональные характеристики
• Интерфейсы
• Требования к данным испытаний
• Тестовое покрытие
• Рефакторинг
• Требования к рассмотрению и утверждению

В дополнение к DoD для пользовательских историй, DoD также требуется —

• на каждом уровне тестирования
• для каждой функции
• для каждой итерации
• для выпуска

Тестовая информация

Тестер должен иметь следующую информацию о тестировании —

• Пользовательские истории, которые необходимо протестировать
• Соответствующие критерии приемки
• Системные интерфейсы
• Среда, в которой система должна работать
• Наличие инструментов
• Тестовое покрытие
• DoD

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

• Получать необходимую информацию о тестировании на постоянной основе.
• Определите информационные пробелы, которые влияют на тестирование.
• Устраните недостатки совместно с другими членами команды.
• Решите, когда будет достигнут тестовый уровень.
• Убедитесь, что соответствующие тесты выполнены в соответствующее время.

Функциональный и нефункциональный дизайн теста

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

Для разработки функциональных тестов тестировщики и разработчики могут использовать традиционные методы разработки тестов Black Box, такие как —

• Эквивалентное разбиение
• Анализ граничных значений
• Таблицы решений
• Государственный переход
• Дерево классов

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

Исследовательское тестирование

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

Исследовательское тестирование (ET) определяется как одновременное обучение, разработка теста и выполнение теста. В исследовательском тестировании тестер активно контролирует структуру тестов по мере их выполнения и использует информацию, полученную в ходе тестирования, для разработки новых и более качественных тестов.

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

Риск-тестирование

Риск-тестирование — это тестирование, основанное на риске сбоев, которое снижает риски с помощью методов разработки тестов.

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

• Функциональные риски
• Нефункциональные риски производительности
• Нефункциональные риски юзабилити

Анализ риска должен быть сделан, чтобы оценить вероятность (вероятность) и влияние каждого риска. Затем риски расставлены по приоритетам —

• Высокие риски требуют обширного тестирования
• Низкие риски требуют только краткого тестирования

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

Fit тесты

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

FIT использует JUnit, но расширяет функциональность тестирования. Таблицы HTML используются для отображения тестовых случаев. Fixture — это класс Java, стоящий за таблицей HTML. Приспособление берет содержимое таблицы HTML и запускает контрольные примеры для тестируемого проекта.

Agile Тестирование — Workproducts

План тестирования готовится во время планирования выпуска и пересматривается при каждом планировании спринта. План тестирования служит руководством к процессу тестирования для обеспечения полного охвата тестированием.

Типичное содержание плана испытаний —

• Тестовая стратегия
• Тестовая среда
• Тестовое покрытие
• Объем тестирования
• Испытание усилий и график
• Инструменты тестирования

В Agile Projects все члены команды несут ответственность за качество продукта. Следовательно, все участвуют в планировании испытаний.

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

Пользовательские истории

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

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

Ручные и автоматические тесты

Во время первого запуска тестирования используются ручные тесты. Они включают в себя —

• Модульные тесты
• Интеграционные тесты
• Функциональные тесты
• Нефункциональные тесты
• Приемочные испытания

Затем тесты автоматизируются для последующих запусков.

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

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

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

Во всех типах методов имеет место непрерывная интеграция, которая включает в себя непрерывное интеграционное тестирование.

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

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

Результаты теста

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

Также может быть подготовлено резюме теста, которое содержит:

• Область тестирования (Что было проверено, а что нет)
• Анализ дефектов вместе с анализом первопричин, если это возможно
• Состояние регрессионного тестирования после исправления дефекта
• Проблемы и соответствующее разрешение
• Нерешенные вопросы, если таковые имеются
• Любые изменения, необходимые в тестовой стратегии
• Тест Метрики

Отчеты о тестовых показателях

В Agile Projects тестовые метрики включают следующее для каждого спринта:

• Тест Усилие
• Точность оценки теста
• Тестовое покрытие
• Автоматическое тестовое покрытие
• Количество дефектов
• Коэффициент дефектов (количество дефектов на точку истории пользователя)
• Степень серьезности дефекта
• Время исправления дефекта в том же спринте (исправление ошибки, выходящей из текущего спринта, стоит в 24 раза дороже)
• Количество дефектов, зафиксированных в одном и том же спринте
• Завершение приемочных испытаний заказчиком в рамках спринта

Обзор спринта и ретроспективные отчеты

Тестировщики также участвуют в обзоре спринта и ретроспективных отчетах. Типичное содержание —

• Тест Метрики
• Результаты теста Журналы результатов проверки
• Что пошло правильно и что можно улучшить с точки зрения тестирования
• Лучшие практики
• Уроки выучены
• вопросы
• Обратная связь с клиентом

Agile Testing — Kanban

Agile Testing можно эффективно управлять с помощью концепций Kanban. Следующее гарантирует, что тестирование будет выполнено вовремя в течение итерации / спринта и, таким образом, сфокусировано на доставке качественного продукта.

• Пользовательские истории, которые можно тестировать и эффективно измерять, приводят к разработке и тестированию в указанные сроки.

• Предел WIP (Work-In-Progress) позволяет сосредоточиться на ограниченном количестве пользовательских историй одновременно.

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

• Концепция совместной работы команды Kanban позволяет без проблем находить узкие места по мере их выявления.

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

• Определение Done (DoD) называется «Done-Done» в том смысле, что Story достигает состояния завершения только после того, как тестирование также завершено.

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

Предел WIP (Work-In-Progress) позволяет сосредоточиться на ограниченном количестве пользовательских историй одновременно.

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

Концепция совместной работы команды Kanban позволяет без проблем находить узкие места по мере их выявления.

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

Определение Done (DoD) называется «Done-Done» в том смысле, что Story достигает состояния завершения только после того, как тестирование также завершено.

Тестирование деятельности в разработке продукта

В разработке продукта, релизы можно отслеживать с помощью функции Kanban Board. Функции для определенного выпуска назначаются на доску Feature Kanban, которая визуально отслеживает состояние разработки функции.

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

Следующие действия Agile Testing обеспечивают качественную доставку в каждом выпуске, а также в конце всех выпусков —

• Тестеры участвуют в создании пользовательской истории и таким образом обеспечивают —

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

  • Пользовательские истории тестируемы.

  • Размер пользовательских историй позволяет завершить разработку и тестирование (DoneDone) в течение итерации.

• Visual Task Kanban Board —

  • Описывает статус и ход выполнения задач.

  • Узкие места выявляются сразу по мере их появления

  • Облегчает измерение времени цикла, которое затем можно оптимизировать

• Коллективное сотрудничество помогает в —

  • Ответственность всей команды за качественный продукт

  • Устранение узких мест, как и когда они возникают, экономя время ожидания

  • Вклад каждой экспертизы во все виды деятельности

• Непрерывная интеграция, ориентированная на тестирование непрерывной интеграции

• Автоматизация тестов для экономии усилий и времени при тестировании

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

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

• Непрерывное тестирование по мере развития, чтобы гарантировать исправление дефектов внутри итерации —

  • Обеспечить тестовое покрытие

  • Сохраняйте количество открытых дефектов низким

Тестеры участвуют в создании пользовательской истории и таким образом обеспечивают —

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

Пользовательские истории тестируемы.

Размер пользовательских историй позволяет завершить разработку и тестирование (DoneDone) в течение итерации.

Visual Task Kanban Board —

Описывает статус и ход выполнения задач.

Узкие места выявляются сразу по мере их появления

Облегчает измерение времени цикла, которое затем можно оптимизировать

Коллективное сотрудничество помогает в —

Ответственность всей команды за качественный продукт

Устранение узких мест, как и когда они возникают, экономя время ожидания

Вклад каждой экспертизы во все виды деятельности

Непрерывная интеграция, ориентированная на тестирование непрерывной интеграции

Автоматизация тестов для экономии усилий и времени при тестировании

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

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

Непрерывное тестирование по мере развития, чтобы гарантировать исправление дефектов внутри итерации —

Обеспечить тестовое покрытие

Сохраняйте количество открытых дефектов низким

История исследования

Story Exploration — это коммуникация в Agile команде для изучения понимания Story, когда владелец продукта передает историю для принятия в разработку.

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

Завершение истории основано на постоянном и постоянном общении между владельцем продукта, разработчиками и тестерами.

Предварительный расчет

Оценка происходит в Планировании релиза и каждом Планировании итерации.

В Планировании релизов тестеры предоставляют:

• Информация о том, какие тестовые действия требуются
• Оценка усилий для того же

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

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

Следовательно, оценка теста играет важную роль в оценке истории.

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

Планирование истории начинается после того, как история была оценена и присвоена текущей итерации.

Планирование истории включает в себя следующие тестовые задания —

• Подготовить тестовые данные
• Продлить приемочные тесты
• Выполнить ручные тесты
• Провести сеансы поискового тестирования
• Автоматизируйте тесты непрерывной интеграции

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

• Тестирование производительности
• Регрессионное тестирование
• Обновления связанных тестов непрерывной интеграции

Прогресс истории

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

Непрерывное тестирование выполняется во время Story Progression и включает в себя непрерывное интеграционное тестирование. Вся команда участвует в тестировании.

Принятие истории

Принятие истории происходит, когда история достигает состояния Готово. то есть история разработана и проверена и передана как завершенная.

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

Agile Testing — Инструменты

В Agile Projects тестеры отвечают за следующие ежедневные задачи —

• Поддержка разработчиков в кодировании, с разъяснениями ожидаемого поведения системы.

• Помогите разработчикам в создании эффективных и действенных юнит-тестов.

• Разработка сценариев автоматизации.

• Интеграция средств / сценариев автоматизации тестирования с непрерывной интеграцией для регрессионного тестирования.

Поддержка разработчиков в кодировании, с разъяснениями ожидаемого поведения системы.

Помогите разработчикам в создании эффективных и действенных юнит-тестов.

Разработка сценариев автоматизации.

Интеграция средств / сценариев автоматизации тестирования с непрерывной интеграцией для регрессионного тестирования.

Для эффективной и быстрой реализации этих задач в большинстве проектов Agile используется система непрерывной интеграции (CI), которая поддерживает CI кода и тестовые компоненты.

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

Примечание. Решения для записи и воспроизведения, Test-Last, Heavyweight и Test Automation не являются гибкими, поскольку —

• Рабочий процесс test-last, поддерживаемый такими инструментами, не работает в Agile командах.

• Неуправляемые сценарии, созданные с помощью таких инструментов, становятся препятствием для изменения

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

Рабочий процесс test-last, поддерживаемый такими инструментами, не работает в Agile командах.

Неуправляемые сценарии, созданные с помощью таких инструментов, становятся препятствием для изменения

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

Инструменты, которые широко используются —

S.No.	Инструмент и цель
1	Гудзон CI Framework
2	Селен Функциональное тестирование — интегрировано с Hudson
3	Круиз-контроль CI Framework
4	Junit Модульный тест Java
5	Nunit .Net Unit Test
6	Cobertura / JavaCodeCoverage / JFeature / JCover / Тестирование Java
7	шут Java — тестирование мутаций / автоматическое заполнение ошибок
8	Гретель Инструмент мониторинга покрытия тестов Java
9	TestCocoon C / C ++ или C # — уменьшает количество тестов, находя избыточные тесты и находя мертвый код
10	ДЖАЗ Java — ветвление, узел и Defuse Coverage и реализует графический интерфейс, планировщики тестов, динамические инструменты и анализатор тестов
11	Муравей Java — Автоматизация сборки
12	Nant .Net — Автоматизация сборки
13	Костер Дополнение Agile Testing для JIRA

Гудзон

CI Framework

Селен

Функциональное тестирование — интегрировано с Hudson

Круиз-контроль

CI Framework

Junit

Модульный тест Java

Nunit

.Net Unit Test

Cobertura / JavaCodeCoverage / JFeature / JCover /

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

шут

Java — тестирование мутаций / автоматическое заполнение ошибок

Гретель

Инструмент мониторинга покрытия тестов Java

TestCocoon

C / C ++ или C # — уменьшает количество тестов, находя избыточные тесты и находя мертвый код

ДЖАЗ

Java — ветвление, узел и Defuse Coverage и реализует графический интерфейс, планировщики тестов, динамические инструменты и анализатор тестов

Муравей

Java — Автоматизация сборки

Nant

.Net — Автоматизация сборки

Костер

Дополнение Agile Testing для JIRA

Инструменты автоматизации тестирования Agile

Эффективная поддержка инструментов автоматизации тестирования Agile —

• Ранняя автоматизация тестирования с использованием подхода «сначала тест».

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

• Сосредоточение внимания на ожидаемое поведение системы.

• Отделение сущности теста от деталей реализации, что делает технологию независимой.

• Содействие сотрудничеству.

Ранняя автоматизация тестирования с использованием подхода «сначала тест».

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

Сосредоточение внимания на ожидаемое поведение системы.

Отделение сущности теста от деталей реализации, что делает технологию независимой.

Содействие сотрудничеству.

Автоматизированные модульные тесты (с использованием Junit или NUnit) поддерживают первый подход к тестированию для кодирования. Это тесты «белого ящика», которые гарантируют, что дизайн надежный и на нем нет дефектов. Такие тесты создаются разработчиками при поддержке тестировщиков и могут быть независимыми от требуемой функциональности. Это приводит к поставке продукта, который может не соответствовать требованиям клиента и, следовательно, не иметь никакой коммерческой ценности.

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

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

Гибкие инструменты и платформы, поддерживающие автоматическое приемочное тестирование, —

• Поместиться
• Fitnesse
• Concordion
• Рубин
• Огурец

Поместиться

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

• Клиенты или Владельцы продукта, чтобы привести примеры поведения продукта с использованием Microsoft Word и Microsoft Excel

• Программисты легко превращают эти примеры в автоматизированные тесты.

Клиенты или Владельцы продукта, чтобы привести примеры поведения продукта с использованием Microsoft Word и Microsoft Excel

Программисты легко превращают эти примеры в автоматизированные тесты.

Fit 1.1 поддерживает как Java, так и .NET.

FitNesse

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

В FitNesse автоматизация приемочных испытаний выглядит следующим образом:

• Экспресс-тесты в виде таблиц входных данных и ожидаемых выходных данных.

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

  • В качестве альтернативы, поместите тестовую таблицу в Microsoft Excel, скопируйте в буфер обмена и затем используйте команду Spreadsheet to FitNesse, чтобы FitNesse правильно отформатировал таблицу.

• Запустить тест

• Вы получаете результаты теста по цветовой кодировке ячеек в тестовой таблице

  • зеленые клетки показывают, что ожидаемые значения получены

  • эритроциты показывают, что получено значение, отличное от ожидаемого

  • желтые клетки представляют собой исключение

Экспресс-тесты в виде таблиц входных данных и ожидаемых выходных данных.

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

В качестве альтернативы, поместите тестовую таблицу в Microsoft Excel, скопируйте в буфер обмена и затем используйте команду Spreadsheet to FitNesse, чтобы FitNesse правильно отформатировал таблицу.

Запустить тест

Вы получаете результаты теста по цветовой кодировке ячеек в тестовой таблице

зеленые клетки показывают, что ожидаемые значения получены

эритроциты показывают, что получено значение, отличное от ожидаемого

желтые клетки представляют собой исключение

Огурец

Cucumber — это инструмент, основанный на платформе Behavior Driven Development (BDD). Ключевые особенности —

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

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

Был реализован в Ruby, а затем расширен до среды Java. Оба поддерживают Джунит.

Поддерживает другие языки, такие как Perl, PHP, Python, .Net и т. Д.

Может использоваться вместе с Селеном, Ватиром, Капибарой и т. Д.