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

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

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

Введение

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

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

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

• соответствует ли он требованиям? 

• подходит цели? 

• какие есть дефекты (баги)?

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

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

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

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

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

1. подготовка/планирование,

2. проектирование тестов,

3. выполнение тестов,

4. отчетность,

5. завершающие действия (опционально).

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

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

1.  Готовимся — выясняем, с чем мы собираемся иметь дело: 

   1. с какой целью создается документ, его официальное определение,

   2. какие обязательные сведения в нем должны содержаться,

   3. какие сведения дополнительны, но хорошо бы иметь,

   4. находим примеры в интернете, формируем личную насмотренность.

2. Проектируем Check list:

   1. включаем в него общепринятые требования в компании,

   2. подбираем подходящие best practices с просторов сети,

   3. если есть идеи потенциальных дефектов, записываем.

3. Выполняем рецензирование:
   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, английский agile консультант, и она рассказала, что на сегодня считается успешной практикой, когда раздел Acceptance criteria заполняют именно разработчики. Это на уровне документации заставляет их детально подумать, 

• как они будут реализовать программный код,

• что непонятно, и какой информации не хватает в требованиях.

Отчетность

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

Заключение

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