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

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

Руководство по управлению тестовыми выпусками. Что такое Управление Тестовыми Выпусками?

Posted by Шамрай Александр на Апрель 30, 2013

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

Темы
  • Почему Управление Тестовыми Выпусками Необходимо
  • Краткое Описания Артефактов Тестирования
  • Цели Управления Тестовыми Выпусками
  • Альтернативные Классификации Рабочих Элементов

Потребность в Управлении Тестовыми Выпусками

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

  • Обеспечение отчетов тестирования для каждого спринта.
  • Поддержка снимка тестовых сценариев при выпуске.
  • Обеспечение отчетов тестирования по ветвям.
  • Минимизация издержек управления планами тестирования и рабочими элементами.

Чтобы успешно справиться с этими проблемами, лидер команды тестирования программного обеспечения должен разработать решение для организации и управления артефактами тестирования проекта, которыми являются:

  • Планы тестирования
  • Тестовые наборы
  • Тестовые случаи
  • Общие шаги

Артефакты Тестирования

Следующий рисунок показывает, как тестовые наборы и тестовые случаи отображаются в плане тестирования в Microsoft Test Manager. Тестовые случаи отображаются в выбранном тестовом наборе.

Представление Плана Microsoft Test Manager, Содержимое

  • Планы тестирования и тестовые наборы не являются рабочими элементами Team Foundation Server. Они являются отдельными артефактами, хранящимися в репозитории Team Foundation Server.
  • Тестовые случаи – рабочие элементы, но шаги в тестового сценария не могут быть отредактированы в Visual Studio. Шаги тестирования должны редактироваться в Microsoft Test Manager или других инструментах, специально предназначенных для этой цели (см. ссылки ниже).
  • Общие шаги — рабочие элементы и шаги в них должны редактироваться так же, как и шаги тестового случая. Общие шаги могут использоваться в различных тестовых случаях.

Следующий рисунок показывает форму тестового случая в Microsoft Test Manager. Шаги тестирования и общие шаги отображаются на вкладке Шаги.

Форма Тестового Случая Microsoft Test Manager

Предупреждение Наборы на основе требовании и Базовые линии
Тщательно оценивайте использование наборов на основе требований. Особенно, если Ваша организация требует, чтобы Вы поддерживали тестовые случаи и результаты тестирования в их точном состоянии после выпуска программного обеспечения. Например, если Вы добавите регрессионный тестовый случай к пользовательской истории, которая является частью набора на основе требований в предшествующем выпуске, то результаты тестирования изменят состояние плана тестирования предшествующего выпуска. Функция Microsoft Test Manager 2012 TCM.exe /clone избегает это, преобразовывая наборы на основе требований в статические наборы. Другие опции включают клонируемые требования для каждого выпуска, а также тестовые случаи или использование наборов на основе требований.Наборы на основе требований (НОТ) и Тестовые случаи
Когда Вы удаляете тестовый случай из набора на основе требований, он также удаляет ссылку «тестирует/тестируется» из тестового случая к пользовательской истории (или PBI). Чтобы избежать это, начиная с Обновления Visual Studio №2, планы Microsoft вводят признак «Не Применимый», который может использоваться, чтобы отметить тестовый случай как «Не Применимый» для текущего цикла, но сохраняет трассируемость.

Цели Управления Тестовыми Выпусками

Цели управления тестовыми выпусками состоят в том, чтобы определить минимальное обновление ваших артефактов тестирования, чтобы гарантировать, что требования к отслеживанию тестов и к отчетности удовлетворяются. Обновление обычно имеет место когда:

  • Выполняется переход к следующему спринту.
  • Код перемещается из одной ветки в другую.
  • Выполняется переход к следующему выпуску.

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

  • Спринтами
  • Фазами
  • Выпусками
  • Подкомандами
  • Компонентами
  • Базовыми линиями

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

Тип Поля классификации Комментарии
План Тестирования
  • Наименование
  • Путь области
  • Путь итерации
  • Используемое построение
  • Владелец
  • Состояние
  • Дата начала
  • Дата окончания
  • Состояние тестирования
Тип план тестирования не является рабочим элементом, но в действительности имеет часть таких же атрибутов. Например, у плана тестирования есть атрибуты состояния, пути области и пути итерации.Независимое «состояние тестирования» также обеспечено, которое может быть просмотрено и установлено только из окна содержимого плана в MTM.
Тестовый Набор
  • Наименование
  • Тип
  • Состояние тестирования
Различные типы наборов такие, как статичные, основанные на требованиях и основанные на запросе, ведут себя по-разному. См. предупреждение выше для наборов основанных на требованиях.»Состояние тестирования» также доступно для каждого набора.
Тестовый случай
  • Наименование
  • Кому назначено
  • Состояние
  • Причина
  • Приоритет
  • Состояние автоматизации
  • Путь области
  • Путь итерации
