Методы тестирования из традиционного тестирования также могут быть использованы в 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 и запускает контрольные примеры для тестируемого проекта.