Артефакты, необходимые для тестирования. План теста


Про Тестинг - Тестирование - Тест План или план тестирования

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

Тест план (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. Критерии окончания тестирования:
    • результаты тестирования удовлетворяют критериям качества продукта:
    • ...

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

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

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

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

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

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

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

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

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

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

Наверх

www.protesting.ru

Блог Про Тестинг: План Тестирования (Test Plan)

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

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

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

  1. TestPlanTemplate_RUP
  2. TestPlanTemplate_IEEE_829

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

  1. что надо тестировать (объект тестирования: система, приложение, оборудование)
  2. что будете тестировать (список функций и компонент тестируемой системы)
  3. как будете тестировать (стратегия тестирования - виды тестирования и их применение по отношению к тестируемому объекту)
  4. когда будете тестировать (последовательность проведения работ: подготовка, тестирование, анализ результатов, в разрезе запланированных фаз разработки проекта)
  5. критерии начала и окончания тестирования

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

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

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

  • Мастер Тест План (Master Plan or Master Test Plan)
  • Тест План (я его называю детальный тест план)

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

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

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

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

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

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

Переработки и дополнения к статье смотрите на сайте ПроТестинг - Тест план

alexeybulat.blogspot.ru

Как создать тест план - EasyQA

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

Полезная ссылка: EasyQA YouTube канал

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

Что такое тест план?

Тест План представляет собой документ, который описывает весь объем процесса тестирования и все его параметры, такие как:

  • объект тестирования - полное описание того, что вы будете тестировать. Например, тестовыми объектами могут быть Android или iOS приложения, веб-сайт, ПО для персональных компьютер.
  • стратегия тестирования - общий план, который описывает подход к проведению тестирования цикла разработки программного обеспечения. Эта стратегия включает в себя методы тестирования новых функций, общее время и ресурсы, необходимые для реализации проекта.
  • тест процедуры - подробные инструкции, как настроить, выполнить и оценить результаты для данного теста.
  • критерии для начала и окончания тестирования - показывают нам, какие задачи должны быть завершены для определенного уровня тестирования, прежде чем QA инженер сообщит, что тестирование завершено.
  • необходимые ресурсы для тестирования - показывают сколько тестировщиков будет задействовано, какую тестовую среду они будут использовать, компютеры, мобильные телефоны и т.д.
  • предварительные условия включают в себя состояние системы и ее окружение, настройку и конфигурацию, необходимые для успешного выполнения тестирования.
  • оценка рисков с предлагаемыми способами их решения.

Как создать тест план?

Инструмент управления тестированием EasyQA позволяет создавать тест планы и тест кейсы легко, и работать с ними в понятной для пользователя среде. Нажмите на кнопку Новый тест план для создания плана тестирования.  Укажите название тест плана и его краткое описание. После того, как тест план будет создан, вы увидите изменения в окне браузера.

Create test plan in EasyQA, EasyQA test management tool, qa, testing, software

В левом окне показаны:

  • название тест плана
  • имя создателя
  • дата создания
  • число модулей и кейсов
  • дата последних изменений
  • кнопки для редактирования или удаления плана тестирования

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

EasyQA_test_plan

Как разделить тест план на модули?

В инструменте управления тестированием EasyQA  вы можете разделить ваш Тест План на модули, что делает работу с ним намного удобнее.

Например, у вас есть проект с:

  • регистрацией
  • логинизацией
  • платежами
  • или любой другой частью проекта

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

Add module to test plan, how to create test plan, EasyQA test management tool, qa, testing, software

Нажмите на кнопку Добавить модуль для его создания, введите названия модуля и его краткое описание. После того, как модуль будет создан, он отобразится в окне браузера.

 

test plan

Вы можете увидеть три модуля на этом изображении, которые вы можете изменить или удалить.

Команда, ответственная за эту часть сайта, попыталася объединить все основные особенности работы QA отдела.Зарегистрируйте новую учетную запись в EasyQA и попытайтесь создать Тест План с нами. Мы будем рады получить ваши отзывы, для улучшения нашего продукта.

geteasyqa.com

Тест-план на одну страницу

Автор: Клэр Рэклесс (Claire Reckless)

Оригинал статьи: https://dojo.ministryoftesting.com/lessons/the-one-page-test-plan

Перевод: Ольга Алифанова

Загуглите "как написать тест-план" – и утоните в куче шаблонов, обучающих материалов, маст-хэвов и всего такого прочего. Когда дело доходит до создания тест-плана, способов его сделать миллионы, и в уме нужно держать множество вещей – очень легко запутаться. Люди часто вносят в план информацию с целью "лишней не будет" – кажется, что лучше бы ее туда включить. Может, кому-то она нужна, правда? Как только план написан, прошел ревью, исправлен, финализирован и передан всем заинтересованным лицам, часто выясняется, что его никто никогда не читал.

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

Джеймс Уиттакер писал о Тест-плане за десять минут несколько лет назад, описывая вызов, который он бросил своей команде. Его целью было получить ценность тест-плана как можно быстрее. Давайте рассмотрим этот подход с другой точки зрения, но со схожей целью. Сложность будет не во времени, а в пространстве. Как уложить тест-план в одну страничку?

А зачем его вообще писать?

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

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

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

Возможно, вашему проекту тест-план и вовсе не нужен. Организация может сообщать о тестировании различными способами, вообще не прибегая к документации. Не делайте тест-план, если в нем нет смысла, просто потому, что процесс или шаблон считают, что вы должны этим заняться. Зачем писать длинные документы, пользы от которых никакой? Это же простая трата времени. Писать документацию вообще-то довольно затратно, поэтому неиспользуемая документация – это трата денег. Отсутствие письменного тест-плана не означает, что плана нет вообще. Иногда тест-план – это очень простая миссия-заявление, или майндкарта с процессом работы. Делайте так, как лучше для вашей компании.

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

Почему тест-план на одну страничку сработает

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

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

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

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

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

Идеи для презентации тест-плана

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

Документ Word

A Word document

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

Формат дашборда

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

Майнд-карты

Еще один отличный способ создания тест-плана, и даже не нужно укладываться в одну страницу А4. Создайте ноду для каждой области тест-плана и работайте с ними. Конечно, очень хочется неорганизованно бегать вокруг и создавать кучу нод, но помните о том, что майнд-карта должна хорошо читаться. Вот отличный пример из статьи Элизабет. Если вы создаете план со списками тестов, этот подход тоже может сработать. Вы даже можете использовать ментальную карту, как предвестник письменного плана, чтобы помочь вам набросать контент. Попробуйте Try XMind, Mindmup, MindMeister или Coggle.it для создания таких карт.

Эксель или любая другая таблица

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

Wiki-страничка

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

Доска для записей

Считается ли это все еще "одной страничкой"? Думаю, да. Если ваш план будет использоваться только командой, у которой эта доска перед глазами, то ее вполне достаточно – зачем вам формальный документ? Использование доски – один из самых простых способов создания тест-плана, он быстрый, дешевый, эффективный, и такой план легко обновлять. Его можно сфотографировать, чтобы не забыть, если вы не рядом с доской.

Трелло

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

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

Выбор тем для плана

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

  • Продукт или фича, которые тестируются.
  • Что будет сделано и что сделано не будет.
  • Риски.
  • Допущения.
  • Инструменты.
  • Окружения.
  • Ресурсы.
  • Оценки.

Если вы решили добавить что-то в документ, спросите себя, действительно ли это нужно и важно знать читателю? К тому же, как уже говорилось выше, спросите самого читателя! Что они хотят узнать, прочитав ваш план? Только не попадитесь в ловушку, включая в план что-то только потому, что так делалось всегда.

Если что-то не влезает, подумайте, как можно это прилинковать к внешнему источнику или ресурсу, который содержит эту информацию, например:

  • Инструмент управления тестами
  • Тест-чартеры
  • Дизайн-документ
  • Список рисков
  • Список допущений
  • Ганнт-чарты и таймлайны
  • Ссылки на исследования и прототипы
  • Приемочная документация
  • Документация по инфраструктуре
  • Связанные с вашим тест-планы для специфичных типов тестирования (к примеру, тестирования производительности и безопасности).

Сделайте так, чтобы его было легко читать

Зная, кто ваша аудитория и для чего она использует ваш тест-план, поможет вам включить в него только самое нужное. Разные люди используют план по-разному:

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

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

Учтите, что пользователи и клиенты могут не иметь доступа к внутренней документации, поэтому не смогут увидеть ваш тест-план во всей его красе. Можно получить специальное разрешение для доступа "только для чтения" для этой документации, если это необходимо.

Источники:

Про Клэр Рэклесс

Клэр Рэклесс тестировщица в Авекто и работает над ПО, обеспечивающим безопасность. Помогать людям тестировать лучше – ее страсть. Ее опыт также включает финансовый и ERP-софт. Клэр живет в Манчестере со своим мужем Робом, кошкой и собакой. Она любит бегать, когда у нее есть на это время. Клэр можно найти в Твиттере.

Обсудить на форуме

www.software-testing.ru

Артефакты, необходимые для тестирования / Хабр

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

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

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. Это называется: “Ух ты компилицо”

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

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

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

habrahabr.ru

план теста соответствия - это... Что такое план теста соответствия?

 план теста соответствия
  1. conformance test plan

 

план теста соответствия Определение протоколов тестирования, которые должны быть успешно пройдены для того, чтобы было достигнуто соответствие коммуникационному стандарту. План теста соответствия для CAN стандартизирован ISO 16845.[http://can-cia.com/fileadmin/cia/pdfs/CANdictionary-v2_ru.pdf]

Тематики

  • сети вычислительные

EN

Русско-английский словарь нормативно-технической терминологии. academic.ru. 2015.

  • план текущего обслуживания
  • план тестовых мероприятий ФНД

Смотреть что такое "план теста соответствия" в других словарях:

  • план теста соответствия — Определение протоколов тестирования, которые должны быть успешно пройдены для того, чтобы было достигнуто соответствие коммуникационному стандарту. План теста соответствия для CAN стандартизирован ISO 16845. [http://can… …   Справочник технического переводчика

  • Экспериментальные планы (experimental designs) — Э. п. служат руководством для исследователей при проведении эксперимента. Эксперименты представляют собой запланированное введение фактора в ситуацию с целью установить его связь с изменением в данной ситуации. Вводимый фактор обычно называют… …   Психологическая энциклопедия

  • Microsoft SQL Server — Тип Реляционная СУБД Разработчик Sybase, Ashton Tate, Microsoft …   Википедия

  • Германия — Федеративная Республика Германии (ФРГ), гос во в Центр. Европе. Германия (Germania) как территория, заселенная герм, племенами, впервые упоминается Пифеем из Массалии в IV в. до н. э. Позже название Германия использовалось для обозначения рим.… …   Географическая энциклопедия

  • Обследование больного — I Обследование больного Обследование больного комплекс исследований, направленных на выявление индивидуальных особенностей больного, установление диагноза болезни, обоснование рационального лечения, определение прогноза. Объем исследований при О …   Медицинская энциклопедия

  • ВАЗ-2121 — Нива …   Википедия

  • ЕВХАРИСТИЯ. ЧАСТЬ II — Е. в православной Церкви II тысячелетия Е. в Византии в XI в. К XI в. визант. богослужение приобрело почти тот вид, какой оно сохраняло в правосл. Церкви все последующее тысячелетие; в его основе лежала древняя к польская традиция, значительно… …   Православная энциклопедия

  • Египет — Арабская Республика Египет, Миср, гос во на С. В. Африки и на Синайском п ове Азии. Название Египет известно с III тыс. до н. э. Оно восходит к др. егип. Кипет черная земля , что противопоставляло долину Нила с ее плодородной почвой красной земле …   Географическая энциклопедия

  • Октябрьский (Башкортостан) — У этого термина существуют и другие значения, см. Октябрьский. Эту статью следует викифицировать. Пожалуйста, оформите её согласно правилам оформления статей …   Википедия

  • Антитела — I Антитела белки сыворотки крови и других биологических жидкостей, которые синтезируются в ответ на введение антигена и обладают способностью специфически взаимодействовать с антигеном, вызвавшим их образование, или с изолированной детерминантной …   Медицинская энциклопедия

  • Туберкулёз — I (tuberculosis; лат. tuberculum бугорок + ōsis) болезнь, вызываемая микобактериями туберкулеза. Наиболее часто поражаются органы дыхания (см. Туберкулез органов дыхания (Туберкулёз органов дыхания)), среди других органов и систем преимущественно …   Медицинская энциклопедия

normative_ru_en.academic.ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рецензия и Утверждение

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

  • Ведущий тестировщик

  • Тест менеджер (менеджер по качеству)

  • Руководитель разработки

  • Менеджер Проекта

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

Вывод

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

Тестовый случай (Test Case)

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

Под тест кейсом понимается структура вида:

Action > Expected Result > Test Result

Пример:

Action

Expected Result

Test Result (passed/failed/blocked)

Open page "login"

Login page is opened

Passed

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

Тест кейсы разделяются по ожидаемому результату на позитивные и негативные:

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

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

Структура Тестовых Случаев (Test Case Structure)

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

Каждый тест кейс должен иметь 3 части:

PreConditions

Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.

Test Case Description

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

PostConditions

Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state)

Примечание: Post Conditions не является обязательной частью. Это скорее всего - правило хорошего тона: "намусорил - убери за собой". Это особенно актуально при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов.

Пример тест кейса:

do A1, verify B1

do A2, verify B2

do A3, verify B3

В приведенном примере конечная проверка - В3. Это значит, что именно она является ключевой. Значит, A1 и А2 - это действия приводящие систему в тестопригодное состояние. А В1 и В2 - условия того, что система находится в состоянии пригодном для тестирования. Таким образом имеем:

Action

Expected Result

Test Result (passed/failed/blocked)

PreConditions

 

 

do A1

verify B1

 

do A2

verify B2

 

Test Case Description

 

 

do A3

verify B3

 

PostConditions

 

 

 

 

 

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

Теперь ответим на вопрос: "Почему данное разбиение удобно использовать?"

Ответ: конечная проверка одна, т.е. в случае если тест провален (test failed) будет сразу ясно из-за чего. Т.к. если провальными окажутся проверки В1 и/или В2, то тест кейс будет заблокирован (test blocked), из-за того, что функцию не возможно привести в тестопригодное состояние (состояние пригодное для проведения тестирования), но это не значит, что тестируемая функция не работает.

Action

Expected Result

Test Result (passed/failed/blocked)

PreConditions

 

 

do A1

verify B1

passed

do A2

verify B2

failed

Test Case Description:

do A3

verify B3

blocked

PostConditions

 

 

 

 

 

Детализация описания тест кейсов (Test Case Specification)

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

Пример тест кейса 1:

Проверка отображения страницы

Действие

Ожидаемый результат

Результат теста

Открыть страницу "Вход в систему"

- Окно "Вход в систему" открыто - Название окна - Вход в систему - Логотип компании отображается в правом верхнем углу - На форме 2 поля - Имя и Пароль - Кнопка Вход доступна - Ссылка "забыл пароль" - доступна

...

Пример тест кейса 2:

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

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

На нашем сайте вы также сможете найти пример оформления тест кейса

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

Вывод

В заключение скажу, для того чтобы команда тестирования работала сплоченно и не отвлекалась по вопросам оформления тест кейсов, у всех должен быть единый шаблон или подход к их написанию. То, что предлагаем мы - это структура PreConditions, Test Case Description, PostConditions, и уже ваше личное дела - пользоваться ей или придумать свой "велосипед.

Баг Репорт (Bug Report)

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

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

  • Структура баг репорта

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

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

Предлагаем Вам комментарий одного разработчика: - Прочитав короткое описание бага (Bug Summary), я должен понять в чем состоит проблема, прочитав детальное описание бага (Bug Description) я должен знать строку кода, которую править.

С этим можно соглашаться или не соглашаться, но смысл этого высказывания в том, что вы должны делать все так, чтобы к вам меньше было вопросов по существу описанной в баг репорте проблемы. Так как каждый возвращенный вам баг репорт со статусом "Отклонен", "Не воспроизводится", "Требуется информация" (Rejected, Can't Reproduce, More info) - это потеря времени, как вашего так и разработчика. А время, как известно - это деньги, которые мы получаем, за то что делаем нашу работу лучше всех!

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

Шаблоны и примеры документов

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

Тест План

  1. Тест план IEEE 829

  2. Тест план RUP

  3. План приемо-сдаточных испытаний RUP

  4. План проведения нагрузочного тестирования

Тест Дизайн спецификации

  1. Тест дизайн спецификация [MSF]

  2. Тест дизайн спецификация [IEEE 829-1998]

Тест Кейс

  1. Пример оформления тест кейса

Баг репорт

  1. Пример оформления баг репорта

studfiles.net


Смотрите также