Документации в тестировании

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

Ценность документации

Содержание

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

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

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

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

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

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

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

Опасности шаблонов и вырезания/вставки

Если ваш проект определяет, что требуется определенный документ, скажем, план тестирования системы или реестр рисков, возникает соблазн найти готовый шаблон для этих (и многих других типов документов) в Интернете.

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

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

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

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

Использование предварительно сформированного шаблона или существующего документа в качестве источника несет в себе несколько рисков:

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

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

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

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

В этом разделе мы рассмотрим различные формы тестовой документации и обсудим некоторые аспекты структурированных или гибких/непрерывных проектов по сравнению с традиционным водопадом.

Основной набор тестовых документов, как правило, делится на следующие категории:

Политика и стратегия (иногда называемая генеральным планом тестирования)
Определение теста (также известное как спецификация или планы тестирования, что сбивает с толку)
Тестовый дизайн
Тестовые случаи
Тестовые процедуры или сценарии
Выполнение теста
Расписание
Бревно
Отчет об испытаниях

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

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

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

Политика, стратегия, генеральный план тестирования

*Цель*	Политика обычно распространяется на организацию и включает подмножество тем, охватывающих все проекты. Стратегия обычно охватывает один проект (или приложение) В целом, стратегия обеспечивает принятие решений по логистическим вопросам подхода, передачи, ответственности, среды и т. д. Некоторые из этих решений могут быть приняты заранее и задокументированы в стратегии. Некоторые решения не могут быть приняты сейчас, но стратегия может задокументировать процесс, метод или информацию, которые позволят принять решения (в проекте). Для неопределенных ситуаций или незапланированных событий, когда необходимо принять решение, в стратегии будут документированы общие принципы (или процесс), которым необходимо следовать.
*Содержание*	Заинтересованные стороны, цели, ключевые риски, вызывающие обеспокоенность Принципы/подход к испытаниям, которые необходимо принять, например подход к испытаниям, основанный на оценке рисков Процесс тестирования (этапы тестирования): цели и объем критерии приемлемости методы, приемы результаты (документы) обязанность Нефункциональные/технические испытания (Тестовая) политика управления поставщиками Процесс управления инцидентами Источники тестовых данных Тестовые среды Инструменты/стратегия автоматизации Форматы/шаблоны документации
*Источники*	Заинтересованные стороны, пользователи, бизнес-аналитики, разработчики, операторы
*техническое обслуживание*	Обычно это одноразовый документ, определенный для проекта или программы.
*Соображения Agile/Continuous* Стратегия тестирования для agile-проектов с использованием Scrum, например, скорее всего, будет довольно краткой и состоять всего из нескольких страниц (если они вообще документированы). Процесс тестирования может не иметь стадий, но, скорее всего, будет определение тестирования на разных уровнях. Например: Тестирование в спринте или итерации Тестирование для релиза Тестирование системной интеграции (с другими системами или интерфейсами) Пользовательское тестирование (в спринте и/или на уровне релиза). То, как инструменты используются при тестировании разработчиками (например, с использованием BDD или TDD), скорее всего, останется недокументированным, но ожидается, что команды разработчиков будут развивать подход и поддерживать связь с другими членами группы по мере того, как они будут вносить новый код. Роль тестировщика может заключаться в интерактивном тестировании функций по мере их выпуска разработчиками или в роли тренера по тестированию для остальной части команды. Подобно использованию инструментов и/или TDD, способ работы будет меняться со временем и, возможно, никогда не будет официально задокументирован.

Определение теста (дизайн, случаи, процедуры)

