Как тестировать документацию. Простой алгоритм
Last updated
Was this helpful?
Last updated
Was this helpful?
Мы все знаем прелести раннего тестирования и честно стараемся ревьюить требования, архитектурные проекты и прочую документацию. Выискиваем неполные описания, инструкции, которые приведут к ошибкам и вопросы без ответов.
При этом у меня бывает, что на тестировании документации сложно сфокусироваться, особенно если это затянувшееся коллективное ревью, автор рассказывает детали, а скука обволакивает и затягивает в сон. Я попыталась себе помочь, и зафиксировала некоторые азы рецензирования. Держу их перед собой. Добавим чашку кофе, и ревью превращается в осмысленное мероприятие. Тем, кто формирует свой стиль работы, пригодится. Делюсь!
Введение
Повторенье - мать учения, пробежимся по базовым определениям, чтоб изъясняться на одном языке:
Тестирование (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. Но недавно у нас проводила тренинги , английский agile консультант, и она рассказала, что на сегодня считается успешной практикой, когда раздел Acceptance criteria заполняют именно разработчики. Это на уровне документации заставляет их детально подумать,