Как составить план тестирования программы

Как составить план тестирования программы

Форматы

Отображать тест план можно разными способами:

  • В виде традиционного документа с использованием Microsoft Excel или Microsoft Word.
  • Используя методики визуализации с помощью майнд-карт, таблиц, диаграмм, коротких схем.
  • Прибегнуть к помощи профессиональных инструментов – систем для управления процессами на проектах.

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

Рекомендации по написанию

Что должен содержать хороший тест план:

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

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

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

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

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

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

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

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

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

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

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

Результаты тестирования удовлетворяют критериям качества продукта: требования к количеству открытых багов выполнены, выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF), выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB) и т.д.

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

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

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

Структура

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

Структура тест-плана:

1-я страница:

— шапка (логотип и адрес компании),

— название,

— версия,

— год.

2-я страница:

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

3-я страница:

— содержание.

4-я страница и далее:

— введение,

— виды тестирования,

— операционные системы, браузеры,

— функционал приложения,

— критерии начала тестирования,

— критерии выхода из тестирования,

— характеристики оборудования.

Предпоследняя страница:

— сколько человеко-часов планируется на различных этапах (дата начала и окончания). Например, на тест-дизайн, выполнение тестов, анализ тестирования, отчеты.

Последняя страница:

— выводы и рекомендации.

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

— команда исполнителей,

— контактные данные,

— жизненный цикл бага,

— риски тестирования,

— ссылки на документы или стандарты,

— толковый словарь,

— расписание,

— обязанности,

— риски.

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

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

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

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

Шаблоны и примеры

Каждая методология или процесс диктуют свои форматы оформления планов тестирования.

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

Обычный документ

Шаблоны, которых можно придерживаться:

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

Готовые примеры:

— Тестирование интернет-магазина 1

— Тестирование интернет-магазина 2

— Тестирование программы Блокнот

Майнд-карта (mind map)

Несколько примеров, как именно можно использовать майнд-карту

Дашборд

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

Excel или другая таблица

В таблице можно запросто отобразить любые списки тестов или описание сценариев, с которыми мы намерены работать на данном проекте.

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

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

Тест план: как составлять, изображение №10

Итог

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

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

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

Источник

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

Если вы новичок в планировании тестирования, эта статья ответит на все ваши вопросы и предоставит основу для планирования.

Что такое контроль качества?

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

Источник

Что такое план тестирования?

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

Тесты делятся на несколько категорий:

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

Функциональное тестирование — функциональное тестирование фокусируется на функциях продукта и проверке их соответствия требованиям.

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

Тестирование производительности — тестирование производительности измеряет скорость работы продукта и выявляет любые узкие места в системе.

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

Зачем нужен план тестирования?

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

Как создать идеальный план тестирования?

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

Шаг 1. Анализ продукта

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

Источник

  • Выявите все функции вашего продукта

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

  • Составьте список, что должно быть проверено

Шаг 2. Проанализируйте целевую аудиторию

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

Шаг 3. Разработайте стратегию

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

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

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

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

Шаг 4. Определите цели

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

Источник

Шаг 5. Определяем критерии теста

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

Критерии приостановки — это условия, которые требуют временной остановки тестирования.

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

Шаг 6. Планируйте ресурсы

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

Люди — сколько человек необходимо для выполнения задач тестирования.

Время — сколько времени требуется для тестирования.

Инструменты — если в процессе тестирования будут использоваться какие-либо инструменты тестирования и управления задачами.

Бюджет — вам необходимо учитывать размер вашего бюджета на тестирование.

Шаг 7. Спланируйте тестовую среду

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

  • Определите конкретное место, где будет проходить тестирование

  • Определите типы устройств, необходимых для тестирования

  • Назначьте людей на разные части плана тестирования

Шаг 8. График и оценка

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

Шаг 9. Определите результаты тестирования

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

Необходимые тестовые компоненты и документы

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