*Цель*	Чтобы продемонстрировать поток или прослеживаемость между источниками знаний и тестами, которые необходимо выполнить Чтобы задокументировать покрытие (по нескольким моделям) аспектов требований, системных функций или поведения пользователя. Дать возможность заинтересованным сторонам рассмотреть объем, подход, охват и выбор, сделанный при создании тестов, которые будут применяться. Предоставлять инструкции по выполнению тестов на определенном согласованном уровне детализации.
*Содержание*	Объем тестирования – как на высоком уровне, например, характеристики, так и на более низком уровне, например, модели поведения. Покрытие тестов по сравнению с элементами в рамках (например, матрица покрытия требований или другая модель тестирования) Тестовые случаи, определяющие функции, предварительные условия, входные данные и постусловия (включая ожидаемые результаты) Тестовые процедуры, многократно используемые для выполнения выбранных тестовых случаев.
*Источники*	Заинтересованные стороны, пользователи, требования, проекты и спецификации
*техническое обслуживание*	В принципе, при фиксированных требованиях должна быть одна согласованная версия этих документов. В случае изменения требований или области применения тестировщики должны будут скорректировать документы, сохранить отслеживаемые аспекты документации и обеспечить управление конфигурацией или журнал изменений.
*Соображения Agile/Continuous* Область определения тестов — это то место, где подход к Agile наиболее заметно отличается от структурированных проектов. Потенциально тестировщики, которые сосредотачиваются на функциях по мере их выпуска, могут вообще не создавать никакой документации. Это уместно, если, например, существует общесистемная политика или устав для тестирования функций. Скорее всего, будет краткий устав для тестирования каждой функции в сеансе исследовательского тестирования. Устав похож на план на короткий период исследования. Устав обычно определяет: Объем тестового сеанса — функции, которые необходимо охватить, и/или некоторые указанные функции или поведение системы. Цель занятия — изучить определенные аспекты поведения, сосредоточиться на каком-либо риске или способе отказа, применить некоторые выбранные сценарии. Продолжительность сеанса обычно составляет 45-120 минут. Сессия обязательно ограничена по объему, но тестировщики могут свободно исследовать ее за пределами области, если они считают ее полезной. Хартия может быть направлена на изучение — узнать, что делает функция, определить конкретные варианты поведения, которые стоит протестировать, оценить, сколько тестов / сколько сеансов требуется для тестирования большой или сложной функции, чтобы понять, какие тестовые данные могут потребоваться. протестировать и тд Устав может быть сосредоточен конкретно на тестировании функции, но может выделять некоторые области, требующие большего внимания, чем другие. Инструменты и истории BDD в выбранном формате, например истории и сценарии в формате Cucumber или Gherkin, могут обеспечить прослеживаемость и содержание, которые обеспечивают схемы и процедуры тестирования. Каждый сценарий с пунктами «дано/когда/затем» идентифицирует предварительные условия, входные данные и постусловия. Они ссылаются на одну функцию, поэтому они обеспечивают минимальный тестовый пример/процедуру и прослеживаются, по крайней мере, до функций. Тесты, предназначенные для запуска с помощью инструментов, могут иметь или не иметь промежуточной документации. Команды больше полагаются на наблюдение за автоматизированными тестами и таблицами тестовых данных, используемых автоматизированными сценариями, чем на документированные проекты тестов.

Выполнение теста (расписание, журнал)

*Цель*	Чтобы указать порядок выполнения тестов Записывать статус тестов – запущен/не запущен и статус Чтобы предоставить результаты выполнения теста для отчетности
*Содержание*	Идентификатор теста, тестер, дата/время запуска, статус Для тестов, демонстрирующих аномальное поведение (необязательно): Подробная информация о выполнении теста, где детали отличаются от сценария Фактические и ожидаемые результаты Другие наблюдения, интерпретация Статус теста (дефект, аномалия настройки или среды и т. д.) Идентификатор сообщения о наблюдении или дефекте (при необходимости)
*Источники*	Инвентаризация тестовых случаев/процедур, тестировщики
*техническое обслуживание*	График будет меняться в зависимости от объема испытаний и процедур, которые будут изменены, удалены или добавлены в план. Тесты, скорее всего, будут запускаться несколько раз в качестве повторных или регрессионных тестов. Журнал должен содержать полную историю всех тестов в объеме.
*Agile/непрерывные соображения* Если гибкие/непрерывные проекты не обязывают к документам определения тестов, они в некоторой степени компенсируют это, поощряя тестировщиков вести более качественные журналы выполнения тестов. Там, где тестирование выполняется сеансами в соответствии с чартерами, ожидается, что тестировщик будет вести хорошие записи тестов, которые они проводят. Существует несколько специализированных инструментов для протоколирования тестов, которые представляют собой нечто большее, чем записные книжки, поэтому многие тестировщики используют простые текстовые редакторы, блокноты или записные книжки. Журналы, как правило, используются для записи всех значительных действий и наблюдений в сеансах, пока они их выполняют. Типичный журнал исследовательского тестирования должен содержать такие аспекты, как: Структура исследуемых объектов (карта территории) Наблюдения, вопросы, касающиеся особенностей, изученных на сессии Модели, списки, таблицы тестовых заданий и тестовых идей Запуск тестов, снятых достаточно подробно, чтобы их можно было воспроизвести Обнаружены аномалии — сбои, сомнительное поведение, медленные ответы, плохое взаимодействие с пользователем и т. д. Время, затрачиваемое на исследование, настройку теста, тестирование, расследование, регистрацию ошибок, повторное тестирование, регрессионное тестирование, непроизводительное время. Дата/время входа Когда тестировщики регистрируют свою активность в сеансе в ведении заметок или других инструментах, они используют некоторую разметку или другой предметно-ориентированный язык для структурирования своих заметок. Их можно проанализировать с помощью простых внутренних инструментов, чтобы предоставить сводку активности для использования в отчете о тестировании. Тесты, выполняемые инструментами (проприетарными или открытыми), автоматически ведут журналы. Обычно к этим журналам можно обращаться с помощью инструмента или написанных пользователем процедур.

