Тестовая документация

Виды тестовой документации

Тестовая поставка (test deliverable)

Любой тестовый (рабочий) продукт, который должен быть доставлен кому-то другому, кроме автора тестового (рабочего) продукта. (ISTQB)

Тестовое обеспечение (testware)

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

Артефакт (artifact)

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

Результаты тестирования (Test Deliverables)

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

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

По Куликову документацию можно разделить на два больших вида в зависимости от времени и места ее использования:

Продуктная документация (product documentation, development documentation) используется проектной командой во время разработки и поддержки продукта. Она включает:
- План проекта (project management plan) и в том числе тестовый план (test plan);
- Требования к программному продукту (product requirements document, PRD) и функциональные спецификации (functional specifications document, FSD; software requirements specification, SRS);
- Архитектуру и дизайн (architecture and design);
- Тест-кейсы и наборы тест-кейсов (test cases, test suites);
- Технические спецификации (technical specifications), такие как схемы баз данных, описания алгоритмов, интерфейсов и т.д.;
Проектная документация (project documentation) включает в себя как продуктную документацию, так и некоторые дополнительные виды документации и используется не только на стадии разработки, но и на более ранних и поздних стадиях (например, на стадии внедрения и эксплуатации). Она включает:
- Пользовательскую и сопроводительную документацию (user and accompanying documentation), такую как встроенная помощь, руководство по установке и использованию, лицензионные соглашения и т.д.;
- Маркетинговую документацию (market requirements document, MRD), которую представители разработчика или заказчика используют как на начальных этапах (для уточнения сути и концепции проекта), так и на финальных этапах развития проекта (для продвижения продукта на рынке).

Можно встретить и другие классификации.

Внутренняя документация подробно описывает процесс разработки продукта, например стандарты, проектную документацию, заметки о деловой переписке и т. д. Внешняя документация относится к документам, которые подробно описывают сам продукт, например, Системная документация и Пользовательская документация.
К внешней документации можно отнести Test policy, Test strategy, различные отчеты, Defect Report, Замечание, Запрос на изменение (улучшение), к внутренней всё от чеклиста до плана тестирования, тестовые данные и т.п. Пользовательская документация (User documentation) - это вся документация, которая будет передана конечному пользователю в комплекте с ПО.

Политика качества (Quality policy)

Отражает видение компании в отношении производства и поставки качественного продукта;

Политика тестирования (Test policy)

Документ высокого уровня, в котором описаны принципы, методы и все важные цели тестирования в организации;

Стратегия тестирования (Test strategy)

Статический документ документ высокого уровня (high-level), обычно разрабатываемый менеджером проекта (project manager). Это документ, который отражает подход к тестированию продукта и достижению целей. Обычно он выводится из Спецификации бизнес-требований (BRS - Business Requirement Specification). На основе стратегии тестирования готовится План тестирования;

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

Документ, который содержит план всех действий по тестированию, которые необходимо выполнить для получения качественного продукта. План тестирования является производным от описания продукта (Product Description), SRS (Software requirements specification) или сценариев использования (Use Case) для всех будущих действий проекта. Обычно его готовит руководитель тестирования или менеджер по тестированию (Test Lead or Test Manager);

Отчет об оценке усилий (Effort Estimation Report)

В этом отчете группы тестирования оценивают усилия для завершения процесса тестирования;

Сценарий тестирования (Test Scenario)

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

Тестовый набор/комплект** (Test Suite)

“Комплект тестовых наборов для исследуемого компонента или системы, в котором обычно постусловие одного теста используется в качестве предусловия для последующего.” (ISTQB)_. Некоторый набор формализованных Test case, объединенных между собой по общему логическому признаку;

Тестовый случай/пример (Test case)

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

Тест сурвей (Test Survey)

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

Чек-лист (Check List)

Перечень формализованных Test case в упрощенном виде удобном для проведения проверок, часто только список из заголовков кейсов;

Матрица прослеживаемости требований (Requirements Traceability Matrix)

Документ, который соотносит требования с тестовыми примерами;

Тестовые данные (Test Data)

Данные, которые существуют (например, в базе данных) на начало выполнения теста и влияют на работу, или же испытывают влияние со стороны тестируемой системы или компонента.” (ISTQB). “Созданные или отобранные данные, удовлетворяющие входным требованиям для выполнения одного или более контрольных примеров, которые могут быть определены в плане тестирования, контрольном примере или процедуре тестирования. (ГОСТ 56920)

Отчет о дефектах (Defect Report)

Цель документа заключается в том, чтобы зафиксировать факт ошибки и передать разработчикам подробную информацию о ней;

Отчет о выполнении теста (Test Execution Report)

Содержит результаты тестирования и сводку действий по выполнению тестов;

Сводный отчет о тестировании (Test summary report)

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

Графики и метрики (Graphs and Metrics)

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

Отчет о тестовых инцидентах (Test incident report)

Содержит все инциденты, разрешенные или неразрешенные, обнаруженные во время тестирования;

Отчет о завершении тестирования (Test closure report)

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

Отчет о статусе тестирования (Test status report)

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

Еженедельный отчет о статусе (менеджер проекта для клиента)

Weekly status report похож на отчет о статусе тестирования, но генерируется еженедельно;

Отчет об улучшении (?Enhancement report)

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

Запрос на модификацию (Modification Request)

Запрос клиента на изменение существующей функциональности;

Примечания к выпуску (Release Note)

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

Руководство по установке / настройке (Installation/configuration guide)

Это руководство помогает установить или настроить компоненты, из которых состоит система, и ее аппаратные и программные требования;

Руководство пользователя (User guide)

это руководство помогает конечному пользователю понять как пользоваться продуктом;

Документы требований**.

Источник:

Test Deliverables in Software Testing - Detailed Explanation

Доп. материал:

виды тестовой документации

https://www.freecodecamp.org/news/how-to-write-qa-documentation-that-will-work/

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