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

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

Введение

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

Тестирование (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 заполняют именно разработчики. Это на уровне документации заставляет их детально подумать, 

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

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

Отчетность

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

Заключение

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