Заметки консультанта

Шамрай Александр Владимирович

Руководство по управлению тестовыми выпусками. От спринта к спринту

Posted by Шамрай Александр на Май 6, 2013

<<Перейти к содержанию

Темы
  • Переход к следующему спринту
  • Закрытие и планирование спринта
  • Примеры отчетов Управления Тестовыми Выпусками

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

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

  • Наш персонаж Кристина, которая является лидером команды тестирования в проекте.
  • Проект использует Microsoft Visual Studio Scrum 2.0 как шаблон процесса.
  • Проект использует декларативную классификацию рабочих элементов, где путь итерации …\Release 1\Sprint 1.
  • Путь области не используется.
  • Кристина использует один план тестирования на итерацию.

Сценарий от Спринта к Спринту

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

Кристина, как лидер команды тестирования, должна теперь создать план тестирования относительно спринта 2, который включает:

  • Регрессионное тестирование завершенной работы спринта 1
  • Новые тестовые сценарии для запланированной реализации в спринте 2

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

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

Примечание «Базовая линия» тестового случая – это точное состояние или снимок рабочего элемента тестового случая в определенный момент времени. Team Foundation Server действительно обеспечивает историю рабочих элементов, но не поддерживает управление версиями рабочих элементов. Поэтому, поддержка базовой линии тестирования не означает внесение изменения в план тестирования определенной базовой линии и его тестовые случаи после того, как базовая линия будет установлена. См. предупреждение ранее относительно наборов на основе требований и как Microsoft рассматривает это в Обновлении 2 для Visual Studio 2012.

Кристина должна:

  • Завершить эту работу максимально быстро и эффективно.
  • Обеспечить отчеты спринта 1, которые точны, полны и готовы к предстоящей ретроспективе по спринту 1.
  • Гарантировать, что план тестирования относительно спринта 2 настроен для обеспечения корректной отчетности по тестированию.
  • Убедиться, что отчеты для спринта 1 не будут затронуты активностями спринта 2.

Рекомендуемые практики

В примере для проекта первый шаг должен определить, как будут проверены пользовательские истории, присвоенные спринту 1, и какие тестовые случаи спринта 1 будут выполнены как регрессия во время выполнения спринта 2. Нужно рассмотреть следующие вопросы:

  • Какие тесты должны быть включены в план спринта 2?
  • Тестирование спринта 1 отслеживается?
  • Как прогресс тестирования в конце спринта должен быть показан?
  • Как регрессионные тестовые случаи должны быть организованы в плане тестирования?

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

Примечание Рекомендуемые практики показаны на концептуальном уровне. Они предназначены для передачи природы решения, а не обеспечения точных шагов выполнения работ. См. Управление Тестовыми Выпусками от Спринта к Спринту в Лабораторных Работах для ознакомления с процедурами и практическими примерами выполнения управления тестовым случаями от спринта к спринту.

Закрытие Спринта 1

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

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

Идентифицируйте:

  • Проверенные тестовые случаи, которые будут регрессированы в спринте 2.
  • Проверенные тестовые случаи, которые не будут регрессированы в спринте 2.
  • Неполные тестовые случаи, где работа была задержана для спринта 2.
  • Тестовые случаи невыполненные в спринте 1, т.к. работа была задержана для спринта 2.

Обновление и закрытие плана тестирования спринта 1

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

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

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

Используйте MTM для создания и настройки плана тестирования спринта 2.

Действие Руководство
Создать План Тестирования Спринта 2
  • Включите номер спринта в имя плана
  • Установите состояние тестирования плана тестирования спринта в «Планируется».
  • Установите даты начала и окончания для плана тестирования, чтобы они соответствовали датам запуска и окончания спринта.
  • Установите путь итерации плана тестирования в \project\Release1\Sprint2.
Назначить Тестовые Случаи из Плана Тестирования Спринта 1
  • Используйте функцию «Создание тестовых наборов с помощью ссылок на существующие тестовые случаи», чтобы скопировать все наборы с плана тестирования спринта 1 в плана тестирования спринта 2 (за исключением тех наборов, для которых Вы не планируете выполнять их тестовые случаи в спринте 2).
  • Удалите из наборов любые тестовые случаи, которые Вы не планируете выполнять в спринте 2.
  • Измените путь итерации оставшихся тестовых случаев в плане тестирования спринта 2 из \project\Release1\Sprint1 до \project\Release1\Sprint2.

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

Примечание Остающиеся проблемы с отчетностью по работам тестирования
Оставшейся работой тестирования, являются любые тестовые случаи в текущем плане тестирования спринта (спринт 1 в примере выше) в состоянии «готово», которые не были выполнены или провалены.Остающаяся работа будет продолжать отображаться в отчете Описание Пользовательских Историй SQL Server Reporting Services (SSRS) и подобных отчетах, если это не будет удалена из старых планов тестирования. Это может быть приемлемо. Если Вы хотите избежать этого:

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

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

Действие Руководство
Назначить Новые Тестовые Случаи на Спринт 2
  • Добавьте тестовые случаи из элементов журнала, которые запланированы для тестирования в спринте 2.
  • Установите их путь итерации в … \Release1\Sprint2.
Проверить Статус, Состояние и Ссылки
  • Проверьте чтобы план тестирования, наборы, тестовые случаи и общие шаги находились в корректном статусе и состоянии и что они связаны с корректными пользовательскими историями.
Проверить Путь Итерации
  • Проверьте чтобы у всех тестовых случаев и общих шагов в плане тестирования относительно спринта 2 есть корректный путь итерации. … \Release1\Sprint2.

Добавление тестовых случаев, проверка планов, наборов и общих шагов

Когда проект будет готов к тестированию в спринте 2, установите состояние плана тестирования спринта 2 в «Выполняется».

Примечание Даже при том, что тестовые случаи перемещены в следующий спринт, результаты остаются в спринте, в котором они были выполнены. Как только тестовый случай был присвоен другому спринту и выполнен, результаты связываются с тем же спринтом. Это позволяет Team Foundation Server обеспечивать точную историческую отчетность по результатам тестирования.

Итоги

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

<<Перейти к содержанию

Advertisements

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: