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

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

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

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

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

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

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

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

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

В нашем примере для проекта продукт выпускается в конце спринта 2.

Переход к следующему выпуску имеет некоторую схожесть с переходом к следующему спринту. Например, следующие требования управления тестовыми выпусками для перехода в следующий спринт также применимы при переходе в следующий выпуск. Лидер команды тестирования проекта Кристина должна:

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

Однако, у Кристин есть следующие дополнительные требования, которые она не имела для спринта «без выпуска»:

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

Сценарий От Выпуска к Выпуску

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

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

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

Проектный пример идет дальше к выпуску 2 и начинает планирование спринта 1. Как лидер команды тестирования Кристина должна будет:

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

Поскольку спринт 2 является последним спринтом выпуска, считаем план тестирования спринта 2 как план тестирования относительно целого выпуска. Это будет часто целесообразно, потому что последний спринт выпуска будет, вероятно, включать все тестирование, требуемое для приемки. В примере для проекта Кристина переименовала плана тестирования спринта 2 в «Спринт 2 Плана тестирования — для Выпуска 1». Он используется для проверки и принятия всей функциональности и возможностей выпуска 1.

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

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

Клонируйте Выпуск 1

В конце выпуска оцените состояние работ и обновите артефакты тестирования соответственно так, чтобы:

  • Отчеты показывали выпуск 1 как закрытый.
  • Планирование спринта от выпуска 1 к выпуску 2 могло быть легко выполнено.
  • Все артефакты тестирования находились в корректном состоянии и присвоены корректному пути итерации.

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

Действие Руководство
Оценить Состояние Работ Идентифицируйте:

  • Пользовательские истории, которые будут повторно протестированы в спринте 1 выпуска 2.
  • Тестовые сценарии, которые будут регрессированы в спринте 1 выпуска 2.
  • Проверенные тестовые сценарии.
  • Неполные тестовые сценарии, для которых работа была задержана для спринта 1 выпуска 2.
  • Тестовые сценарии не выполненные в выпуске 1, для которых работа была задержана для спринта 1 из выпуска 2.
Проверить Состояние Тестового Случая и Путь Итерации
  • Все активные тестовые случаи находятся в Активном состоянии.
  • Все активные тестовые случаи назначены на путь итерации спринта 2 (… \Release1\Sprint2).
  • Проверьте, что тестовые случаи, которые никогда не выполнялись, назначены в журнал.
Проверить Состояние Общих Шагов и Путь Итерации
  • Все активные общие шаги находятся в Активном состоянии.
  • Все активные общие шаги назначены пути итерации спринта 2.
  • Проверьте, что общие шаги, которые никогда не выполнялись, назначены в журнал.
Обновить План Тестирования Выпуска 1
  • Установите состояние тестирования «проверенным» наборам в «Завершено».
  • Установите состояние тестирования для плана тестирования выпуска 1 в «Завершено».
  • Установите состояние для свойств плана тестирования выпуска 1 в «Неактивный».

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

Создайте базовую линию

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

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

  • Корневому пути области.
  • Спринтам под путем итерации узла выпуска 1.
Эти рабочие элементы становятся базовой линией, как только их путь области установлен в выпуск 1 (… \Release1). Рабочие элементы под этим узлом пути области могут тогда быть установлены только для чтения.

Различия в зависимости от Декларативной Модели и Последней Модели

После этого шаги одинаковы для обеих моделей. Любые рабочие элементы, которые будут продвинуты в следующий выпуск, клонируются в журнал. Как правило, это будут активные ошибки, готовые тестовыми случаи и активные общие шагами.

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

Настройте новый план тестирования

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

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

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

Действие Руководство
Создать План Тестирования
  • Включайте номер спринта в имя плана.
  • Установите состояние тестирования плана тестирования спринта в «Планируется».
  • Установите даты начала и окончания плана тестирования так, чтоб они соответствовали датам начала и окончания спринта.
  • Установите путь итерации плана тестирования в \project\Release2\Sprint1.
  • Создайте один или более наборов для новых тестовых случаев, разработанных для возможностей выпуска 2.
  • Не создавайте набор для регрессионных тестовых случаев выпуска 1. Он будет создаваться, когда тестовые сценарии выпуска 1 будут клонироваться.