Идентификатор плана тестирования (ID) — идентификатор плана тестирования требуется, чтобы отличить один план обеспечения качества от другого.

Сводка теста (Test summary) — краткий обзор того, что было протестировано, и были ли обнаружены какие-либо проблемы.

Тестовые элементы — все характеристики и функции, которые были протестированы.

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

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

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

Подход – как будет проходить тестирование.

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

Требования к приостановке и возобновлению — этот пункт представляет собой список условий, которые требуют приостановки и/или возобновления тестирования.

Результаты тестирования — это список всех результатов, которые потребуются после завершения тестирования.

Задачи тестирования — список всех задач, которые необходимы для выполнения QA-тестирования.

Потребности — список всех элементов, необходимых для успешного завершения тестирования QA.

Смета – плановая смета времени и стоимости.

График — список всех этапов и сроков, которые необходимо выполнить.

Инструменты и ресурсы — здесь будут подробно описаны любые инструменты, которые будут использоваться для тестирования.

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

Риски – включает в себя любые риски со значительными последствиями, которые необходимо учитывать.

Предположения и зависимости — включаtn предположение о том, что требуется для выполнения плана тестирования QA.

Метрики и KPI — включает все элементы, которые необходимо отслеживать.

В заключение

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

Источник

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

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

Чек-лист по составлению плана тестирования

  1. Укажите, объект тестирования, над которым необходимо работать: приложение, оборудование или система;

  2. Что конкретно необходимо тестировать: перечень компонентов и функций проверяемой системы;

  3. Особенности прохождения тестирования: определите инструменты тестирования и характер их применения по отношению к проверяемому объекту;

  4. С чего начнется и чем закончится тестирование: укажите конкретные критерии начала и окончания проверки;

  5. Определите последовательность работы: проверка перед началом, старт тестирования, сохранение результатов, анализ полученных данных;

  6. Составление инструкции по коррекции системы для отдела разработки.

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

Экспресс-план

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

  • Разделите систему на отдельные логические модули;

  • Перечислите функции в выделенных компонентах;

  • Составьте списки проверок для каждой функции по отдельности;

  • Каждый пункт списка проверяйте последовательно.

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

Пост-обработка плана

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

