# Как тестировать документацию. Простой алгоритм

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

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

Введение

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

> ***Тестирование (testing) - процесс**, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ* ***с целью определить, что*** *они* *. (Источник - ISTQB Glossary)*

Итак, **тестирование - это процесс с тремя вопросами** к тестируемому объекту

* соответствует ли он требованиям?
* подходит цели?
* какие есть дефекты (баги)?

> ***Статическое тестирование (static testing)**: тестирование артефактов разработки программного обеспечения, таких как требования, дизайн или программный код, проводимое без исполнения этих артефактов. Например, с помощью рецензирования или статического анализа. (Источник - ISTQB Glossary)*

Статический анализ выполняется специальным программным обеспечением. Мы же практикуем рецензирование.

> ***Рецензирование (review)**: оценка состояния продукта или проекта с целью установления расхождений с запланированными результатами и для выдвижения предложений по совершенствованию. (Источник - ISTQB Glossary)*

### Алгоритм тестирования документации

Здесь напомню, что [жизненный цикл тестирования](https://www.getsoftwareservice.com/software-test-life-cycle/) у нас такой:

1. подготовка/планирование,
2. проектирование тестов,
3. выполнение тестов,
4. отчетность,
5. завершающие действия (опционально).

Ревью (==рецензирование) документации - это тоже тестирование.

А значит, имеем алгоритм

1. **Готовимся - выясняем, с чем мы собираемся иметь дело**:
   1. с какой целью создается документ, его официальное определение,
   2. какие обязательные сведения в нем должны содержаться,
   3. какие сведения дополнительны, но хорошо бы иметь,
   4. находим примеры в интернете, формируем личную насмотренность.
2. **Проектируем Check list**:
   1. включаем в него общепринятые требования в компании,
   2. подбираем подходящие best practices с просторов сети,
   3. если есть идеи потенциальных дефектов, записываем.
3. **Выполняем рецензирование**:\
   \&#xNAN;***Entry criteria: Документ соответствует цели своего создания.***
   1. читаем, проверяем выполнение пунктов Check list.
4. ***Exit criteria: найдено 1-2 minor дефекта.***\
   **Формируем отчетность**:
   1. cоставляем список дефектов, рекомендаций по улучшению, нераскрытых вопросов,
   2. ранжируем в порядке серьезности и приоритетности,
   3. отправляем автору,
   4. после получения обновленного варианта возвращаемся в шаг 3.

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

***Exit criteria*** ***(критерии выхода)*** *- условия, когда тестирование считается успешно завершенным и документ можно использовать для дальнейшей работы по назначению.*

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

### Пример тестирования требований

Какой самый частый документ, который вы тестируете? Я - Jira ticket, тип Story. Задача в Джире, которая будет\_включена/уже\_включена в новый спринт - типичный объект раннего тестирования. Чем она вернее и полнее описана изначально, тем больше шансов вовремя получить качественный функционал.

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

**Подготовка**

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

Для меня Jira задача обязательно должна содержать:

* summary - короткое заглавие,
* description - описание предстоящей работы,
* user story - вид бизнес требования на разговорном языке, используется в Agile,
* acceptance сriteria - это критерии, которым должна соответствовать работа, для того, чтобы быть принятой заказчиком.

Дополнительно могут быть:

* use cases - прописанные сценарий пользования системой с новым функционалом,
* release number - номер релиза к которому он готовится,
* epic - основной тикет, который объединяет в группу другие,\
  И т.п.

**Check list**

* user story - небольшая изолированная единица функциональности, которую можно продемонстрировать,
* user story написана в формате As a < type of user >, I want < some goal > so that < some reason >,
* ticket подходит к целям спринта,
* описание функциональности понятно\
  (например, нет неизвестных терминов, сленга),
* acceptance criteria тестируемы\
  (например, система должна работать стабильно весь год или интерфейс должен быть удобный - не тестируемые критерии),
* функциональность не зависит от другой функциональности в спринте\
  (либо зависимость указана),
* требования к новому интерфейсу обозначены,
* функциональность приоритезирована,
* новый функционал не противоречит, согласуется с существующим ранее.

**Рецензирование**

Мое рецензирование jira задач не похоже на классическое книжное ревью, потому что у нас часто бывает, что Product Manager торопится и не прописывает все детали. По классическому алгоритму я должна бы собрать все замечания и вернуть ему документ на доработку. Но, когда мы говорим про Jira ticket это ненужная потеря времени, и я просто сама в процессе рецензирования дописываю недостающее. Важно, если хоть немного сомневаюсь в чем-то, прошу его проверить и подтвердить верность моих суждений, а вместе с тем адресую замечания, которые остаются. Получается рецензирование на рецензирование.

Кстати, интересный факт, я всегда считала, что заполнение jira ticket полностью обязанность Product Manager. Но недавно у нас проводила тренинги [Liz Keogh](https://twitter.com/lunivore?lang=en), английский agile консультант, и она рассказала, что на сегодня считается успешной практикой, когда раздел Acceptance criteria заполняют именно разработчики. Это на уровне документации заставляет их детально подумать,

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

**Отчетность**

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

### Заключение

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

![](https://assets.getpocket.com/web-client/_next/static/media/Focused-light.b3e4f02d.svg)

<br>