Клонировать Тестовые Случаи
  • Используйте команду TCM.exe Suites /Clone, чтобы создать набор регрессионных тестов в новом плане тестирования.
  • Команда /Clone:
    • Копирует тестовые случаи и общие шаги, используемые этими тестовыми случаями.
    • Создает ссылки от клонированных тестовых случаев к новым общим шагам.
    • Создает связанную ссылку от клонированного до исходного элемента.
  • Откройте Visual Studio Command Prompt из папки Visual Studio Tools во Все Программы, Microsoft Visual Studio 2011 и Visual Studio Tools.
  • Измените каталог на «… \Microsoft Visual Studio 2012\Common7\IDE»
  • Выполните TCM Suites /?, чтобы получить синтаксис для использования команды TCM Suites /Clone.

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

Примечание Для 2012 RTM команда TCM Suites /Clone поддерживала только статические наборы тестов. С Обновлением Visual Studio №1, мы также поддерживаем опцию «/CloneRequirement»
Примечание Команда TCM Suites /Clone доступна только в Team Foundation Server 2012. Для Visual Studio 2010 возможно использование Test Case Migrator Tool от Shai Raiten. См. раздел Ссылки в приложении.
Действие Руководство
Назначить Новые Тестовые Случаи
  • Переименуйте «скопированный» набор тестов в новом плане.
  • Проверьте, что тестовые случаи и общие шаги в новом наборе являются новые рабочими элементами.
  • Проверьте связи и путь итерации в клонированных тестовых случаях и общи шагах:
    • У клонированный рабочий элемент должен быть связан ссылкой на исходный рабочий элемент.
    • Клонированные тестовые случаи должны быть связаны с клонированными общими шагами.
    • Путь итерации клонированных элементов должен быть \project\Release 2\Sprint 1.
Когда проект готов для начала тестирования спринта 1
  • Установите состояние тестирования плана тестирования спринт 1 в «Выполняется».

Проверка клонированных тестовых случаев

Примечание Примечание – создание регрессионных тестовых случаев
Тестовые случаи, которые являются частью базовой линии выпуска 1, были дублированы. Эти дубликаты используются в выпуске 2 для поддержки регрессионного тестирования и чтобы завершить любое тестирование, не выполненное в выпуске 1. Новые функции в Обновлении Visual Studio №2 создадут запись в истории в тестовом случае, когда выполняется клонирование. До этого вы можете пометить эти копии, используя пользовательский код причины, добавляя пользовательское поле индикатор, комментарий к истории или некоторым другим способом, таким образом, будет просто идентифицировать их при назначении в план тестирования.

Регрессионное тестирование

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

  • Регрессионный тестовый случай в текущем спринте был клонирован из снимка базовой линии.
  • Регрессионный тестовый случай тестирует требование (пользовательскую историю или элемент журнала продукта) в снимке базовой линии
  • Рассмотрите предупреждение ранее об использовании наборов основанных на требованиях и сносок для функций, представленных в Обновлении №1 и Обновлении №2 для Visual Studio 2012.
  • Регрессионное тестирование не принимает изменения в требованиях.
  • Не изменяйте рабочий элемент требования в снимке базовой линии, когда изменения требования должны быть внесены: клонируйте рабочий элемент требования в журнал или текущий спринт и пометьте изменения.

Когда Регрессионные Тесты Не Проходят

Создайте ошибку для регрессионного тестового случая. Затем рассмотрите использование одного из следующего ниже.

Примечание Примечание – соответствующие ссылки к требованиям и ошибкам
За исключением второго пункта, не сохраняйте ссылки в исходных тестовых случаях к требованиям (пользовательские истории и элементы журнала продукта) и ошибкам при клонировании тестовых случаев и общих шагов.
  1. Добавьте соответствующую ссылку от клонированного тестового случая к требованию. У этого подхода относительно меньше видимости. Ошибка не будет обнаруживаться в отчетах о состоянии требований, потому что у регрессионного тестового случая нет ссылки Тестирует/Тестируется к требованию в текущем спринте.
  2. Для большей видимости связывайте клонированный тестовый случай к выпущенному требованию, используя тип ссылки Тестирует/Тестируется. Это просто, эффективно и действительно отображается в отчетах о состоянии требования. Однако, это также подразумевает работу для выпущенного требования, нарушая изоляцию базовой линии.
  3. Для большей видимости и полной поддержки изоляции базовой линии, клонируйте рабочие элементы требования для нового спринта. Пометьте «нет никаких изменений» в требовании. Свяжите клонированный тестовый случай с новым требованием, используя тип ссылки Тестирует/Тестируется.

Итоги

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

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

Реклама

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s

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