От аналитика часто не ждут написание пост-анализа, поскольку эту работу может выполнять дополнительный цензор внутри компании. Учитывайте это перед началом составления плана. На td {border: 1px solid #ccc;}br {mso-data-placement:same-cell;} —>курсах QA для начинающих советуют включать пост-анализ в ТЗ. Это поможет избавиться от возможных проблем во время сдачи проекта.

По каким критериям определяют качество плана тестирования

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

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

Какое программное обеспечение нужно использовать

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

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

Источник

Согласно стандарту IEEE 829, тест план должен состоять из 19 пунктов:

  • Идентификатор тест плана
  • Ссылки
  • Введение
  • Объекты тестирования
  • Проблемы и риски
  • Функции, которые нужно протестировать
  • Функции, которые НЕ нужно тестировать
  • Подходы
  • Критерии прохождения тестов для объектов тестирования
  • Критерии остановки и требования для возобновления тестирования
  • Результаты тестирования
  • Оставшиеся задачи тестирования
  • Требования среды
  • Требования по части кадров и их обучения
  • Распределение обязанностей
  • Расписание
  • Планирование рисков и непредвиденных обстоятельств
  • Утверждение
  • Глоссарий

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

Одна из важных частей документации — тест план.

В этой статье мы рассмотрим:

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

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

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

А теперь давайте перейдем непосредственно к тест плану.

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

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

Структура тест плана

Тест план имеет четкую структуру, установленную IEEE 829 — отраслевым стандартом для документации тестирования программ и систем. Это значит, что вы можете подготовить шаблон и использовать его для любого проекта, заполняя конкретными данными.

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

1. Идентификатор тест плана 

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

2. Ссылки

Дальше идет история документа. Добавьте таблицу изменений со следующими столбцами:

  • дата
  • версия
  • описание
  • автор.

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

3. Введение

Здесь мы кратко обозначаем, что собираемся делать. Введение — это пояснительная записка для клиента. В паре предложений опишите, какие услуги предоставит команда QA и зачем. Например:

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

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

4. Объекты тестирования

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

5. Проблемы и риски

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

6. Функции, которые нужно протестировать

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

Например, в «Объектах тестирования» мы упомянули функциональное тестирование. Тогда в функциях, которые необходимо протестировать, мы должны перечислить отдельные компоненты потока: ввод информации о доставке, выбор способа оплаты, подтверждение заказа и т. д. Что касается времени, клиент и компания, проводящая тестирование, обсуждают его до написания документации.

7. Функции, которые не нужно тестировать

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

8. Подходы

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

9. Критерии прохождения тестов

Каждый тест-кейс будет обозначен как «Pass» (пройден) или «Fail» (провален) в зависимости от двух критериев:

  1. Наличие и серьезность багов
  2. Уровень успешно выполненных требований.

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

Критерии начала — то, что должно быть и что нужно сделать до начала тестирования. Например, вам могут понадобиться:

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

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

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

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

«Все запланированные тесты проведены, все исправленные баги отмечены, сделаны уведомления обо всех новых обнаруженных багах. Все точки отказа (например, провал определенного набора тестов из-за неисправности железа) задокументированы».

10. Критерии остановки и требования для возобновления тестирования

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

11. Результаты тестирования

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

12. Оставшиеся задачи тестирования

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

13. Требования среды

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

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

14. Требования по части кадров и их обучения

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

15. Обязанности

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

16. Расписание

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

17. Планирование рисков и непредвиденных обстоятельств

Этот раздел перекликается с п. 5 «Проблемы и риски». Здесь, в дополнение к перечню рисков, мы предоставляем разъяснения о том, как справиться с этими рисками, и что делать в случае форс-мажорных обстоятельств.

18. Утверждение

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

19. Глоссарий

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

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

Несмотря на стандартную структуру, существует несколько типов тестовых планов. Они отличаются особенностями описанных задач и объемом работ. QA-команды, как правило, используют следующую классификацию:

Тест планы по уровням — планы модульного, интеграционного, системного, приемочного тестирования

Тест планы по типам — планы функционального тестирования, тестирования производительности или юзабилити, план автоматизированного тестирования и т.д.

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

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

Вы можете создать тест план любого типа без использования каких-то особых инструментов. Вам может повстречаться выражение «Инструменты управления тест планами», но это неточная формулировка. Тест план — это документ, и единственный инструмент, который вам нужен для управления им, это текстовый редактор. Обычно речь идет об инструментах  управления тестированием, таких как TestRail, TestPad, Qmetry, KualItee и т. д. 

Тест план и стратегия тестирования — в чем разница?

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

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

Итоги

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

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

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

Источник

Plan for the test

A Test Plan is a thorough document that outlines the test strategy, objectives, timetable, estimation, deliverables, and resources needed to accomplish software testing. The Test Plan assists us in determining the amount of work required to confirm the quality of the application being tested. The test plan is a blueprint for conducting software testing operations as a defined procedure, which the test manager closely monitors and controls.

“A test plan is a document detailing the scope, strategy, resources, and timetable of expected test activities,” according to the ISTQB definition.

Let’s look at an example/scenario of a Test Plan: You want to talk about the Test Plan with the team members at a meeting, but they aren’t interested.

What will you do in such a situation?

  • I am the manager; follow my instructions.

  • Now, let me explain why a Test Plan is necessary.

What Is a Test Plan and Why Is It Important?

There are several advantages to creating a test plan document.

  • Assist others outside the test team in understanding the nuances of testing, such as developers, business managers, and customers.

  • Our thinking is guided by the Test Plan. It’s similar to a set of rules that must be followed.

  • Test Plan documents important features such as test estimates, test scope, and Test Strategy so that it may be evaluated by the Management Team and reused for additional projects.

What is the best way to write a test plan?

You already know that the most essential duty in the Test Management Process is to create a Test Plan. To build a test plan in accordance with IEEE 829, follow the seven stages outlined below.

  • Examine the item.

  • Create a test strategy

  • Create a list of test objectives.

  • Specify the test criteria

  • Organizing Resources

  • Construct a Test Environment

  • Estimation and Schedule

  • Establish the Test Deliverables

Step 1 − Examine the item

How can you test a product if you don’t know what it is? Impossible is the answer. Before you can evaluate a product, you must first understand everything there is to know about it.

The test product is an e-commerce website. You should do research on your clients and end-users to learn about their wants and expectations from the app.

  • Who will be the target audience for the website?

  • What is the purpose of it?

  • How is it going to work?

  • What software and hardware does the product make use of?

Take a look around this website and go over the product documentation. Reviewing product documentation can assist you in comprehending all of the website’s features as well as how to use it. If you have any questions, you may interview the client, the developer, or the designer to gain additional information.

Step 2 − Create a testing strategy

In software testing, deciding on a test strategy is an important step in creating a test plan. A Test Strategy document is a high-level document that is often created by the Test Manager. This article contains the following definitions −

  • The project’s testing goals and methods for achieving them

  • Determines the amount of time and money spent on testing.

Returning to your project, you’ll need to create a test strategy for the banking website. The steps below should be followed −

Step 2.1 − Define the Testing Scope

The scope of the testing should be established before beginning any test activity. You’ll have to think about it for a while.

  • The “in scope” components of the system to be tested (hardware, software, middleware, and so on) are defined.

  • The system components that will not be tested must also be explicitly characterized as “out of scope.”

For all stakeholders, defining the scope of your testing project is critical. You will benefit from having a precise scope.

  • Give everyone on the team confidence and accurate information about the testing you’re performing.

  • Everyone on the team will know what’s being tested and what isn’t.

What criteria do you use to define the scope of your project?

You must – to determine scope.

  • Customer specifications are quite specific.

  • Budget for the project

  • Product Specification

  • Your test team’s abilities and talent

The “in scope” and “out of scope” of the tests should now be clearly defined.

According to the software requirements, the project focuses only on testing all of the website’s features and the external interface (in scope testing) Stress, performance, and logical database testing will not be performed at this time. (not within the scope of this document)

Example of a Problem

The customer has requested that you test his API. However, the project budget does not allow for this. What will you do in such a situation? In this instance, you’ll need to persuade the customer that Api Testing is extra work that will take up a lot of time and resources. Give him evidence to back up your claims. Tell him that if Api Testing is included in the scope, the budget would go up by XYZ.

The client agrees, and the new scopes and out-of-scope objects are created.

  • Functional testing and API testing are examples of in-scope things.

  • Database testing, hardware, and any other external interfaces are not included in the scope.

Step 2.2 − Determine the Testing Type 

A Testing Type is a regular test process that produces a predictable test result. Each sort of testing is designed to find a certain type of issue in a product. However, all types of testing are targeted at the same goal: “early discovery of any problems prior to releasing the product to the customer.”

The following diagram depicts the many forms of testing that are regularly used −

  • Unit Testing

  • API Testing

  • Integration Test

  • System Test

  • Install/Uninstall Testing

  • Agile Testing

For software testing, there are a plethora of testing types to choose from. Your team will not be able to handle all types of testing with appropriate effort. You, as the Test Manager, must prioritize the Testing Types.

  • Which kind of testing should be prioritized when it comes to web application testing?

  • Which kind of testing should be skipped in order to save money?

Step 2.3 − Keep a record of the risks and issues.

Risk is an unpredictable future event with a chance of occurring and the potential for loss. When the danger materializes, it becomes a ‘problem.’

You previously learned about the ‘Risk’ analysis and identified possible dangers in the project in the article Risk Analysis and Solution.

You will document those risks in the QA Test Plan.

Risk Mitigation
Members of the team lack the necessary abilities for website testing. Plan a training session for your team to improve their skills.
The project timetable is very tight; doing this job on time will be difficult. Establish a Test Priority for each test activity.
The Test Manager is a bad manager. Managers should get leadership training.
Employee productivity suffers when there is a lack of collaboration. Encourage each team member in his or her assignment and motivate them to work harder.
Cost overruns and incorrect budget estimates Prior to starting work, define the scope, pay close attention to project planning, and track and measure progress on a regular basis.

Step 2.4 Creating Test Logistics

The Test Manager should respond to the following questions in Test Logistics −

  • Who will put themselves to the test?

  • When will the test take place?

Who will put themselves to the test?

Although you may not know the precise identities of the testers who will be doing the tests, the sort of tester can be identified.

You must examine if his expertise is qualified for the work and estimate the project budget when selecting the correct member for a certain assignment.

The project may fail or be delayed if the wrong person is assigned to the assignment.

A person with the following abilities is most suited to undertake software testing −

  • Ability to comprehend the viewpoints of clients

  • A strong passion for excellence, as well as a keen eye for detail and a willingness to collaborate.

The tester is the team member who will be in charge of the test execution in your project. You can pick an in-house or outsourced tester depending on the project budget.

When will the test take place?

Associated development efforts must be linked with test activities.

When you have all of the elements shown in the accompanying diagram, you may begin testing.

Step 3 − Defining the Test Objective

The ultimate purpose and achievement of the test execution are known as the test objective. The goal of testing is to uncover as many software flaws as possible and to ensure that the product under test is bug-free before it is released.

You should do the following two steps to determine the test goals.

  • Make a list of all program aspects that need to be tested (functionality, performance, GUI, etc.).

  • Define the test’s aim or goal based on the above characteristics.

Let’s use these procedures to figure out what your testing project’s test objective is.

You can use the ‘TOP-DOWN’ technique to locate the aspects of the website that need to be tested. You split down the program under test into components and sub-components using this strategy.

Based on the features listed above, the project’s Test Objective may be defined as follows −

  • Check that the website’s functionality (Account, Deposit, etc.) works as intended in a real-world business context, with no errors or defects.

  • Check that the website’s external interface, such as the UI, is functioning properly and that it meets the needs of the consumer.

  • Examine the website’s usability. Is it possible that such features will be useful to the user?

Step 4 − Define Test Criteria

A test method or test judgment might be based on a standard or rule called test criteria. The following are two types of test criteria

Criteria for Suspension

Define the test’s crucial suspension conditions. The active test cycle will be interrupted until the suspension criteria are addressed if the suspension conditions are fulfilled during testing.

Example of a Test Plan − If your team members indicate that 40% of test cases are failing, you should halt testing until the development team has fixed all of the failed instances.

Criteria for Exit

It describes the criteria for determining if a test phase has been completed successfully. The exit criteria are the test’s intended outcomes, and they must be met before moving on to the next stage of development. For instance, all key test cases must pass 95% of the time.

pacifying a targeted run rate and pass rate are two ways to define exit criteria.

  • The run rate is the ratio of the number of test cases performed to the total number of test cases in the test specification. For example, the test specification calls for a total of 120 TCs, but the tester only completed 100 of them, resulting in a run rate of 100/120 = 0.83. (83 percent)

  • The ratio of the number of test cases passed to the number of test cases conducted is known as the pass rate. For example, out of more than 100 TCs conducted, 80 TCs passed, resulting in an 80/100 = 0.8 pass rate (80 percent).

Step 5 − Organizing Resources

A resource plan is a comprehensive list of all resources needed to fulfill a given assignment. Human resources, as well as the equipment and materials required to execute a job, are all resources.

Resource planning is a crucial aspect of test planning since it helps determine the number of resources (employees, equipment, etc.) that will be needed for the project. As a result, the Test Manager can create an accurate project plan and estimate.

This section lists the resources that are recommended for your project.

Human Resource Management

The following table depicts several members of your project team.

S.NO Member Tasks
1 Manager of Tests Oversee the entire project.
Define the project’s goals.
Obtain the necessary resources
2 Tester Identifying and characterizing suitable testing approaches, tools, and automation architecture
Examine and evaluate the Test Approach
Execute the tests, keep track of the results, and report any defects.
Depending on the project budget, testers might be in-house or outsourced.
To save money on the project, I advocate using outsourced personnel for low-skilled tasks.
3 Developer undergoing testing Execute the test cases, test program, and test suite, among other things.
4 Administrator of Tests Establishes and maintains the Test Environment as well as its assets.
SupportTester will run tests in the test environment.
5 Members of the SQA Assume responsibility for quality assurance.
Check to see if the testing procedure adheres to the specifications.

Resource for the System

You should plan the resources for testing a web application as shown in the tables below −

S.NO Resources Descriptions
1 Server Install the test web application.
If applicable, this comprises a separate web server, database server, and application server.
2 tool for testing The purpose of the testing tool is to automate testing, replicate user operations, and create test results.
You may use a variety of test tools for this project, including Selenium, QTP, and others.
3 Network To imitate the real-world company and user environment, you’ll need a network that includes both LAN and the Internet.
4 Computer The computer that people frequently use to connect to the webserver

Step 6 − Plan a test environment

What does the test environment?

A testing environment is a software and hardware configuration on which the testing team will run test cases. The test environment includes a real-world business and user environment, as well as physical surroundings like a server and a front-end operating environment.

How to Create a Testing Environment?

How can you build up a test environment for this e-commerce website, returning to your project?

You’ll need good collaboration between the Test Team and the Development Team to complete this assignment.

To fully comprehend the web application under test, you should ask the developer certain questions. Here are some questions to consider. Of course, if you need to, you may ask the other questions.

  • What is the maximum number of simultaneous connections this website can handle?

  • What are the hardware and software requirements for this website’s installation?

  • Is there anything special that the user’s machine needs to visit the website?

Step 7 − Planning and Estimation

You already used various approaches to estimate the effort required to accomplish the project in the article Test estimation. You should now add that estimate, along with the timetable, to the Test Planning.

Assume you split down the whole project into tiny jobs and include the estimation for each work in the Test Estimation phase, as shown below.

Task Member Estimate Effort
Make a test specification. Designer of Tests 170 hours of labor
Conduct a test execution Administrator and Tester 80 hours of labor
Report on the Test Tester 10 hours of labor
Delivery of a Test 20 hours of labor
Total 280 hours of labor

After that, you make a plan for completing these chores.

In project management, the term “making schedule” is commonly used. The Test Manager can utilize a solid schedule created in Test Planning as a tool for monitoring project progress and controlling cost overruns.

The Test Manager will require the following pieces of information to build the project schedule

  • Employees and project deadlines − The number of working days, the project deadline, and the availability of resources are all elements that influence the timetable.

  • Project estimation: The Test Manager knows how long it will take to complete the project based on the estimation. As a result, he will be able to create an adequate project timetable.

  • Understanding project risk allows the Test Manager to allocate adequate time to the project plan to cope with the risks.

Step 8 − Test Deliverables

A list of all the documentation, tools, and other components that must be produced and maintained in support of the testing endeavor is called Test Deliverables.

Every stage of the software development lifecycle has its own set of test deliverables.

Before the testing process, test deliverables are supplied.

  • A document containing test plans.

  • Documents containing test cases

  • Specifications for test design

During the testing, test deliverables are given.

  • Test Scripts

  • Simulators

  • Test Data

  • Test Traceability Matrix

  • Error logs and execution logs

Test Data: After the testing cycles are completed, test deliverables are supplied −

  • Reports/results of tests

  • Defect Reports

  • Installation/Test Procedures Guidelines

  • Notes about the release

Источник

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