Тестовая документация – простыми словами

Разбираемся в тестовой документации

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

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

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

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

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

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

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

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

Этот подход ищет старший грейд QA, а когда находит – описывает в стратегии тестирования. В ней подробно описывается, какие именно тесты будут выполнены в проекте.

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

Из стратегии тестирования вытекает тест-план (план тестирования). Все запланированные проверки конкретизируются по датам, ресурсам и участникам проекта. Выглядит как обычный план действий. Очень удобен для организации QA-команд любого размера.

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

Техническое задание (Technical specification)

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

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

Пользовательские истории (User Story)

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

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

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

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

Тест-кейс (Test Case)

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

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

Это совокупность тест-кейсов, сгруппированная в одну «батарею» по какому-либо признаку. Например, по хронологии использования (пост-условие одного тест-кейса является пред-условием следующего).

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

Тест-кейс или тестовый набор, который описывает возможные действия от начала пользования ПО до конца (End-to-End). Моделирует поведение какого-либо пользователя. Часто применяется при сквозном тестировании.

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

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

Баг-репорт/Отчет о дефектах (Defect Report)

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

Отчет о тестировании (Test Report)

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

Рекомендации по улучшению (Improvement Recommendations)

Опциональный документ (составляется в некоторых компаниях), в котором QA-специалисты дают советы по дальнейшему улучшению IT-продукта. Очень востребован в компаниях, работающих по принципам непрерывного совершенствования (LEAN, Kaizen, Continuous Improvement). Иногда может идти как часть отчета о тестировании. 

Резюме

Итого в тестировании имеется 14 основных документов. QA-специалисты легко в них ориентируются, потому что их содержание интуитивно понятно. Тестовая документация – это полезно и тестировщикам, и другим участникам IT-проекта.