План тестирования Agile - действительно ли он нужен?

Нужен ли нам документ с планом гибкого тестирования?

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

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

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

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

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

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

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

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

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

Во время спринта QA постоянно тестирует новый код / ​​функцию. Планирование тестирования становится динамичной деятельностью, поскольку приоритеты дня меняются. Тестирование основано на активности в течение дня и исходе накануне.

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

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

Итак, с учетом всего этого, действительно ли документ с планом тестирования или обширные стратегии тестирования ушли в прошлое? Нам действительно нужен Agile Test Plan?