Гибкое тестирование - методы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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