Test Design Specification Template

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

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

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

· Набор тест кейсов и тестов (Test Case & Test suite) - это последовательность действий, по которой можно проверить соответствует ли тестируемая функция установленным требованиям.

· Дефекты / Баг Репорты (Bug Reports / Defects) - это документы, описывающие ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

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

 

Рекомендации по написанию Тест Плана

Каждая методология или процесс пытаются навязать нам свои форматы оформления планов тестирования. Предлагаю вам, как пример, шаблоны тест планов от RUP (Rational Unified Process) и стандарт IEEE 829:

1. TestPlanTemplate_RUP

2. TestPlanTemplate_IEEE_829

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

1. что надо тестировать (объект тестирования: система, приложение, оборудование)

2. что будете тестировать (список функций и компонент тестируемой системы)

3. как будете тестировать (стратегия тестирования - виды тестирования и их применение по отношению к тестируемому объекту)

4. когда будете тестировать (последовательность проведения работ: подготовка, тестирование, анализ результатов, в разрезе запланированных фаз разработки проекта)

5. критерии начала и окончания тестирования

 

 Что надо тестировать?

· описание объекта тестирования: системы, приложения, оборудования

 Что будете тестировать?

· список функций и описание тестируемой системы и её компонент в отдельности

 Как будете тестировать?

· стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования

 Когда будете тестировать?

· последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки

 Критерии начала тестирования:

· готовность тестовой платформы (тестового стенда)

· законченность разработки требуемого функционала

· наличие всей необходимой документации

·...

 Критерии окончания тестирования:

· результаты тестирования удовлетворяют критериям качества продукта:

o требования к количеству открытых багов выполнены

o выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF)

o выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB)

 

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

· Окружение тестируемой системы

· Необходимое для тестирования оборудование и программные средства

· Риски и их разрешение

Виды тест планов

Чаще всего на практике приходится сталкиваться со следующими видами тест планов:

1. Мастер Тест План (Master Plan or Master Test Plan)

2. Тест План (Test Plan), назовем его детальный тест план)

3. План Приемочных Испытаний (Product Acceptance Plan) - документ, описывающий набор действий, связанных с приемочным тестированием (стратегия, дата проведения, ответственные работники и т.д.) (Шаблон плана приемо-сдаточных испытаний от RUP)

Явное отличие Мастер Тест Плана от просто Тест Плана в том, что мастер тест план является более статичным в силу того, что содержит в себе высокоуровневую (High Level) информацию, которая не подвержена частому изменению в процессе тестирования и пересмотра требований. Сам же детальный тест план, который содержит более конкретную информацию по стратегии, видам тестировании, расписанию выполнения работ, является "живым" документом, который постоянно претерпевает изменения, отражающие реальное положение дел на проекте.

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

 

Test Design Specification Template

· (IEEE 829-1998)

· Test Design Specification Identifier

· Some type of unique company generated number to identify this test case specification,

· its level and the level of software that it is related to. Preferably the design specification

· level will be the same as the related software level. Ideally the design specification

· naming convention should follow the same general rules as the software it is related to.

· This is to assist in coordinating software and testware versions within configuration

· management.

· Unique "short" name for the case

· Version date and version number of the case

· Version Author and contact information

· Revision history

· Features to be Tested

· The set of test objectives covered by this test design specification. It is the overall purpose of

· this document to group related test items together.

· Features

· Attributes and Characteristics

· Groupings of features

· Level of testing appropriate to test item if this test design specification covers more that

· one level of testing

· Reference to the original documentation where this test objective (feature) was obtained.

· Approach Refinements

· Add the necessary level of detail and refinement based on the original approach defined in

· the test plan associated with this test design specification.

· Selection of specific test techniques

· Reasons for technique selection

· Method(s) for results analysis

· Tools etc.

· Relationship of the test items/features to the levels of testing

· Summarize any common information that may relate to multiple test cases or procedures.

· My centralizing common information document size is reduced and maintenance is

· simplified.

· Shared Environment

· Common setup/recovery

· 2001 - Software Quality Engineering - Version 7.0

· A - 16

· Case dependencies

· Test Identification

· Identification of each test case with a short description of the case, it’s test level or any

· other appropriate information required to describe the test relationship.

· Identification of each test procedure with a short description of the case, it’s test level or

· any other appropriate information required to describe the test relationship.

· Feature Pass/Fail Criteria

· Describe the criteria for assessing the feature or set of features and whether the test(s) were

· successful of not.

Поделиться:

Воспользуйтесь поиском по сайту: