Форматы
Отображать тест план можно разными способами:
- В виде традиционного документа с использованием Microsoft Excel или Microsoft Word.
- Используя методики визуализации с помощью майнд-карт, таблиц, диаграмм, коротких схем.
- Прибегнуть к помощи профессиональных инструментов – систем для управления процессами на проектах.
Преимущества схематических тест планов:
— Позволяют визуально представить запланированный процесс,
— Просты в использовании,
— Гибкие к внесению изменений,
— Содержат самую основную информацию, что позволяет в значительной степени сократить время на планирование.
Рекомендации по написанию
Что должен содержать хороший тест план:
- Что надо тестировать?
Описание объекта тестирования: системы, приложения, оборудования.
- Что будете тестировать?
Список функций и описание тестируемой системы и её компонент в отдельности.
- Как будете тестировать?
Стратегия тестирования, а именно: виды тестирования и их применение по отношению к объекту тестирования.
- Когда будете тестировать?
Последовательность проведения работ: подготовка (Test Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в разрезе запланированных фаз разработки.
- Критерии начала тестирования:
Готовность тестовой платформы (тестового стенда), законченность разработки требуемого функционала, наличие всей необходимой документации и т.д.
- Критерии окончания тестирования:
Результаты тестирования удовлетворяют критериям качества продукта: требования к количеству открытых багов выполнены, выдержка определенного периода без изменения исходного кода приложения Code Freeze (CF), выдержка определенного периода без открытия новых багов Zero Bug Bounce (ZBB) и т.д.
Ответив в своем тест плане на вышеперечисленные вопросы, можно считать, что у вас на руках уже есть хороший черновик документа по планированию тестирования.
Далее, чтобы документ приобрел более менее серьезный вид, можно дополнить его следующими пунктами:
- Окружение тестируемой системы (описание программно-аппаратных средств).
- Необходимое для тестирования оборудование и программные средства (тестовый стенд и его конфигурация, программы для автоматизированного тестирования и т.д.).
- Риски и пути их разрешения. Риски могут быть связаны с недостатками, связанными с персоналом. Например, недостаточная квалификация персонала или недостаточное количество тестировщиков.
Структура
Обычно детальный тест план занимает от пары страниц до нескольких десятков. Это если мы говорим о его визуализации в виде документа. Общая структура тест плана не зависит от его объема или формата визуализации. Достаточно заменить слово «страница» из структуры ниже на слово «ветка» и мы сможем с легкостью перенести данную структура на майнд-марту.
Структура тест-плана:
1-я страница:
— шапка (логотип и адрес компании),
— название,
— версия,
— год.
2-я страница:
— история документа, которая представляет собой таблицу изменений. Эта таблица содержит столбцы: дата, версия, описание, автор.
3-я страница:
— содержание.
4-я страница и далее:
— введение,
— виды тестирования,
— операционные системы, браузеры,
— функционал приложения,
— критерии начала тестирования,
— критерии выхода из тестирования,
— характеристики оборудования.
Предпоследняя страница:
— сколько человеко-часов планируется на различных этапах (дата начала и окончания). Например, на тест-дизайн, выполнение тестов, анализ тестирования, отчеты.
Последняя страница:
— выводы и рекомендации.
Также в тест план могут входить следующие данные:
— команда исполнителей,
— контактные данные,
— жизненный цикл бага,
— риски тестирования,
— ссылки на документы или стандарты,
— толковый словарь,
— расписание,
— обязанности,
— риски.
Рецензия и утверждение
Для увеличения ценности тест плана рекомендуется проводить его периодическое рецензирование со стороны участников проектной группы. Это можно сделать просто договорившись между собой или же реализовать в виде «процедуры утверждения». Примерный список участников проектной группы:
- Ведущий тестировщик,
- Тест менеджер (менеджер по качеству),
- Руководитель разработки,
- Менеджер проекта.
Каждый из перечисленных участников проекта перед утверждением проведет рецензию и внесет свои комментарии и предложения, которые помогут сделать тест план более полным и качественным.
Шаблоны и примеры
Каждая методология или процесс диктуют свои форматы оформления планов тестирования.
Шаблоны ниже помогут понять, какой формат больше подходит для вашего проекта и как вообще составлять тест план. А готовые решения, возможно, натолкнут вас на какие-то мысли или помогут лучше понять смысл составления данного документа.
Обычный документ
Шаблоны, которых можно придерживаться:
- Test Plan Template RUP
- Test Plan Template IEEE 829
Готовые примеры:
— Тестирование интернет-магазина 1
— Тестирование интернет-магазина 2
— Тестирование программы Блокнот
Майнд-карта (mind map)
Несколько примеров, как именно можно использовать майнд-карту
Дашборд
Подобный структурный вид позволит понять, что конкретно мы намерены тестировать. С помощью цвета можно привлечь внимание к определенным областям.
Excel или другая таблица
В таблице можно запросто отобразить любые списки тестов или описание сценариев, с которыми мы намерены работать на данном проекте.
Доска для записей – Trello
Тут не только можно будет прописать все задачи, но и следить за ходом их выполнения.
Итог
Создание тест плана повышает качество продукта за счет перечисления деталей и списка проверок, а также позволяет проанализировать, насколько успешно были проведены все этапы тестирования.
Нет четкого шаблона, по которому необходимо писать тест план. Можно взять за основы шаблоны, которые рассмотрены в статье. А можно создать свой собственный.
Какой шаблон или вид вы бы не выбрали, главное только то, что тест-план должен выполнять свою задачу. А именно, описать весь объем работ по тестированию и быть понятным и читабельным.
Когда вы запускаете новый продукт, обеспечение качества (QA) очень важно. Независимо от того, отдаете ли вы аутсорсинг команде QA или выполняете внутренние проверки, вам необходимо создать план тестирования. Это гарантирует, что в процессе обеспечения качества ничего не будет упущено.
Если вы новичок в планировании тестирования, эта статья ответит на все ваши вопросы и предоставит основу для планирования.
Что такое контроль качества?
QA — это процесс подтверждения того, что продукт соответствует стандартам качества. Это гарантирует, что продукт не имеет дефектов или неисправностей, проверяя его на соответствие согласованным спецификациям. Это также помогает выявить любые проблемы с удобством использования на ранних этапах цикла разработки. Этот бизнес-процесс переводит продукт из концептуальной стадии в стадию вывода на рынок.
Источник
Что такое план тестирования?
План тестирования — это документ, в котором описываются шаги, необходимые для выполнения необходимого тестирования. В нем также указано, кто в вашей организации будет отвечать за каждую задачу, какие функции продукта тестируются и когда проверка должна быть завершена.
Тесты делятся на несколько категорий:
Исследовательское тестирование — исследовательское тестирование больше основано на том, чтобы следовать своей интуиции и тестировать все, о чем вы можете подумать в данный момент.
Функциональное тестирование — функциональное тестирование фокусируется на функциях продукта и проверке их соответствия требованиям.
Тестирование локализации — тестирование локализации проверяет, что продукт работает должным образом с разными языками, валютой и часовыми поясами.
Тестирование производительности — тестирование производительности измеряет скорость работы продукта и выявляет любые узкие места в системе.
Тестирование безопасности — тестирование безопасности гарантирует, что ваше приложение безопасно и не представляет риска для личной информации или личных данных.
Зачем нужен план тестирования?
Что произойдет, если вы не проведете контроль качества? Что ж, тогда вы потенциально получите продукт, который никто не захочет использовать, и вы, вероятно, не заработаете денег. План тестирования поможет выявить потенциальные проблемы на ранней стадии, что сэкономит время и деньги в долгосрочной перспективе.
Как создать идеальный план тестирования?
Чтобы создать идеальный процесс тестирования, вам нужно сосредоточиться на реализации процессов. В этом разделе представлена структура для создания плана тестирования.
Шаг 1. Анализ продукта
При создании плана тестирования QA вам необходимо разбить свой продукт на более мелкие компоненты. Это позволит вам определить лучший процесс тестирования в зависимости от типа создаваемого продукта:
Источник
-
Выявите все функции вашего продукта
-
Определите, сколько тестовых сценариев необходимо для каждой функции
-
Составьте список, что должно быть проверено
Шаг 2. Проанализируйте целевую аудиторию
Еще один фактор, который следует учитывать при создании плана тестирования — это ваша целевая аудитория. Вы должны убедиться, что ставите клиента на первое место.
Шаг 3. Разработайте стратегию
Соберите все тестовые сценарии и разработайте стратегию тестирования — это поможет вам определить не только то, что нужно протестировать, но и то, когда это следует протестировать для получения оптимальных результатов.
Определите объема тестирования. Прежде чем приступить к работе, необходимо определить объем тестирования. Это включает в себя решение о том, что необходимо протестировать, кто будет проводить тестирование и когда оно должно быть завершено.
Определите типы тестирования. После того, как вы определили объем, пришло время определить, какие типы тестирования необходимо выполнить. Это включает в себя понимание того, сколько испытаний необходимо, а также риски безопасности и конфиденциальности для вашего продукта.
Разработка подхода к тестированию. После того, как вы определили объем, протестировали типы тестирования и определили сопутствующие риски, пришло время создать свой подход к тестированию.
Шаг 4. Определите цели
Следующий шаг — выяснить, каковы цели вашего тестирования. Это включает в себя определение ответственных за тестирование, решение о том, что будет тестироваться, когда оно должно быть завершено, и как будут оцениваться результаты. Вам также необходимо определить, какие функции необходимо протестировать и как они будут разбиты (например, основные и второстепенные цели). Вам следует рассмотреть возможность использования целей SMART для вашего теста обеспечения качества.
Источник
Шаг 5. Определяем критерии теста
Для каждой функции вашего продукта вам необходимо определить, какие критерии должны быть соблюдены, чтобы тест прошел успешно. Эти критерии можно разделить на две основные подкатегории.
Критерии приостановки — это условия, которые требуют временной остановки тестирования.
Критерии выхода — это условия, составляющие успешное испытание. Когда критерий выхода выполнен, тест может перейти к следующему этапу.
Шаг 6. Планируйте ресурсы
Теперь, когда у вас есть стратегия и план тестирования, пришло время определить, какие ресурсы необходимо использовать для выполнения работы. Это включает:
Люди — сколько человек необходимо для выполнения задач тестирования.
Время — сколько времени требуется для тестирования.
Инструменты — если в процессе тестирования будут использоваться какие-либо инструменты тестирования и управления задачами.
Бюджет — вам необходимо учитывать размер вашего бюджета на тестирование.
Шаг 7. Спланируйте тестовую среду
Следующим шагом является разработка и планирование среды тестирования. Это включает в себя все, от того, где будут проводиться тесты, до того, как это должно быть сделано и кто будет это делать. Вот основной список дел:
-
Определите конкретное место, где будет проходить тестирование
-
Определите типы устройств, необходимых для тестирования
-
Назначьте людей на разные части плана тестирования
Шаг 8. График и оценка
Этот шаг посвящен подготовке вашего плана к работе. Это включает в себя планирование тестов, когда они должны быть выполнены и сколько времени потребуется для их завершения.
Шаг 9. Определите результаты тестирования
И последнее, но не менее важное: необходимо определить результаты. Здесь вы сообщаете о своих выводах после завершения тестирования. Цель состоит в том, чтобы разработать план тестирования, который подходит для вашей среды и целей. Чтобы добиться оптимальных результатов, необходима четкая стратегия.
Необходимые тестовые компоненты и документы
Прежде чем приступить к реализации плана тестирования, вам необходимо создать определенные компоненты и документы.
Идентификатор плана тестирования (ID) — идентификатор плана тестирования требуется, чтобы отличить один план обеспечения качества от другого.
Сводка теста (Test summary) — краткий обзор того, что было протестировано, и были ли обнаружены какие-либо проблемы.
Тестовые элементы — все характеристики и функции, которые были протестированы.
Расписание — включает, когда тесты должны начинаться и останавливаться, кто несет ответственность, где это будет происходить и т. д.
Список функций для тестирования — этот пункт представляет собой список функций, которые необходимо протестировать. Автоматизация Excel поможет вам организовать этот список.
Список функций, которые не будут тестироваться — этот пункт представляет собой список функций, которые не будут тестироваться.
Подход – как будет проходить тестирование.
Критерии прохождения и провала — в этом пункте будут описаны критерии, которые должны быть соблюдены, чтобы тест считался успешным.
Требования к приостановке и возобновлению — этот пункт представляет собой список условий, которые требуют приостановки и/или возобновления тестирования.
Результаты тестирования — это список всех результатов, которые потребуются после завершения тестирования.
Задачи тестирования — список всех задач, которые необходимы для выполнения QA-тестирования.
Потребности — список всех элементов, необходимых для успешного завершения тестирования QA.
Смета – плановая смета времени и стоимости.
График — список всех этапов и сроков, которые необходимо выполнить.
Инструменты и ресурсы — здесь будут подробно описаны любые инструменты, которые будут использоваться для тестирования.
Потребности в персонале и обучении — это будет включать в себя, кто нужен, что они будут делать и сколько времени это займет.
Риски – включает в себя любые риски со значительными последствиями, которые необходимо учитывать.
Предположения и зависимости — включаtn предположение о том, что требуется для выполнения плана тестирования QA.
Метрики и KPI — включает все элементы, которые необходимо отслеживать.
В заключение
План тестирования является неотъемлемой частью цикла разработки продукта. Это гарантирует, что продукт готов к выпуску для целевой аудитории. Кроме того, это гарантирует, что все важные функции работают правильно. Автоматизируя бизнес-процессы, вы можете упростить процесс тестирования QA. Эта статья должна была предоставить вам всю информацию, необходимую для создания надежного плана тестирования.
Автор: Ричард Патерсон (Richard Paterson)
Оригинал статьи
Перевод: Ольга Алифанова
Многие организации планируют тестирование, не осознавая всей ценности такого планирования. Тестировщики зачастую создают тест-планы просто потому, что всегда это делали (или процессы гласят им, что так надо). Если тест-план грамотно составлен – это мощное оружие в вашем тест-арсенале.
Писать тест-план или не писать – вот в чем вопрос! Этот вопрос регулярно поднимается в обсуждениях на Software Testing Clinic. Положительный ответ на этот вопрос, в свою очередь, породит множество новых вопросов. Вот некоторые из них, которые стоит задать себе или команде:
- В какой форме тест-план должен быть?
- Какую информацию он должен включать?
- Для кого он предназначен?
Это ценные вопросы, заслуживающие подробных и взвешенных ответов. Их задают очень часто, и их необходимо задавать, чтобы убедиться, что план дает внятные ответы на различные вопросы бизнеса – к примеру, связанные с наглядностью, контролируемостью, передачей знаний или управлением изменениями.
Нужен ли вам тест-план?
Документация как коммуникационное средство существует в первую очередь потому, что стороны, нуждающиеся в доступе к знаниям, разделены временными или пространственными рамками и неспособны синхронно делиться информацией.
Если все вы находитесь в одном пространстве, и вам не требуется долгоживущее подтверждение результатов ваших переговоров, то ценность документации сомнительна. Как гласит манифест Agile, люди и взаимодействия важнее полной документации. Не то чтобы у документации не было права на жизнь, но нужно тщательно выбирать, что и когда документировать. Очень важно соблюсти грамотный баланс, а также регулярно пересматривать его, дабы убедиться, что нужды всех заинтересованных сторон эффективно удовлетворены.
Я не собираюсь указывать вам, писать вам тест-план или не писать. Только вы можете определить, требуется ли вам этот документ в вашем конкретном контексте. Я лишь хочу, чтобы вы честно спросили себя, нужен ли вам этот тест-план?
Если вам кажется, что план вам нужен, то ниже – ряд вопросов, которые стоит задать, и несколько неплохих возможных ответов на них:
Вопрос: Кто запрашивает этот документ?
Ответ: заказчик, мы обязаны предоставить его по контракту.
Вопрос: Кто будет читать этот документ?
Ответ: Менеджер проекта, которому нужно убедиться, что я собираюсь протестировать продукт как минимум на удовлетворительном уровне.
Вопрос: Что читатель получит от этого документа?
Ответ: Вместе с прочей информацией – достаточную уверенность для релиза.
Вопрос: Что может улучшиться, если я прекращу писать тест-план?
Ответ: У меня будет больше времени для действительно ценной для проекта работы, потому что я не трачу время на то, что никто не будет читать.
Вопрос: Что может ухудшиться, если я прекращу писать тест-план?
Ответ: В проекте никто не будет иметь ни малейшего понятия, что именно я тестирую.
Вопрос: Кто заметит, если я прекращу писать тест-план?
Ответ: Владелец процесса , так как создание тест-плана – это часть нашего контролируемого процесса.
Использование тест-плана как можно раньше в жизненном цикле проекта для поиска ответов на эти вопросы – это разновидность тестирования. Вы можете, например, спросить, есть ли критерии производительности, которые можно оценить и использовать для тестирования? Будет ли продукт выходить в интернет? Какие сценарии восстановления/избегания проблем должен поддерживать продукт? Задавая эти вопросы, вы подводите заинтересованных лиц к размышлениям о производительности, безопасности и устойчивости, и они займутся этим раньше, чем могли бы, не спроси вы их об этом.
Возможно, вы обязаны предоставить тест-план по контракту. В этом случае работайте совместно с заказчиком, чтобы уточнить, что он хочет узнать, и посредством какого механизма он хочет получить эту информацию.
Глаголы, а не существительные
“Планы бесполезны, но планирование бесценно” – Дуайт Эйзенхауэр.
Тест-планы статичны по своей природе, а планирование тестирования – динамический, дискурсный процесс обучения и переговоров. Документ, который никто не читает, бессмысленен. Создание того, что не принесет пользы проекту или его заинтересованным лицам, стоит денег и времени. План начнет приносить ценность только тогда, когда вы будете его использовать. Тест-план, который никто не читает, и который не информирует никого о тестировании – это трата вашего ценного времени, которое уместнее потратить на что-то более полезное.
Сбалансируйте создание подробного тест-плана и деятельность по планированию реального тестирования на период, покрытый этим планом. Если детальный план необходим, убедитесь, что вы учитываете риски, что что-то может остаться непокрытым или непротестированным. Тест-планы можно использовать как для информирования о том, что вы собираетесь тестировать, так и для того, чтобы сообщить, что вы, возможно, протестировать не сможете, если времени на это не хватит.
Заинтересованные лица – кто они?
Документы создаются для коммуникаций между людьми. Вам нужно понимать, кто эти люди в контексте связанной с тестированием информации. Кто ваши заинтересованные лица?
Если вы не уверены в ответе, определитесь, на какие вопросы о тестировании вам нужно получить ответ, а затем выясните, кто может ответить на них наилучшим образом, и спросите их об этом. Они должны быть задействованы в тестировании продукта или приложения. Объясните, почему вы задаете эти вопросы, и расскажите им, как их ответы улучшат ваше тестирование.
Тест-планом также могут пользоваться те, кому полезна информация, полученная в ходе запланированного тестирования. Найдите их, спросите, какая информация им требуется, и планируйте соответственно. Ниже – примеры заинтересованных лиц:
Тестировщики, которые хотят знать, что им предстоит тестировать в проекте. Тест-план может дать им подробную информацию об окружениях, версиях, или исходных данных. Тестировщики могут помочь вам улучшить план, основываясь на своем опыте, и добавить в него недостающую информацию и тест-подходы, о которых вы не подумали.
Менеджеры проекта хотят знать, что вы собираетесь тестировать, дабы быть уверенными в решении о выходе в релиз.
Техподдержка может рассказать об окружениях пользователей, о том, как они используют систему, и с какими проблемами сталкиваются. Эта информация может послужить основой для тестирования, покрывающего эти трудности.
Продакт-оунеры расскажут, как планируется использовать продукт, и, возможно, о случаях, когда пользователи используют его иначе. Эта информация полезна для создания профилей пользователей, помогающих в тестировании.
Продажники сообщат, какие продукты наиболее популярны, и как именно они применяются.
Если вы сомневаетесь, принадлежит ли человек к группе заинтересованных лиц, то всегда лучше включить его в процесс, нежели исключить. Никогда не знаешь, кто владеет информацией, которая может перевернуть подход к тестированию, или повлиять на его специфику. Со временем люди поймут механизмы сбора информации для тест-плана и то, как они могут помочь в его создании.
Как написать хороший тест-план: форма, структура и содержание
Тест-планы могут принимать какую угодно форму, например:
- Word-документы – зачастую формат по умолчанию, так как Word доминирует на рынке, и люди хорошо с ним знакомы. Тест-планы варьируют от одностраничного документа, кратко описывающего основные области тестирования, до длинного, соответствующего IEEE829 / IEEE29119 стандартам мануала, подробно расписывающего каждую деталь.
- Ментальные карты – отличный способ изложить тест-информацию в структурированной графичной форме. Читателю легко отслеживать структуру плана и просмотреть его на необходимом уровне детализации. Погуглите “mindmap test plans”, чтобы посмотреть на примеры.
- SharePoint / Wiki – отличные альтернативы Word, и обладают мощным инструментарием управления версиями и редактирования. Они позволяют гибко структурировать информацию, а также быстро обновлять и совместно редактировать ее.
- Web-инструменты планирования (например, Jira) можно использовать не только для планирования задач разработки. Интеграция с системами управления тестами (например, TestRail) даст команде полную картину запланированного и реального тестирования.
- Whiteboard / доски Kanban – еще один неплохой способ графически показать масштабы тестирования. Физические доски – очень прозрачный способ донести, что и как вы собираетесь тестировать.
Хороший способ начать тест-план – это одностраничный план. Он поможет вам создать краткий и информативный документ.
С точки зрения содержания тест-планы обычно создаются, чтобы зафиксировать базовые ответы на “пять почему и как” тестирования. Содержание ваших планов может меняться по ряду причин (к примеру, от релиза к релизу или от спринта к спринту). Обновляйте ваш тест-план на основании полученной от релиза к релизу (или от продукта к продукту) информации.
Используйте ваши планы эффективно, чтобы улучшить процесс тестирования. Пусть он станет репозиторием для знаний организации. Сделали ошибку в релизе? Определите, как выловить ее в следующий раз, и добавьте в шаблон плана. Обычно забываете про какой-то тип тестирования? Отметьте, что это необходимо покрыть. Добавьте заметки о бедах и горестях пользователя, а также о том, что может дать вам полезную для тестирования информацию. Тест-план может стать основой для непрерывного совершенствования планирования и стратегии тестирования.
Со временем обновляйте шаблон, чтобы поддерживать и улучшать свое планирование. Пусть тетс-план работает на вас и формой, и структурой, и содержанием. Если он не работает – меняйте его.
Как оценивать тест-план
Когда ваш план готов, пересмотрите его. Оценка тест-плана может проводиться по-разному – лично я рекомендую личную встречу для его обсуждения. Такие встречи могут дать информацию о том, что еще необходимо добавить или покрыть. Они также делают тестирование продукта, приложения или релиза прозрачным для вас и вашей команды.
Пригласите на ревью заинтересованных лиц. Максимально сократите количество участников, но убедитесь, что все нужные роли присутствуют. Предположительный кворум может состоять из четырех человек или ролей – автор тест-плана (как правило, тестировщик), другой тестировщик, менеджер проекта, и представитель техподдержки. Однако для более крупных релизов можно подключать и других заинтересованных лиц – все зависит от вашей специфики.
Пройдитесь по каждому аспекту тест-плана и обсудите все его разделы. Выслушайте обратную связь, учтите информацию, которой делятся участники встречи.
Если план одобрен необходимым большинством, он не должен оставаться статичным. Когда тестирование начнется, используйте план для отслеживания усилий команды по достижению указанных в плане целей.
“Ни один план не выдерживает встречи с противником” – Хельмут фон Мольтке Старший.
“Только изменчивость постоянна” – Гераклит.
Как обновлять тест-план
Все меняется, и ваш план должен быть открыт переменам. Подход к планированию тестирования должен позволять справляться с изменениями, разъяснять, что вы будете делать иначе, какая информация вам необходима, и какую новую информацию (и кому) вы должны предоставить.
Договоритесь о подходящей частоте пересмотра тест-плана, или же используйте для этого любой достаточно весомый повод. Пересмотры не должны быть глобальными – пусть они соответствуют масштабу перемен. Это необязательно личные встречи: попросите людей просмотреть изменения и отправить вам комментарии по почте. Пусть всем будет легко помогать вам в поддержании плана в актуальном и рабочем состоянии.
Тест-планы работают на вас
Если ваше тестирование совсем не документируется, это может вызывать вопросы, на которые трудно найти ответ. Если вы способны показать ваш одобренный, обновляющийся, регулярно пересматриваемый тест-план вместе с результатами тестирования – у вас есть куда более солидная база для обсуждения тестирования, повышающая прозрачность того, что вы делаете для улучшения качества продукта.
Тест-план может помочь вам обдумать, какая подготовительная работа вам нужна. Это особенно важно, если вы не контролируете то, что может вам понадобиться в процессе тестирования. Если вам нужны серверы, данные или доступ к инструментам, то с шансами вы будете во всеоружии, как только они будут доступны – если вы заранее все спланируете. Очень важно быть готовым к действиям, как только появится что-либо, что можно тестировать.
Эта информация также полезна во время ретроспектив и пост-мортемов, позволяя лучше принимать решения и обсуждать, как можно улучшить тестирование.
Полезный тест-план
Используйте тест-план с пользой – как механизм для поиска ответов, как катализатор обмена информацией и достижения консенсуса, и для самоподготовки. Пусть он приносит ценность вам и остальным участникам проекта. Он должен работать на вас, а не против вас, а если он этого не делает – избавьтесь от него.
Об авторе
Ричард Патерсон руководит тестированием и безопасностью приложений в SAS R&D (Шотландия). Он считает себя не только тестировщиком, но и дизайнером, лидером и создателем.
Контакты Ричарда: @rocketbootkid, LinkedIn и блог www.rcpaterson.co.uk/blog
Обсудить в форуме
Согласно стандарту IEEE 829, тест план должен состоять из 19 пунктов:
- Идентификатор тест плана
- Ссылки
- Введение
- Объекты тестирования
- Проблемы и риски
- Функции, которые нужно протестировать
- Функции, которые НЕ нужно тестировать
- Подходы
- Критерии прохождения тестов для объектов тестирования
- Критерии остановки и требования для возобновления тестирования
- Результаты тестирования
- Оставшиеся задачи тестирования
- Требования среды
- Требования по части кадров и их обучения
- Распределение обязанностей
- Расписание
- Планирование рисков и непредвиденных обстоятельств
- Утверждение
- Глоссарий
Хорошо написанная документация — залог эффективного тестирования. Она структурирует тестирование и привносит в него определенную логику. В некотором смысле документация объединяет членов команды вокруг поставленной цели, обеспечивая четкое понимание иерархии, задач и ожидаемых результатов.
Одна из важных частей документации — тест план.
В этой статье мы рассмотрим:
- что из себя представляет тест план
- чем он отличается от стратегии тестирования
- какова его роль в проекте
- какие виды тест планов бывают
- зачем команде нужен тест план
- и, самое главное, как его составить.
Прежде чем приступить к определениям и объяснениям, мы хотели бы объяснить еще один важный термин из сферы QA — артефакт тестирования.
Артефакты тестирования — побочные продукты, генерируемые в процесса тестирования ПО и использующиеся совместно с командой проекта. Проще говоря, это документы, которые помогают наладить коммуникацию между всеми участниками проекта.
А теперь давайте перейдем непосредственно к тест плану.
Что такое тест план?
Тест план — это артефакт тестирования, описывающий действия, которые будут происходить в процессе тестирования — от разработки стратегии до критериев поиска ошибок. Он также описывает логику завершения задач и оценку рисков со сценариями их разрешения.
Структура тест плана
Тест план имеет четкую структуру, установленную IEEE 829 — отраслевым стандартом для документации тестирования программ и систем. Это значит, что вы можете подготовить шаблон и использовать его для любого проекта, заполняя конкретными данными.
Создание тест плана в соответствии со стандартом IEEE 829 дает много преимуществ. Прежде всего, когда структура документа всем известна, такой документ и составлять легче, и пользоваться им проще. Стандарт IEEE 829 устраняет любые бесполезные дебаты относительно того, что включать в тест план и в каком порядке. Вместо этого тестировщики могут сосредоточиться на других, более важных вещах.
1. Идентификатор тест плана
В этом разделе мы указываем название и логотип компании, проводящей тестирование, название документа, его версию и год создания. Это титульная страница вашего тест плана.
2. Ссылки
Дальше идет история документа. Добавьте таблицу изменений со следующими столбцами:
- дата
- версия
- описание
- автор.
С помощью этой таблицы команда сможет эффективно фиксировать и отслеживать изменения в документе и процессе, который он описывает.
3. Введение
Здесь мы кратко обозначаем, что собираемся делать. Введение — это пояснительная записка для клиента. В паре предложений опишите, какие услуги предоставит команда QA и зачем. Например:
«Наша компания осуществляет функциональное и UI-тестирование для выявления ошибок в программном продукте до выпуска. Мы выполняем тщательное тестирование заявленных функциональных возможностей, чтобы помочь достичь заданных целей бизнеса для вашего программного продукта».
Включите все виды тестирования, которые вы согласились осуществить, но не входите в детали. На этом этапе достаточно обозначить все в общих чертах.
4. Объекты тестирования
Объекты тестирования — это общие функциональные возможности, которые будут протестированы. Например, установка программы, регистрация в системе, оформление заказа и т. д. По сути, это краткое содержание тест плана. В дальнейшем каждый из объектов будет описан отдельно. Список может быть расширен или сокращен в зависимости от задач или типа тестирования.
5. Проблемы и риски
В этом разделе мы описываем проблемы, с которыми команда может столкнуться во время тестирования. Например, если дедлайн установлен на летний период, разумно предположить, что люди могут уйти в отпуск, из-за чего возможны задержки. Здесь нужно упомянуть все значимые проблемы и риски: как связанные с кадрами, так и технологические аспекты.
6. Функции, которые нужно протестировать
Эта часть охватывает то, что, по мнению большинства людей, и должно быть в тест плане: подробный список функций для проверки и время, за которое они должны быть проверены.
Например, в «Объектах тестирования» мы упомянули функциональное тестирование. Тогда в функциях, которые необходимо протестировать, мы должны перечислить отдельные компоненты потока: ввод информации о доставке, выбор способа оплаты, подтверждение заказа и т. д. Что касается времени, клиент и компания, проводящая тестирование, обсуждают его до написания документации.
7. Функции, которые не нужно тестировать
Здесь вы перечисляете функции, которые тестировщики по каким-то причинам не будут тестировать. Неважно, почему вы не покрываете тестами эти фичи. Просто не забудьте указать, какие именно функции не охватываются тестированием и остаются в зоне ответственности клиента.
8. Подходы
Затем мы описываем методы и виды тестирования, которые будем применять. В этот раздел также включаются тест-кейсы. Благодаря этому клиент может получить полную картину действий по тестированию.
9. Критерии прохождения тестов
Каждый тест-кейс будет обозначен как «Pass» (пройден) или «Fail» (провален) в зависимости от двух критериев:
- Наличие и серьезность багов
- Уровень успешно выполненных требований.
И не забудьте определить критерии начала и окончания тестирования.
Критерии начала — то, что должно быть и что нужно сделать до начала тестирования. Например, вам могут понадобиться:
- законченная справочная документация
- программный продукт в том виде, в котором его будут получать клиенты
- специальные программные утилиты, конфигурационные файлы или данные
- требования к продукту и прочая документация и т.д.
Критерии начала тестирования служат для определения готовности или неготовности к тестированию. Будет полезно составить список того, что будет использоваться в качестве входных данных, и запросить материалы, необходимые для выполнения тестов.
Критерии окончания тестирования — это то, что вы считаете необходимым для завершения процесса тестирования. Тестировщики часто стараются сделать критерии окончания тестирования условием для поставки ПО, но это не реально. Это решение принимает собственник продукта (или другое ответственное лицо).
Пример критериев окончания тестирования:
«Все запланированные тесты проведены, все исправленные баги отмечены, сделаны уведомления обо всех новых обнаруженных багах. Все точки отказа (например, провал определенного набора тестов из-за неисправности железа) задокументированы».
10. Критерии остановки и требования для возобновления тестирования
Критерии остановки/возобновления описывают ситуацию, когда тестирование невозможно продолжать из-за найденных багов. Другими словами, если дела идут так плохо, что запланированные тесты нельзя провести, тестирование нужно остановить до устранения блокирующих багов.
11. Результаты тестирования
Чтобы засвидетельствовать результаты проведенной работы, мы отправляем их клиенту. Обычно результаты тестирования оформляют при помощи различных показателей: количество завершенных тестов, найденные баги и т.д. В некотором смысле эти показатели — индикаторы качества тестирования, хотя и не должны быть единственным критерием для оценки проделанной работы.
12. Оставшиеся задачи тестирования
Жизненный цикл ПО может быть непредсказуемым. Иногда проверка продукта занимает больше времени, чем первоначально ожидалось. Если времени мало, некоторые части функциональности могут оставаться непроверенными. В таком случае команда включает оставшиеся задачи в тест план. Кроме того, в этом разделе можно описать масштаб необходимой работы на случай, если все задачи будут закрыты до дедлайна.
13. Требования среды
В целом, в этом разделе описывается, что нужно для тестирования по части аппаратного обеспечения. Здесь мы перечисляем и инструменты, используемые для тестирования.
При необходимости вы можете описать какое-то особое оборудование и его функционал. Например, если в связи со спецификой проекта вам потребуется использовать комплект VR или какие-то специфические устройства, которые нужно приобрести.
14. Требования по части кадров и их обучения
Если мы получим задачу тестирования ПО для ядерных реакторов, вполне вероятно, что команда не будет полностью понимать специфику. Это, конечно, преувеличение. Но если команда должна протестировать проект из сферы, с которой они не знакомы, имеет смысл провести лекцию или краткий обучающий курс от экспертов. Это поможет тестировщикам понять особенности проекта и сделает их работу более эффективной.
15. Обязанности
В этом разделе описываются сферы ответственности каждого члена команды QA. Удобно составить таблицу с тремя столбцами — имя, должность и обязанности.
16. Расписание
Тест план должен также включать дедлайны. Команде нужно как-то оценивать скорость работы. Для этого им нужно знать, сколько времени отводится на тестирование. Если есть несколько этапов тестирования, нужно расписать их порядок и сроки.
17. Планирование рисков и непредвиденных обстоятельств
Этот раздел перекликается с п. 5 «Проблемы и риски». Здесь, в дополнение к перечню рисков, мы предоставляем разъяснения о том, как справиться с этими рисками, и что делать в случае форс-мажорных обстоятельств.
18. Утверждение
Каждый тест план должен содержать информацию о том, кто его составлял (имя, должность), и о том, кто его должен одобрить и дать команде зеленый свет на его использование.
19. Глоссарий
В этом разделе вы можете пояснить основные термины, используемые при написании тест плана. Глоссарий помогает предотвратить неправильное толкование используемой терминологии.
Виды тест планов
Несмотря на стандартную структуру, существует несколько типов тестовых планов. Они отличаются особенностями описанных задач и объемом работ. QA-команды, как правило, используют следующую классификацию:
Тест планы по уровням — планы модульного, интеграционного, системного, приемочного тестирования
Тест планы по типам — планы функционального тестирования, тестирования производительности или юзабилити, план автоматизированного тестирования и т.д.
Мастер тест план — это комплексный план тестирования. Включает высокоуровневую информацию, которая не часто меняется в ходе тестирования и требования к которой не часто пересматриваются.
По сравнению с простым тест планом мастер тест план более статичен. Это ключевое различие. Как правило, команда проекта использует один мастер тест план и несколько более подробных тест планов для разных уровней или типов тестирования, в которых описываются отдельные модули одного приложения.
Вы можете создать тест план любого типа без использования каких-то особых инструментов. Вам может повстречаться выражение «Инструменты управления тест планами», но это неточная формулировка. Тест план — это документ, и единственный инструмент, который вам нужен для управления им, это текстовый редактор. Обычно речь идет об инструментах управления тестированием, таких как TestRail, TestPad, Qmetry, KualItee и т. д.
Тест план и стратегия тестирования — в чем разница?
Многие считают, что разграничить тест план и стратегию тестирования сложно. Тем не менее, это два разных документа. Тест план более подробный и охватывает больше аспектов, чем стратегия тестирования. Последняя часто используется на организационном уровне и редко меняется. Между тем тест план более динамичен и используется на уровне проекта. Стратегия обычно является частью плана.
Существует также QA-стратегия, которая выходит за пределы тестирования и охватывает другие виды деятельности и методологии обеспечения качества.
Итоги
Как видите, тест план — объемный, часто сложный в написании, но очень важный артефакт тестирования. Он хорошо структурирует процесс тестирования, предотвращая много стрессовых ситуаций и недоразумений. Более того, тест план помогает всем членам команды быть в курсе происходящего, поскольку все заинтересованные стороны имеют к нему доступ.
Написание тест плана требует сильных аналитических навыков, внимания к деталям, а также способности продумывать действия на несколько шагов вперед. Но результат стоит свеч.
В общем, даже если написание документации кажется менее интересным, чем тестирование, только вместе они делают процесс QA эффективным.
Необходимо обозначить, что помимо аналитики и тестирования спецификации к проекту на первом этапе также создаются высокоуровневые документы по тестированию продукта. К ним можно отнести тест-план и тест-стретагию. Начнем с первого.
Тест план (Test Plan) — это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Данный документ обычно создаётся тестировщиком, либо руководителем команды тестирования.
Такой артефакт (документ) позволяет:
- Обозначить сроки тестирования;
- Обозначить ресурсы тестирования (временные, человеческие, технологические);
- Определить тестовое покрытие и метрики тестирования;
- Обозначить роли участников команды и их ответственности.
Согласно международному стандарту IEEE 829, тест-план должен содержать следующие разделы (ниже приведены не все разделы из стандарта):
1. Введение. Описание, что из себя представляет документ, для чего он предназначен;
2. Функции, которые будут протестированы;
3. Функции, которые не будут протестированы;
4. Тестовые единицы – более детальное описание тестируемых функций. Тут указывается объем тестирования функции и при необходимости проводится декомпозиция функции;
5. Тестовые подходы и тестовые техники, которые будут использоваться при тестировании;
6. Критерии тестирования (например, критерии начала/завершения и приостановки тестирования);
7. Ресурсы. Описываются человеческие, временные и технологические ресурсы;
8. Расписание — календарь с описанием основных этапов тестирования и обозначение контрольных точек, может использоваться диаграмма Ганта;
9. Роли участников проекта и их ответственности;
10. Оценка рисков — описание основных рисков, которые могут возникнуть в процессе выполнения тестирования;
11. Документация — описание документации, которая будет использоваться в процессе выполнения тестирования (баг-репорты, чек-листы, тест-кейсы);
12. Метрики — числовые характеристики показателей качества, они позволяют оценить прогресс тестирования;
13. Согласования — указываются лица, ответственные за принятие результатов тестирования, а также принимающие решение о переходе на следующий этап разработки или начале новой итерации.
Наличие тест-плана, а также его содержание зависят от особенностей проекта и компании. Зачастую тест-план содержит не все перечисленные разделы, а только ту информацию, которая используется в работе и необходима команде, либо заказчику.
Также имеется вариативность и в количестве таких тест-планов. Команда может иметь один основной тест-план на весь проект (мастер тест-план). Может иметь мастер тест-план плюс тест-планы для каждых крупных модулей/функциональностей приложения. Также могут быть локальные тест-планы (например, тест-план на спринт или тест-план на неделю/месяц).
Тем самым главное понять, что необходимый минимум это наличие мастер тест-плана. Дальнейшая его декомпозиция и уточнение хоть и необязательно, но явно упрощает дальнейший процесс тестирования. К примеру, без локальных тест-планов совершенно будет непонятно:
- Кто будет тестировать определенную функциональность в рамках спринта?
- Что необходимо протестировать в рамках спринта и в каком объеме?
- Какие критерии успешности для текущего MVP?
И так далее.
Рекомендую изучить последовательность составления тест-плана, которая отлично изложена в данной статье:
В качестве готовых примеров тест-планов я бы посоветовал данные варианты, так как в русскоязычном интернете ничего путного в открытом доступе не нашёл:
