Гибкое тестирование - Краткое руководство

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

Agile Manifesto

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

The Agile Manifesto is −

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

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

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

Что такое гибкое тестирование?

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

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

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

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

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

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

Ниже приведены основные различия между Agile Testing и Waterfall Testing.

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

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

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

Testing moves the project forward- Непрерывное тестирование - единственный способ обеспечить непрерывный прогресс. Agile Testing обеспечивает постоянную обратную связь, и конечный продукт соответствует требованиям бизнеса.
Testing is not a phase- Agile-команда тестирует вместе с командой разработчиков, чтобы убедиться, что функции, реализованные во время данной итерации, действительно реализованы. Тестирование не переносится на более поздний этап.
Everyone tests- При гибком тестировании приложение тестирует вся команда, включая аналитиков, разработчиков и тестировщиков. После каждой итерации даже заказчик выполняет приемочное тестирование пользователя.
Shortening Feedback Loops- В Agile Testing бизнес-команда знакомится с разработкой продукта для каждой итерации. Они участвуют в каждой итерации. Постоянная обратная связь сокращает время отклика обратной связи и, следовательно, меньше затрат на ее устранение.
Keep the Code Clean- Дефекты исправляются по мере их возникновения в рамках одной итерации. Это гарантирует чистый код на любом этапе разработки.
Lightweight Documentation - Вместо исчерпывающей тестовой документации, Agile-тестеры -
- Используйте многоразовые контрольные списки, чтобы предлагать тесты.
- Сосредоточьтесь на сути теста, а не на случайных деталях.
- Используйте легкие стили / инструменты документации.
- Фиксируйте тестовые идеи в уставах для исследовательского тестирования.
- Используйте документы для различных целей.
Leveraging one test artifact for manual and automated tests- Один и тот же артефакт тестового скрипта можно использовать для ручного тестирования и в качестве входных данных для автоматических тестов. Это устраняет необходимость в документации ручного тестирования, а затем в эквивалентном сценарии тестирования автоматизации.
“Done Done,” not just done - В Agile считается, что функция создается не после разработки, а после разработки и тестирования.
Test-Last vs. Test Driven- Тестовые случаи написаны вместе с требованиями. Следовательно, развитие может быть стимулировано тестированием. Этот подход называется разработкой, управляемой тестированием (TDD), и разработкой, управляемой приемочным тестированием (ATDD). Это контрастирует с последним этапом тестирования Waterfall Testing.

Действия по гибкому тестированию

Действия по гибкому тестированию на уровне проекта:

Планирование выпуска (план тестирования)
- Для каждой итерации
- Действия по гибкому тестированию во время итерации
Регрессионное тестирование
Действия по выпуску (связанные с тестированием)

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

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

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

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

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

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

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

Гибкие методологии

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

Scrum

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

XP

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

Кристалл

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

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

FDD

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

DSDM

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

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

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

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

В Lean Principles являются -

Устранение отходов
Усиление обучения
Обязательство отсрочки
Расширьте возможности команды
Доставка быстро
Добросовестность в
Увидеть все

Канбан

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

Канбан основан на -

Канбан-доска (наглядная и постоянная в процессе разработки)
Лимит незавершенного производства (WIP)
Время выполнения

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

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

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

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

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

Другие широко используемые методологии Agile-тестирования:

Test-Driven Development (TDD) - Разработка через тестирование (TDD) основана на кодировании, управляемом тестами.
Acceptance Test-Driven Development (ATDD) - Разработка, основанная на приемочных испытаниях (ATDD), основана на общении между клиентами, разработчиками и тестировщиками и управляется заранее определенными критериями приемки и сценариями приемочных испытаний.
Behavior-Driven Development (BDD) - При разработке, управляемой поведением (BDD), тестирование основывается на ожидаемом поведении разрабатываемого программного обеспечения.

Жизненный цикл гибкого тестирования

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

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

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

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

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

У Agile-тестировщика должны быть традиционные навыки тестирования. Кроме того, Agile-тестеру необходимы:

Хорошие навыки межличностного общения.
Способность действовать позитивно и ориентироваться на решения с членами команды и заинтересованными сторонами.
Способность проявлять критическое, ориентированное на качество, скептическое отношение к продукту.
Способность проявлять инициативу и активно получать информацию от заинтересованных сторон.
Навыки для эффективной работы с клиентами и заинтересованными сторонами в определении тестируемых пользовательских историй, критериев приемлемости.
Талант быть хорошим членом команды, работающей с разработчиками над созданием качественного кода.
Удобство использования навыков тестирования, чтобы иметь правильные тестовые примеры в нужное время и на нужном уровне и хорошо выполнять их в течение спринта.
Возможность оценивать и сообщать результаты тестирования, ход тестирования и качество продукции.
Открытость для быстрого реагирования на изменения, включая изменение, добавление или улучшение тестовых примеров.
Возможность самоорганизации работы.
Энтузиазм к постоянному повышению квалификации.
Компетентность в автоматизации тестирования, разработке на основе тестирования (TDD), разработке на основе приемочных испытаний (ATDD), разработке на основе поведения (BDD) и тестировании на основе опыта.