Тестовый случай — рабочий элемент и может быть выбран как другие типы рабочих элементов.Шаги тестов не могут быть отредактированы от Visual Studio.
Общие шаги
  • Наименование
  • Кому назначено
  • Состояние
  • Причина
  • Приоритет
  • Путь области
  • Путь итерации
Общие шаги – рабочий элемент и может быть выбран как другие типы рабочих элементов.Шаги общих шагов не могут быть отредактированы от Visual Studio.

Статус и аспекты классификации плана тестирования, наборов и тестовых случаев.

Примечание Рассмотрите документирование «Плана Управления Тестовыми Выпусками». Используйте этот план для распространения информации в вашей команде и как справку о том, как обновляются поля классификации артефактов тестирования, поля состояний и связи.

Альтернативы для Классификации Рабочих Элементов

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

  • Путь итерации
  • Путь области

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

Путь Итерации

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

  • Выпуск
  • Фаза
  • Спринт

Безопасность для пути итерации ограничена разрешениями на создание, редактирование, организацию и просмотр узлов дерева. Возможно иметь некоторую комбинацию выпусков, фаз и спринтов по пути итерации. Однако, у пути итерации будет множество значений. Это будет рассмотрено более подробно в разделе далее «Использование Путей Области и Итерации: Две Модели.»

Путь Области

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

  • Подкоманде
  • Компоненту продукта
  • Базовой линии продукта

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

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

  • Редактировать рабочие элементы в этом узле
  • Управлять планами тестирования
  • Просматривать рабочие элементы в этом узле

Использование Путей Итерации и Области: Две Модели

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

«Декларативная модель»

В Декларативной Модели активная работа назначается явной версии, определенной в начале проекта. Например, если проектная команда работает над спринтом 1 из выпуска 1.0, итеративный путь был бы [корень дерева итераций]\Release 1\Sprint01. Когда версия 1.0 выпущена, и начинается работа над следующей версией, итеративный путь для работы будет [корень дерева итераций] Release 2\Sprint01.

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

Пример иерархии пути итерации при использовании декларативной модели

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

Пример иерархии пути области при использовании декларативной модели

«Последняя модель»

В Последней Модели итеративный путь не используется для определения версии выпуска, только спринта. Активная работа всегда находится в корне пути области. Например, если проектная команда работает над спринтом 1 из выпуска 1.0, путь итерации будет [корень дерева итераций]\Sprint01 и путь области будет [корень дерева области]. Когда версии 1.0 выпущены после спринта 5, путь области для завершенной работы изменяется на [корень дерева области]\1.0. Работа над следующей версией начинается по пути итерации [корень дерева итераций]\Sprint06 и путь области остается тем же как раньше [корень дерева области].

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

Пример иерархии пути итерации при использовании последней модели

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

  • Путь итерации – период времени
  • Путь области – версия

Пример иерархии пути области при использовании последней модели

Сравнение Декларативной и Последней Моделей

За и против для этих двух моделей:

Модель За Против
Декларативная Проста для понимания Менее гибка, потому что поля пути итерации означают и версию, и период времени (номер выпуска и номер спринта).
Больше затрат на поддержку. Изменения организации проекта, структуры, вероятно, потребует изменений в пути итерации, который в этом случае должен быть обновлен во всех рабочих элементах.
После выпуска рабочие элементы обычно «оставляются позади» без любого изменения в путях итерации или области, что не обеспечивает явной индикации относительно анализа качества и утверждения базовой линии.
Последняя Использует ту же область и путь итерации для активной работы по выпускам: разработчики, работающие над последним кодом всегда, продолжают работать в корневом пути области. Сложно для понимания
Гибкая и простая в поддержке, потому что передача работы в архив (базовой линии), происходит после того, как выпуск завершен, когда все проектные изменения и решения были уже сделаны
Использует явное присвоение архивного пути области, который требует активного анализа рабочих элементов до их передачи в базовую линию.
Гибка и проста в поддержке, потому что путь области и итерации имеют однозначное значение, поэтому они могут быть расширены и изменены, не вступая в конфликт с другими значениями, как в Декларативной Модели.
Доступно управление разрешениями по определенной пути области для рабочих элементов.

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

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

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

Клонирование Рабочих Элементов

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

Тип рабочего элемента Клонирование Объяснение
Ошибка Активные ошибки Следуйте по принципу одна ошибка на базовую линию, предполагая, что у каждой базовой линии есть свое собственное ветвление кода. Фиксация должна быть применена в каждой базовой линии, даже если это та же ошибка.
Пользовательская история Только когда были изменены или когда найдены ошибки Смотрите раздел руководства «Когда Регрессионные Тесты Не Пройдены» далее.
Тестовый случай Готовые Тестовые Случаи Поддержка записей тестовых случаев на момент выпуска.
Общие шаги Активные Общие Шаги Поддержка записей общих шагов тестовых случаев на момент выпуска.

Предложенные практики клонирования для некоторых типов рабочих элементов

Руководство для клонирования рабочих элементов приведено ниже в документе.

Итоги

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

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

Реклама

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s

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