Как тестировать документацию. Простой алгоритм
Мы все знаем прелести раннего тестирования и честно стараемся ревьюить требования, архитектурные проекты и прочую документацию. Выискиваем неполные описания, инструкции, которые приведут к ошибкам и вопросы без ответов.
При этом у меня бывает, что на тестировании документации сложно сфокусироваться, особенно если это затянувшееся коллективное ревью, автор рассказывает детали, а скука обволакивает и затягивает в сон. Я попыталась себе помочь, и зафиксировала некоторые азы рецензирования. Держу их перед собой. Добавим чашку кофе, и ревью превращается в осмысленное мероприятие. Тем, кто формирует свой стиль работы, пригодится. Делюсь!
Введение
Повторенье - мать учения, пробежимся по базовым определениям, чтоб изъясняться на одном языке:
Тестирование (testing) - процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они . (Источник - ISTQB Glossary)
Итак, тестирование - это процесс с тремя вопросами к тестируемому объекту
соответствует ли он требованиям?
подходит цели?
какие есть дефекты (баги)?
Статическое тестирование (static testing): тестирование артефактов разработки программного обеспечения, таких как требования, дизайн или программный код, проводимое без исполнения этих артефактов. Например, с помощью рецензирования или статического анализа. (Источник - ISTQB Glossary)
Статический анализ выполняется специальным программным обеспечением. Мы же практикуем рецензирование.
Рецензирование (review): оценка состояния продукта или проекта с целью установления расхождений с запланированными результатами и для выдвижения предложений по совершенствованию. (Источник - ISTQB Glossary)
Алгоритм тестирования документации
Здесь напомню, что жизненный цикл тестирования у нас такой:
подготовка/планирование,
проектирование тестов,
выполнение тестов,
отчетность,
завершающие действия (опционально).
Ревью (==рецензирование) документации - это тоже тестирование.
А значит, имеем алгоритм
Готовимся - выясняем, с чем мы собираемся иметь дело:
с какой целью создается документ, его официальное определение,
какие обязательные сведения в нем должны содержаться,
какие сведения дополнительны, но хорошо бы иметь,
находим примеры в интернете, формируем личную насмотренность.
Проектируем Check list:
включаем в него общепринятые требования в компании,
подбираем подходящие best practices с просторов сети,
если есть идеи потенциальных дефектов, записываем.
Выполняем рецензирование: Entry criteria: Документ соответствует цели своего создания.
читаем, проверяем выполнение пунктов Check list.
Exit criteria: найдено 1-2 minor дефекта. Формируем отчетность:
cоставляем список дефектов, рекомендаций по улучшению, нераскрытых вопросов,
ранжируем в порядке серьезности и приоритетности,
отправляем автору,
после получения обновленного варианта возвращаемся в шаг 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 заполняют именно разработчики. Это на уровне документации заставляет их детально подумать,
как они будут реализовать программный код,
что непонятно, и какой информации не хватает в требованиях.
Отчетность
Мне удобно, когда диалог по правкам ведется в комментариях к задаче. Если ответа долго нет, всегда можно напомнить на ежедневной встрече.
Заключение
В этой части просто повторю, что уже писала в одной из своих ранних статей. Не верю, что бывают универсальные алгоритмы, которые подойдут в любую команду, но верю, что насмотренность на чужие (даже самые простые) практики дает фундамент генерировать те способы работы, которые поднимут уровень рабочего комфорта в вашем случае. Удачи!
Last updated