Отчет об испытаниях

*Цель*	Чтобы сообщить результаты этапа тестирования, выбранных тестов или сеанса тестирования Может также применяться к техническим требованиям или нефункциональным действиям по тестированию, и в этом случае содержимое будет отличаться, чтобы соответствовать цели тестирования. Частично информировать заинтересованные стороны, чтобы они могли принять решение о приемке или выпуске системы или подсистемы.
*Содержание*	Время начала/окончания и продолжительность теста Тестовая среда Тестируемые версии программного обеспечения и системы Цели и объем тестирования (из стратегии тестирования, определения теста) Краткое изложение результатов Функции, которые считаются работающими в соответствии с требованиями Риски, которые считаются устраненными Выдающиеся тесты значимости (неудачные или заблокированные) Возможности частично и не тестировались Риски частично или не учтены. Подробная информация о результатах тестирования с выводом из журналов тестирования и т. д. Статус обходного пути для нерешенных аномалий Тестовые анализы Прогресс и статус тестирования с течением времени Статистика инцидентов
*Источники*	Стратегия тестирования, определения тестов, журнал тестирования, отчеты об инцидентах Большая часть содержимого отчета о тестировании будет состоять из инструментов, используемых для записи определений тестирования, журнала тестирования и журнала инцидентов или дефектов.
*техническое обслуживание*	Это моментальный снимок фазы выполнения теста, который не поддерживается.
*Agile/постоянные соображения*Цель отчета о тестировании в гибком проекте может охватывать одну итерацию или спринт, тестирование для выпуска или этап тестирования более высокого уровня, такой как интеграция или общая приемка системы. Как бы то ни было, цель неизменна. Большая часть содержания отчета о тестировании будет из инструментов или заметок тестировщиков. Описательная сводка результатов пишется руководителем тестирования или тестировщиком для этапа тестирования меньшего масштаба. Как обычно, отчет, скорее всего, будет менее формальным, и в нем, вероятно, будет меньше необработанных данных, которые могли бы лечь в основу сложного анализа. Конечно, во время итерации ход итерации с точки зрения функций или историй, доставленных, протестированных и одобренных пользователями, может регистрироваться в инструменте или на общедоступной доске KanBan. Этим способом, заинтересованные стороны информируются о прогрессе на протяжении всей итерации, и меньше необходимости в официальном отчете в конце периода тестирования. Видимость прогресса является ключевой задачей для agile-команд. Например, при регулярных, возможно, ежедневных митингах вокруг Scrum-доски члены команды постоянно делятся своим пониманием прогресса, задают вопросы друг другу и постоянно согласовывают позицию (и следующие шаги). Таким образом, формальный отчет об испытаниях может никогда не потребоваться, потому что команда всегда информирована и актуальна. Если тестировщики ведут письменные заметки о своих действиях во время сеанса, то нет доступных анализируемых данных для представления автоматических отчетов, поэтому отчеты о сеансе и ходе выполнения могут быть представлены публично, визуально. Это требует высокой степени дисциплины и хороших коммуникативных навыков со стороны тестировщиков.

Некоторые советы

Тема документации в проектах является деликатной как для тестировщиков, так и для других членов команды проекта.

Большинство людей считают написание документации рутиной.

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

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

Ну наконец то

Необходимость — мать документации.

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

Лучше представить заинтересованному лицу чистый лист бумаги и вместе добавить темы, которые им нужно увидеть в документе, и работать с ними. Может быть, они просят кучу контента, но то, что им на самом деле нужно, довольно простое. Продолжайте спрашивать: «Зачем им это нужно?»