Роль тестировщика в Agile-команде

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

Действия Agile Tester включают:

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

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

Teamwork
Планирование тестирования
Нулевой спринт
Integration
Практики гибкого тестирования

Командная работа

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

Collaborative Approach- Работа с межфункциональными членами команды по стратегии тестирования, планированию тестирования, спецификации тестирования, выполнению теста, оценке тестирования и отчетности по результатам тестирования. Участие в тестировании вместе с другими командными действиями.
Self-organizing - Хорошее планирование и организация спринтов для достижения целей тестирования путем объединения опыта других членов команды.
Empowerment - Принятие соответствующих технических решений в достижении целей команды.
Commitment - Стремление понять и оценить поведение и характеристики продукта в соответствии с требованиями клиентов и заинтересованных сторон.
Transparent - Открытость, общение и ответственность.
Credibility- Обеспечение достоверности стратегии тестирования, ее реализации и исполнения. Информирование клиентов и заинтересованных сторон о стратегии тестирования.
Open to Feedback- Участие в ретроспективе спринтов, чтобы учиться на успехах и неудачах. Поиск отзывов клиентов и быстрые и адекватные действия для обеспечения качественных результатов.
Resilient - Реагирование на изменения.

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

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

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

Нулевой спринт

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

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

Интеграция

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

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

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

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

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

Pairing- Два члена команды работают вместе за одной клавиатурой. Один из них тестирует, другой просматривает / анализирует тестирование. Два члена команды могут быть
- Один тестировщик и один разработчик
- Один тестировщик и один бизнес-аналитик
- Два тестера
Incremental Test Design - Тестовые примеры создаются из пользовательских историй, начиная с простых тестов и заканчивая более сложными тестами.
Mind Mapping- Интеллектуальная карта - это диаграмма для визуальной организации информации. Mind mapping можно использовать как эффективный инструмент в Agile-тестировании, с помощью которого можно организовать информацию о необходимых сеансах тестирования, стратегиях тестирования и данных тестирования.

Статус теста может быть передан -

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

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

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

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

Доски Scrum (Доски Agile Task)
Графики выгорания
Автоматические результаты тестирования

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

Если в ходе тестирования возникают какие-либо задержки или препятствия, вся команда обсуждает и совместно работает над их устранением.

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

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

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

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

Тесты пройдены / не пройдены
Обнаружены / исправлены дефекты
Тестовое покрытие
Процент пройденных / неудачных тестов
Скорость обнаружения дефектов
Плотность дефекта

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

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

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

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

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

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

Гибкое тестирование основано на подходах к первому и непрерывному тестированию. Следовательно, традиционные инструменты тестирования, основанные на подходе «последний тест», могут не подходить. Следовательно, при выборе инструментов тестирования в Agile-проектах необходимо проверить соответствие Agile-тестированию.
Сократите общее время тестирования за счет автоматизации тестов на более ранних этапах жизненного цикла разработки.
Тестировщикам необходимо поддерживать темп, чтобы соответствовать графику выпуска релизов. Следовательно, надлежащее планирование, отслеживание и перепланирование действий по тестированию необходимо выполнять на лету, ставя целью качество продукта.
На ручное тестирование приходится 80% тестирования в проектах. Следовательно, опытные тестировщики должны быть частью Agile-команды.
Участие этих опытных тестировщиков на протяжении всего жизненного цикла разработки заставляет всю команду сосредоточиться на качественном продукте, отвечающем ожиданиям клиентов.
- Определение пользовательских историй, подчеркивающих поведение продукта, ожидаемое конечными пользователями.
- Определение критериев приемлемости на уровне пользовательской истории / уровне задачи в соответствии с ожиданиями клиента.
- Оценка трудозатрат и продолжительности тестирования.
- Планирование тестовых мероприятий.
- Согласование с командой разработчиков для обеспечения производства кода, соответствующего требованиям, с предварительным дизайном тестирования.
- Первое тестирование и непрерывное тестирование, чтобы убедиться, что статус «Готово» соответствует критериям приемки в ожидаемое время.
- Обеспечение тестирования на всех уровнях спринта.
- Регрессионное тестирование в конце каждого спринта.
- Сбор и анализ показателей продукта, которые полезны для успеха проекта.
- Анализ дефектов, чтобы определить, какие из них необходимо исправить в текущем спринте, а какие можно отложить до следующих спринтов.
- Ориентация на то, что важно с точки зрения Заказчика.

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

