23 артефакты разработки по относящиеся к тестированию план тестирования test plan

План тестирования. основной документ, определяет стратегию тестирования на каждой итерации. в него входят описание целей и задач тестирования в текущей

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

Сценарий тестирования (тест кейс или тестовый случай). Это один из основных документов, с которыми имеет дело тестировщик. По сути, упрощенное описание теста. То есть входной информации, условий и последовательности выполнения действий и ожидаемого выходного результата. Учитывая, что даже успешно прошедшие тесты в RUP выполняются неоднократно в ходе регрессионного тестирования, наличие таких описаний необходимо. Однако уровень формальных требований к их оформлению может меняться в очень широких пределах.

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

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

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

Список идей тестов. Использование в RUP для анализа и проектирования Системы Сценариев использования существенно упрощает задачу разработки необходимого набора тестов. Основной объем тестов строится как проверка различных вариантов выполнения каждого сценария использования. Однако тесты не сводятся к Сценариям использования, как и задачи тестирования не сводятся только лишь к проверке функциональных требований к системе. Проверка нефункциональных требований может потребовать использования специальных приемов и подходов. Соответствующие тесты не всегда очевидны. Для таких ситуаций и создается Список идей тестов. В него все желающие могут записать Что и/или Как стоит еще проверить. Этот список является внутренним рабочим документом группы тестирования.

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

Дефекты. Основополагающие артефакты процесса тестирования – описывают обнаруженные факты несоответствия системы предъявляемым требованиям. Являются одним из подтипов запросов на изменение, описывающих найденную ошибку или несоответствие на всех этапах тестирования. Хотя базу данных дефектов можно вести в текстовом файле или Excel таблице, предпочтительным является использования специализированного инструментального средства, которое позволяет передавать информацию об обнаруженных дефектах от тестировщиков к разарботчикам, а в обратную сторону – сведения об устранении дефектов. А также формировать необходимые отчеты о тенденциях изменения количества обнаруживаемых и устраняемых дефектов.

Раздел: Тестирование > Тестовые
Артефакты > Тест План (План тестирования)

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

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

  1. Test Plan Template RUP
  2. Test Plan Template IEEE 829

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

  1. Что надо тестировать?
    • описание объекта тестирования: системы, приложения, оборудования
  2. Что будете тестировать?
    • список функций и описание тестируемой системы и её компонент в отдельности
  3. Как будете тестировать?
    • стратегия тестирования, а именно: виды тестирования и их
      применение по отношению к объекту тестирования
  4. Когда будете тестировать?
    • последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing),
      анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки
  5. Критерии начала тестирования:
    • готовность тестовой платформы (тестового стенда)
    • законченность разработки требуемого функционала
    • наличие всей необходимой документации
  6. Критерии окончания тестирования:
    • результаты тестирования удовлетворяют критериям качества продукта:
      • требования к
        количеству открытых багов выполнены
      • выдержка определенного периода без изменения исходного кода приложения Code
        Freeze
        (CF)
      • выдержка определенного периода без открытия новых багов Zero
        Bug Bounce
        (ZBB)

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

  • Окружение тестируемой системы (описание программно-аппаратных средств)
  • Необходимое для тестирования оборудование и программные средства (тестовый стенд и его конфигурация,
    программы для автоматизированного тестирования и т.д.)
  • Риски и пути их разрешения

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

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

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

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

Для увеличения ценности вашего тест плана рекомендуется проводить его периодическое рецензирование со
стороны участников проектной группы. Это можно сделать просто договорившись между собой или же
реализовать в виде «процедуры утверждения». Как пример, приведем список участников проектной группы,
утверждение которых мы считаем необходимым:

  • Ведущий тестировщик
  • Тест менеджер (менеджер по качеству)
  • Руководитель разработки
  • Менеджер Проекта

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

Воспользовавшись вышеуказанными советами, у вас будет больше шансов написать хороший документ, нежели
придумывать все самим.

Наверх

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