Whole Team approach- При таком подходе разработчики обучают тестировщиков, а тестировщики обучают других членов команды. Это помогает каждому понять каждую задачу в проекте, поэтому сотрудничество и вклад принесут максимальную пользу. Сотрудничество тестировщиков с клиентами также является важным фактором для определения их ожиданий с самого начала и перевода критериев приемлемости в требуемые для прохождения теста.
Agile Testing Mindset - Тестировщики активно работают над постоянным улучшением качества и постоянно сотрудничают с остальной командой.
Automate Regression Testing- Дизайн для тестирования и стимулирования разработки с помощью тестов. Начните с простого и позвольте команде выбирать инструменты. Будьте готовы дать совет.
Provide and Obtain Feedback- Поскольку это основная ценность Agile, вся команда должна быть открыта для обратной связи. Поскольку тестировщики являются экспертами, предоставляющими обратную связь, необходимо сосредоточиться на актуальной и необходимой информации. В свою очередь, при получении обратной связи следует учитывать изменения тестового примера и тестирование.
Build a Foundation of Core Agile Practices - Сосредоточьтесь на тестировании наряду с кодированием, непрерывной интеграцией, средами совместного тестирования, инкрементальной работой, принятием изменений, поддержанием синергии.
Collaborate with Customers - Выявление примеров, понимание и проверка соответствия требований к поведению продукта, настройка критериев приемки, получение отзывов.
Look at the Big Picture - Стимулируйте разработку с помощью бизнес-тестов и примеров с использованием реальных тестовых данных и размышлений о влиянии на другие области.

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

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

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

Удовлетворенность клиентов быстрым и непрерывным полным тестированием продукта и поиском отзывов клиентов.
Заказчики, разработчики и тестировщики постоянно взаимодействуют друг с другом, сокращая тем самым время цикла.
Гибкие тестировщики участвуют в определении требований, привнося свой опыт тестирования, чтобы сосредоточиться на том, что работает.
Тестировщики Agile участвуют в оценке усилий и времени тестирования.
Ранний дизайн теста, отражающий критерии приемки.
Требования к тестированию консолидируются всей командой, избегая недостатков.
Постоянная ориентация всей команды на качество продукта.
Значение Done прохождение тестов, отражающих статус, гарантирует выполнение требований.
Постоянная обратная связь о задержках или блокировках, чтобы решение могло быть принято немедленно с усилиями всей команды.
Быстрое реагирование на меняющиеся требования и быстрое их удовлетворение.
Регрессионное тестирование, управляемое непрерывной интеграцией.
Никаких задержек между разработкой и тестированием. сначала тестируйте, следуют подходы к непрерывному тестированию.
Автоматическое тестирование внедряется на ранних этапах жизненного цикла разработки, что сокращает общее время и усилия на тестирование.

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

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

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

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

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

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

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

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

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

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

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

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

Приемочное тестирование пользователей

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

Типы тестов

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

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

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

Тесты могут быть на -

Supporting Development (Support Programming) - Тесты поддержки программирования используются программистами.
- Чтобы решить, какой код им нужно написать для выполнения определенного поведения системы.
- Какие тесты необходимо запустить после кодирования, чтобы новый код не мешал остальному поведению системы
Verification only (Critique Product) - Тесты продуктов Critique используются для обнаружения недостатков в готовом продукте.

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

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

Деловая встреча, или
Облицовка технологий

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

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

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

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

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

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

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

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

Quadrant Q1- Unit Level, Technology Facing и поддерживает разработчиков. Модульные тесты относятся к этому квадранту. Эти тесты могут быть автоматизированными.
Quadrant Q2- Системный уровень, бизнес-ориентированность и соответствие продукта поведению. Функциональные тесты относятся к этому квадранту. Эти тесты выполняются вручную или автоматически.
Quadrant Q3- Уровень приемлемости системы или пользователя, ориентация на бизнес и сосредоточение внимания на сценариях в реальном времени. Пользовательские приемочные испытания относятся к этому квадранту. Эти тесты выполняются вручную.
Quadrant Q4- Уровень приемлемости системы или эксплуатации, используемые технологии и акцент на производительности, нагрузке, нагрузке, ремонтопригодности и масштабируемости. Для этих тестов могут использоваться специальные инструменты наряду с автоматизацией тестирования.

Сочетая их, квадранты гибкого тестирования отражают What-Testing-When можно визуализировать следующим образом -

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

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

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

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

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

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

Планирование выпуска

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестировщики в Scrum-команде могут следовать следующим методам Agile:

Pairing- Два члена команды сидят вместе и работают вместе. Эти два человека могут быть двумя тестировщиками или одним тестировщиком и одним разработчиком.
Incremental Test Design - Тестовые наборы разрабатываются по мере постепенного продвижения спринтов и добавления пользовательских историй.

Метрики Agile

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

Для разработки Scrum предлагается несколько метрик. Важные метрики -

Ratio of Successful Sprints - (Number of successful Sprints / Total number of Sprints) * 100. Успешный спринт - это тот, в котором Команда может выполнить свои обязательства.
Velocity- Скорость команды зависит от количества очков истории, заработанных командой во время спринта. Story Points - это количество пользовательских историй, подсчитываемых во время оценки.
Focus Factor - (Velocity / Team’s Work Capacity) / 100. Фактор фокусировки - это процент усилий команды, которые приводят к созданию законченных историй.
Estimation Accuracy - (Estimated effort / Actual effort) / 100. Точность оценки - это способность команды точно оценить усилия.
Sprint Burndown- Работа (в сюжетных точках или в часах), оставшаяся против. Работа, которая должна оставаться в идеале (согласно оценке).
- Если больше, то это означает, что Команда взяла на себя больше Работы, чем она может сделать.
- Если меньше, это означает, что Группа не сделала точной оценки.
Defect Count- Количество дефектов в Спринте. Количество дефектов - это количество дефектов в программном обеспечении по сравнению с невыполненными.
Severity of Defects- Дефекты можно разделить на мелкие, серьезные и критические по степени серьезности. Тестировщики могут определять категоризацию.

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

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

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

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

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

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

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

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

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

Step 1 - Напишите тестовый пример, чтобы отразить ожидаемое поведение функциональности кода, который необходимо написать.
Step 2- Запустите тест. Тест не проходит, так как код еще не разработан.
Step 3 - Разработайте код на основе тестового примера.
Step 4- Запустите тест еще раз. На этот раз тест должен пройти, поскольку функциональность закодирована. Повторяйте шаги (3) и (4), пока тест не пройдет успешно.
Step 5 - Реорганизуйте код.
Step 6 - Запустите тест еще раз, чтобы убедиться, что он прошел.

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

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

Разработка через приемочные испытания

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

Step 1 - Напишите примеры приемочных испытаний вместе с пользовательскими историями в сотрудничестве с заказчиком и пользователями.
Step 2 - Определите соответствующие критерии приемки.
Step 3 - Разработать код на основе приемочных испытаний и критериев приемки.
Step 4 - Запустите приемочные тесты, чтобы убедиться, что код работает должным образом.
Step 5- Автоматизировать приемочные испытания. ПовторениеStep 3 – Step 5 пока не будут реализованы все пользовательские истории в итерации.
Step 6 - Автоматизировать регрессионные тесты.
Step 7 - Запустите автоматические регрессионные тесты, чтобы обеспечить непрерывную регрессию.

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

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

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

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

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

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

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

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

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

Определение Done

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

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

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

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

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

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

Информация о тестах

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

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

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

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

Дизайн функциональных и нефункциональных тестов

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

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

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

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

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

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

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

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

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

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

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

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

Для оценки вероятности (правдоподобия) и воздействия каждого риска необходимо провести анализ рисков. Затем риски расставляются по приоритетам -

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

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

Фитнес-тесты

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

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

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

Типичное содержание плана тестирования:

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

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

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

Истории пользователей

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

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

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

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

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

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

В Test Driven Development, Сначала пишутся модульные тесты, которые не проходят. Код разрабатывается и тестируется, чтобы гарантировать прохождение тестов.

В Acceptance Test Driven Development, Приемочные тесты сначала пишутся на отказ, Код разрабатывается и тестируется, чтобы гарантировать прохождение тестов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пользовательские истории, которые поддаются тестированию и имеют эффективный размер, приводят к разработке и тестированию в указанные сроки.
Ограничение WIP (Work-In-Progress) позволяет сосредоточиться на ограниченном количестве пользовательских историй одновременно.
Канбан-доска, которая визуально представляет рабочий процесс, помогает отслеживать действия по тестированию и узкие места, если таковые имеются.
Концепция совместной работы группы Kanban позволяет устранять узкие места по мере их выявления, без времени ожидания.
Предварительная подготовка тестовых примеров, поддержание набора тестов в процессе разработки и получение отзывов клиентов помогает в устранении дефектов в рамках итерации / спринта.
Определение Done (DoD) называется Done-Done в том смысле, что история достигает состояния завершения только после завершения тестирования.

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

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

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

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