(документы, модели и т.д.). Наиболее
распространенными тестовыми артефактами
являются:

  • План
    тестирования

    (Test Plan)

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

  • Набор
    тест кейсов и тестов

    (Test Case & Test suite)

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

  • Дефекты
    / Баг Репорты

    (Bug Reports / Defects)

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

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

Тест
План (План тестирования)

Тест
план

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

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

Каждая
методология или процесс пытаются
навязать нам свои форматы оформления
планов тестирования. Предлагаю вам, как
пример, шаблоны
тест планов

от RUP
(Rational Unified Process)

и стандарт
IEEE 829
:

  1. Test
    Plan Template RUP

  2. Test
    Plan Template IEEE 829

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

должен как минимум описывать следующее:

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

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

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

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

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

    • стратегия
      тестирования, а именно: виды
      тестирования

      и их применение по отношению к объекту
      тестирования

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

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

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

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

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

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

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

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

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

        выполнены

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

        (CF)

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

        (ZBB)

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

    • Окружение
      тестируемой системы (описание
      программно-аппаратных средств)

    • Необходимое
      для тестирования оборудование и
      программные средства (тестовый стенд
      и его конфигурация, программы для
      автоматизированного тестирования и
      т.д.)

    • Риски
      и пути их разрешения

  • Соседние файлы в папке 4_Тестовые Артефакты

    • #
    • #

    1. Занятие №4 Артефакты тестирования Жизненный цикл тестирования

    2. План на сегодня

    Вспоминаем материал прошлой лекции
    ЖЦ тестирования ПО
    Артефакты тестирования
    Работа с багтрекинговой системой

    3. Вспоминаем

    Что такое проект?
    Участники проекта?
    Цикл разработки ПО?
    Модели разработки ПО?
    Методологии разработки ПО?

    4. Жизненный цикл тестирования

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

    План тестирования (Test Plan)*
    Варианты использования (Use Cases)*
    Список проверки (Checklist)*
    Тестовые сценарии (Test Cases)*
    Матрица соответствий (Traceability Matrix)
    Отчет об ошибке (Bug Report)*
    Отчет о тестировании (Test Result Report)

    6. План тестирования (Test Plan)

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

    7. План тестирования (Test Plan)

    Что надо тестировать?
    Что будем тестировать?
    Когда будем тестировать?
    Критерии начала тестирования
    Критерии окончания тестирования
    Окружение тестируемой системы (описание
    программно-аппаратных средств)
    Необходимое для тестирования
    оборудование и программные средства

    8. Варианты использования (Use Cases)

    Описание поведения системы, когда она
    взаимодействует с кем-то (или чем-то) из
    внешней среды. Система может отвечать на
    внешние запросы Актора (англ. Actor), может
    сама выступать инициатором взаимодействия.

    9. Список проверки (Checklist)

    Чек-лист — это документ, описывающий что
    должно быть протестировано. При этом
    чек-лист может быть абсолютно разного
    уровня детализации.
    Составляющие:
    ◦ Функционал для тестирования
    ◦ Ожидаемый результат (+-)
    ◦ Статус

    10. Тестовые сценарии (Test Cases)

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

    11. Виды Тестовых Случаев

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

    12. Тестовые сценарии (Test Cases)

    13.

    14. Отчет об ошибке (Bug Report)

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

    15.

    16. Структура баг репорта

    Короткое описание (Summary)
    Детальное описание (Description)
    Проект (Project)
    Компонент приложения (Component)
    Номер версии (Version)
    Серьезность (Severity)
    Приоритет (Priority)
    Статус (Status)
    Автор (Author)
    Назначен на (Assigned To)
    ОС / Сервис Пак / Версия приложения…
    Описание (Steps+Results)
    Прикрепленный файл (Attachment)

    17. Серьезность и Приоритет дефекта

    Серьезность (Severity) — это атрибут,
    характеризующий влияние дефекта на
    работоспособность приложения.
    Приоритет (Priority) — это атрибут,
    указывающий на очередность выполнения
    задачи или устранения дефекта. Можно
    сказать, что это инструмент менеджера по
    планированию работ. Чем выше приоритет,
    тем быстрее нужно исправить дефект.

    18. Градация Серьезности (Severity) и Приоритета (Priority)

    Severity:





    S1
    S2
    S3
    S4
    S5
    Блокирующая (Blocker)
    Критическая (Critical)
    Значительная (Major)
    Незначительная (Minor)
    Тривиальная (Trivial)
    Priority:
    ◦ P1 Высокий (High)
    ◦ P2 Средний (Medium)
    ◦ P3 Низкий (Low)

    19. Жизненный цикл бага

    20. Написание баг репортов

    «Прочитав короткое описание бага (Bug
    Summary), я должен понять в чем состоит
    проблема, прочитав детальное описание
    бага (Bug Description) я должен знать строку
    кода, которую править.» ©
    Принцип «Что? Где? Когда?»

    21. Обязательные поля баг репорта

    Короткое описание (Bug Summary)
    Детальное описание (Description)
    Серьезность (Severity)
    Шаги к воспроизведению (Steps to
    reproduce)
    Результат (Actual Result)
    Ожидаемый результат (Expected Result)
    Версия приложения (Build found)

    22.

    23. Работа с Mantis Bug Tracker

    http://qa07.besaba.com/ — адрес трекера
    Логин приходил на почту
    Пароль устанавливался при регистрации
    magazqa.besaba.com – имя проекта
    Assign to – Vladislav.Zotke
    View Status – PRIVATE!!!
    http://magazqa.besaba.com/ – Тестовый
    сайт

    Дисклаймер. Данная статья не является претензией на объективность, а отражает только мое сугубо личное мнение. Также прошу обратить внимание на то, что мое мнение не является статичным и может меняться. Статья написана только для того, чтобы не отвечать много раз на одни и те же вопросы, а просто дать ссылку.

    Итак попробую ответить на вопрос: какие артефакты необходимы для обеспечения процесса тестирования (имеется ввиду разрабатываемые самим тестировщиком).

    Я выделяю несколько артефактов:

    1. План тестирования (Test plan)
    2. Тестовый сценарий (Test-case)
    3. Наборы тестовых сценариев (Test script or Test suite)
    * Набор тестовых сценариев для Smoke-test
    * План приёмосдаточных испытаний (ПСИ)
    4. Описание дефектов
    5. Отчет о тестировании

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

    План тестирования

    Есть как минимум два общепринятых понимания этого документа:

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

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

    * Взять книгу Роберт Калбертсон, Крис Браун, Гэри Кобб. Быстрое тестирование
    * Взять RUP
    * Погуглить
    * Дождаться когда я изложу пример в одной из следующих статей

    Тестовый сценарий(тест)

    Тестовый сценарий — это описание начальных условий, входных данных, действий пользователя и ожидаемого результата.
    Хорошая практика — написание тестовых сценариев на основании вариантов использования (Use cases).

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

    Варианты названий:

    * Атомарный тест
    * Тестовый вариант
    * Вариант тестирования
    * Тестовый случай

    Наборы тестовых сценариев

    Это тестовые сценарии сгруппированные по некоему признаку (например тестируемой функциональности). Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего (Test script)), так и независимыми (Test suite).
    Наиболее часто выделяемыми наборами являются: Набор тестовых сценариев для Smoke-test и План приёмо-сдаточных испытаний.

    Набор тестовых сценариев для Smoke-test

    Если честно, то я не знаю адекватного перевода на русский данного термина. Иногда используется перевод “Дымчатое тестирование”, но он вызывает у меня стойкое отвращение.

    Набор тестовых сценариев для Smoke-test — это документ, включающий в себя набор определенных тестовых сценариев, покрывающих основную функциональность объекта или системы. Цель проведения Smoke-test — убедиться в том, что ключевые функции программы работают, не вникая в подробности.

    Хорошая практика — прием билда в тестирование на основании прохождения Smoke-test. Также зачастую в качестве такого теста используют ежедневную сборку с обязательным прохождением unit тестов.

    Комментарий: Ежедневная сборка без unit тестов не может считаться как Smoke test. Это называется: “Ух ты компилицо”

    План приёмо-сдаточных испытаний (ПСИ)

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

    В общем случае подмножества тестов выглядят так как на рисунке.

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