Тестировщики участвуют в создании пользовательской истории и, таким образом, обеспечивают:
- Все возможные варианты поведения системы фиксируются с помощью пользовательских историй и нефункциональных требований, которые являются частью пользовательских историй.
- Пользовательские истории можно проверить.
- Размер пользовательских историй позволяет завершить разработку и тестирование (DoneDone) в рамках итерации.
Визуальная Канбан-доска для задач -
- Отображает статус и ход выполнения задач
- Узкие места выявляются сразу же по мере их возникновения
- Облегчает измерение времени цикла, которое затем можно оптимизировать
Совместная работа в команде помогает в -
- Ответственность всей команды за качественный продукт
- Устранение узких мест по мере их возникновения, экономия времени ожидания
- Вклад каждого опыта во все виды деятельности
Непрерывная интеграция, ориентированная на тестирование непрерывной интеграции
Автоматизация тестов для экономии усилий и времени на тестирование
Предотвращение дефектов с помощью тестовых примеров, написанных ранее для разработчиков, и наставничества разработчиков в отношении того, что ожидается при различном поведении Системы -
- Ограничение WIP, позволяющее сосредоточиться на ограниченном количестве пользовательских историй одновременно
Непрерывное тестирование по мере продвижения разработки для обеспечения исправления дефектов в рамках итерации -
- Обеспечьте охват тестами
- Держите количество открытых дефектов на низком уровне

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

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

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

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

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

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

При планировании выпуска тестировщики предоставляют:

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

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

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

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

Сюжетное планирование

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

Story Planning включает в себя следующие тестовые задачи -

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

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

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

История развития

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

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

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

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

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

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

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

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

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

Note - Решения для записи и воспроизведения, последнего тестирования, тяжелого веса и автоматизации тестирования не являются гибкими, как -

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

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

S.No.	Инструмент и цель
1	Hudson CI Framework
2	Selenium Функциональное тестирование - интегрировано с Hudson
3	CruiseControl CI Framework
4	Junit Модульный тест Java
5	Nunit .Net Unit Test
6	Cobertura / JavaCodeCoverage / JFeature / JCover / Покрытие Java Test
7	Jester Java - тестирование мутаций / автоматический поиск ошибок
8	Gretel Инструмент мониторинга покрытия тестами Java
9	TestCocoon C / C ++ или C # - уменьшает количество тестов за счет поиска повторяющихся тестов и обнаруживает мертвый код.
10	JAZZ Java - покрытие ветвей, узлов и обезвреживаний и реализует графический интерфейс, средства планирования тестирования, динамические инструменты и анализатор тестирования.
11	Ant Java - Автоматизация сборки
12	Nant .Net - Автоматизация сборки
13	Bonfire Надстройка Agile Testing для JIRA

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

Поддержка эффективных средств автоматизации тестирования Agile -

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

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

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

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

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

Fit
Fitnesse
Concordion
Ruby
Cucumber

Поместиться

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

Клиенты или Владельцы продуктов должны приводить примеры поведения продуктов с использованием Microsoft Word и Microsoft Excel.
Программисты легко превратят эти примеры в автоматизированные тесты.

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

FitNesse

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

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

Экспресс-тесты в виде таблиц входных и ожидаемых выходных данных.
Используйте FitNesse, чтобы поместить тестовую таблицу на страницу, которую вы можете редактировать.
- Или поместите тестовую таблицу в Microsoft Excel, скопируйте в буфер обмена и затем используйте Spreadsheet to FitNesse команда, чтобы FitNesse отформатировал вашу таблицу правильно
Запустить тест
Вы получаете результаты тестирования путем цветовой кодировки ячеек в тестовой таблице.
- зеленые ячейки означают, что ожидаемые значения получены
- красные ячейки показывают, что получено значение, отличное от ожидаемого
- желтые ячейки означают, что возникло исключение

Огурец

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

Используется для написания приемочных тестов для веб-приложений.
Позволяет автоматизировать функциональную проверку в легко читаемом и понятном формате, таком как простой английский.
Был реализован на Ruby, а затем расширен до среды Java. Оба поддерживают Junit.
Поддерживает другие языки, такие как Perl, PHP, Python, .Net и т. Д.
Может использоваться вместе с селеном, ватиром, капибарой и т. Д.