Что такое спецификация в тестировании

Теория тестирования ПО просто и понятно

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

ОСНОВНЫЕ ТЕРМИНЫ

Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:

планированием работ (Test Management)

проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.

анализом результатов (Test Analysis)

Основные цели тестирования

техническая: предоставление актуальной информации о состоянии продукта на данный момент.

коммерческая: повышение лояльности к компании и продукту, т.к. любой обнаруженный дефект негативно влияет на доверие пользователей.

Верификация (verification)

Валидация (validation)

Соответствие продукта требованиям (спецификации)

Соответствие продукта потребностям пользователей

Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.

Следует уметь различать, что:

Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).

Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.

Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).

Жизненный цикл бага

Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.

Градация Серьезности дефекта

Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.

НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА

Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.

Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.

Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).

Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.

Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить общее количество тест-кейсов. Используется для тестирования, например, фильтров, сортировок. Этот интересный метод заслуживает отдельного внимания и более подробно рассматривается в статье по ссылке (в конце которой упоминаются инструменты для автоматизации применения PT ).

Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.

Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований, которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.

Пример таблицы принятия решений

ВИДЫ ТЕСТИРОВАНИЯ

Классификация по целям

Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.

Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.

Тестирование пользовательского интерфейса (GUI Testing) — проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).

Тестирование удобства использования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Состоит из: UX — что испытывает пользователь во время использования цифрового продукта, и UI — инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».

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

Инсталляционное тестирование (installation testing) направленно на проверку успешной установки и настройки, а также обновления или удаления приложения.

Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)

Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться, т.е. обеспечивать сохранность и целостность данных, после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).

Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.

Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.

Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).

Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.

Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса (например, повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера) и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса.

Объемное тестирование (Volume Testing) — тестирование, которое проводится для получения оценки производительности при увеличении объемов данных в базе данных приложения.

Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.

Классификация по позитивности сценария

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

Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.

Классификация по знанию системы

Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.

Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).

Тестирование чёрного ящика (Black Box) — метод тестирования ПО, также известный как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, которая не предполагает доступа (полного или частичного) к системе, т.е. основывается на работе исключительно с внешним интерфейсом тестируемой системы.

Классификация по исполнителям тестирования

Альфа-тестирование — является ранней версией программного продукта, тестирование которой проводится внутри организации-разработчика; может быть вероятно частичное привлечение конечных пользователей.

Бета-тестирование — практически готовое ПО, выпускаемое для ограниченного количества пользователей, разрабатывается в первую очередь для тестирования конечными пользователями и получения отзывов клиентов о продукте для внесения соответствующих изменений.

Классификация по уровню тестирования

Модульное (компонентное) тестирование (Unit Testing) проводится самими разработчиками, т.к. предполагает полный доступ к коду, для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде, проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

Подходы к интеграционному тестированию

Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.

Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами.

Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.

Системное тестирование (System Testing) — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.

Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.

Классификация по исполнению кода

Статическое тестирование — процесс тестирования, который проводится для верификации практически любого артефакта разработки. Например, путем анализа кода (code review). Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к этому виду относится тестирование требований, спецификаций и прочей документации.

Динамическое тестирование проводится на работающей системе, т.е. с осуществлением запуска программного кода приложения.

Классификация по хронологии выполнения

Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.

Регрессионное тестирование (regression testing) — это тестирование после внесения изменений в код приложения (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.

Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

ДОКУМЕНТАЦИЯ

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

Основные атрибуты требований:

Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.

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

Недвусмысленность — требование должно содержать однозначные формулировки.

Проверяемость (тестопригодность) — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.

Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).

Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:

Что нужно тестировать?

Как будет проводиться тестирование?

Когда будет проводиться тестирование?

Критерии начала тестирования.

Критерии окончания тестирования.

Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.

Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.

Источник

Фундаментальная теория тестирования

В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.

Перейдем к основным понятиям

Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.

Для чего проводится тестирование ПО?

Принципы тестирования

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

К задачам контроля качества относятся:

К задачам обеспечения качества относятся:

Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.

Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.

Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:

Этапы тестирования:

Программный продукт проходит следующие стадии:

Требования

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

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

Жизненный цикл бага

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

Градация Приоритета дефекта (Priority):

Тестовые среды

Основные фазы тестирования

Основные виды тестирования ПО

Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.

Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:

Методы тестирования

Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Согласно ISTQB, тестирование белого ящика — это:

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

Согласно ISTQB, тестирование черного ящика — это:

Тестовая документация

Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.

Тест план должен отвечать на следующие вопросы:

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

Источник

Визуальные спецификации

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

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

Agile движение имеет свой взгляд на спецификации. Наиболее экстремальное крыло выражает свои взгляды так:

Как пользователь
Я хочу добавить новую задачу быстро
Чтобы сэкономить время и не потерять контекст

Что удивительно, такой подход работает. В определенных случаях. Необходимо выполнение всех условий ниже:

На другом конце спектра находятся немногочисленные индивидуумы, которые готовы тратить четвертую часть свой жизни на создание исчерпывающей документации по проекту. Они продумывают каждую мелочь, подробно описывают каждое поле в форме, занудно углубляются во все негативные сценарии и точно знают, как должна реагировать система на беспорядочное кликание мышкой, попытку ввести имя на языке SQL и прямое попадание метеорита в дата-центр.

Спецификации и программисты

Многие программисты не любят спецификации. Введем определение, пусть это будут “Программисты класса 1”. Они твердо знают, как система должна работать, на какие сценарии можно выдавать сообщения “Unknown error” или “You can’t do that” и где нужно срезать углы, чтобы меньше возиться с неинтересными вещами.

Наличие спецификации воспринимается как ограничение свободы творчества и выражение недоверия: “ха, можно подумать, мы не знаем, как лучше сделать эту фичу”. Поэтому программисты класса 1 не любят читать спецификации. Они могут их сканировать, смотреть на них и разглядывать картинки, но они не будут их читать.

Программисты класса 2 — совершенно другие люди. Если у фичи нет спецификации, они впадают в грустное состояние и предвкушают много переделок, запоздалых споров и плохих решений. Они знают, что их ждет много прямых контактов с тестировщиками в попытках ввести определение бага. Они ясно видят, сколько им придется потратить времени, в попытках словить управляющего продуктом и лестью или обманом выудить из него ответы на десяток вопросов.

Распределение программистов по типам. Большинство нормально относится к спецификациям.

Программисты класса 2 читают спецификацию от корки до корки, методично ее переваривают и задают убийственно точные вопросы.

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

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

Спецификации и тестировщики

У тестировщиков жизнь тяжелая. Отсутствие спецификации превращает процесс тестирования в медленную пытку на выносливость и стрессоустойчивость. В принципе баг — это несоответствие поведения системы спецификации. Когда спецификации нет, то и багов нет. Чем с удовольствием пользуются корыстные программисты.

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

Программисты почему-то могут позволить себе не читать спецификации, а вот тестировщики — нет. Им придется дотошно разбираться в любом мусоре, который набросал управляющий продуктом из своей головы за максимально короткое время. Им придется методично перечитывать все, искать нестыковки и неясности. И этим могут пользоваться ленивые управляющие продуктом. Чего, собственно, возиться со спецификацией, если тестировщик прочтет все и попытается исправить все ошибки.

Свойства спецификаций

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

(Не)полнота

Согласно Гёделю, нет никакого смысла стремиться к полной спецификации. Любая полная спецификация противоречива. Так что надо смириться с тем, что любая спецификация будет неполна. Максимум, на что можно надеяться, это на непротиворечивость.

На этом месте можно махнуть рукой и сказать, что раз полной спецификации мы сделать не сможем, чего тут вообще возиться. Однако разумные попытки приблизиться к полноте дают очень много плюсов, и всего два минуса: время и силы.

Поиск баланса задача не простая и однозначного ответа тут нет, очень многое зависит от контекста. Однако ясно, что если при старте разработки программисты приходят к управляющему продуктом с тремя и более вопросами, то можно смело лишать управляющего доступа к свежим фруктам и кофе, чтобы не отвлекался, а занялся делом.

Так насколько полными должны быть спецификации? Ответ довольно прост. Сначала спецификация требования должна ограничиваться несколькими предложениями. Перед началом разработки она должна быть настолько подробной, насколько это разумно с точки зрения временных затрат.

Детализация спецификации в зависимости фазы разработки юзер стори. На первых порах достаточно пары предложений. В начале реальной имплементации нужна полная спецификация.

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

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

Типичный ход разработки фичи с отсутствующей (неполной) спецификацией. Выявление новых проблем увеличивает объем работ. Требуются героические усилия для завершения фичи.

Мозгодрочка

Есть люди, которые любят казаться чрезвычайно умными, хотя это слабо коррелирует с их реальными способностями. Они с радостью употребляют слова типа “корреляция”, “дивергенция” и “Гёдель”.

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

Мало того, что их спецификации читать просто скучно, так нужно тратить драгоценные калории энергии на попытки понять, что же имеется ввиду на самом деле под фразой “пользователь осуществляет операцию перехода на следующий раздел клиентского приложения путем двойного нажатия на левую кнопку манипулятора типа мышь”.

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

Размер

Может показаться, что размер коррелирует (черт!) с полнотой. Однако, наполнять спецификацию водой — явно не самая хорошая идея. Наполняйте ее смыслом и жизнью.

Методы донесения идей

Какие вообще бывают методы объяснения своих мыслей? Давайте пройдемся по ним.

Псевдо-Нарративные

Очень многие разработчики спецификаций обожают структурность. Самые доступные структурные элементы: таблицы и списки. Зачастую, в спецификации больше ничего и нет: списки, списки, вложенные списки, вложенные списки вложенные в списки… и таблицы.

С одной стороны, таблицы действительно помогают хорошо воспринимать… табличные данные. Но маловерятно, что любую спецификацию можно представить в виде табличных данных. Хотя некоторым это удается:

Пример великолепного использования таблиц.

Пример убедительного использования списков.

Такое использование текста портит карму. Не делайте так.

Нарративные

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

История про Васю и Батч DnD
Вася планирует следующую итерацию. Он смотрит на доску, заполненную карточками. Слева он замечает список карточек в бэклоге. Вася читает названия юзер сторей, и понимает, что три первые стори надо обязательно сделать в следующем релизе. Вася привычно прижимает Ctrl и кликает по каждой карточке, карточки призывно желтеют в ответ. Вася хватает первую карточку и начинает тащить ее в правую колонку. Карточки красиво складываются в одну, увенчанную эффектной цифрой 3 в правом углу. Вася перемещает карточки в нужную колонку, но пока еще не отпускает их, наслаждаясь тем, как колонка желтеет карточкам в ответ.

Счастливый конец
Вася отпускает карточку, которая распадается на три. Раз дело сделано, колонка возвращает себе привычный серый цвет. Карточки моргают дважды, уверяя, что они уже тут освоились, и тоже становятся обычными. Вася счастлив.

Несчастливый конец
Вася отпускает карточку и вдруг видит тревожное красное сообщение “У тебя, дружище, нет прав на изменение итерации для юзер стори. Попроси админа, может даст”. Карточки прыгают обратно в левую колонку и остаются желтыми, чтобы Вася мог сполна почувствовать собственное ничтожество по сравнению разработчиками системы.

Кажется, читать такую спецификацию гораздо интереснее, чем сухой язык таблиц и списков. Она раскрывает мотивацию, дает почувствовать и представить решение. Васю становится просто жалко и хочется ему как-то помочь. Может быть, дать возможность Васе пингануть админа прямо сейчас одним нажатием на ссылку? Или сделать превентивный показ ошибки еще до того, как Вася отпустил карточки?

К сожалению, мало кто хочет тратить время на нормальный связный текст. Гораздо проще засунуть в документ таблицу и заполнить ее колонки сухими глаголами.

Может быть, нарративная спецификация недостаточно формальна. Но если ее дополнить правильными картинками, то все будет хорошо.

Behavior-Driven Development имеет довольно любопытный формат для описания требований. Фактически, мы описываем критерии приемки фичи. Если все критерии проходят, фича считается готовой. Вот один из примеров спецификации в формате BDD:

As a Scrum Master I want to see Release BD Chart drawn by weeks

As a Scrum Master
I want to see Release BD Chart drawn by weeks
When Iterations practice is disabled
So that I can benefit from BD chart

Что же хорошего и плохого в таком подходе? Из хорошего можно выделить единый формат. К нему привыкаешь, и после нескольких недель уже как-то сразу начинаешь писать спецификацию в таком формате, не особенно включая мозг. Есть / Сделали / Получили — четкий формат реакции на любое действие пользователя.

Кроме того, такую спецификацию можно автоматизировать. Конечно, придется договориться о чуть более строгом формате, но в принципе управляющий продуктом способен выдавать сценарии, которые будут сразу же превращаться в автоматические тесты. Исполняемые спецификации — мечта любого разработчика.

Минусов тоже вполне достаточно. Во-первых, все, что хорошо транслируется в автоматические тесты, обычно плохо транслируется в человеческий мозг. Спецификации в первую очередь пишутся для людей, а не для тестов. Воспринимать формат BDD достаточно тяжело. Особенно уныло смотрится спек из десятка сценариев. Ну ничем не лучше списка или таблицы, а зачастую и хуже, потому что в нем присутствует очень много повторений Given, When, Then. Эти повторения вносят ненужный шум, затрудняя восприятие полезных сигналов.

BDD сценарии хорошо подходят для описания взаимодействия системы с пользователем, но совершенно не подходят для нефункциональных требований и элементов интерфейса.

При использовании BDD практически невозможно охватить сразу всю фичу целиком.

Наброски интерфейса

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

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

Набросок системы отчетов в Targetprocess 3.

Обычно рисуют интерфейс и, гораздо реже, что-то более глубокое. Можно ли сделать спек целиком из скетчей? Вполне, но не факт, что это лучшее применение ваших способностей художника.

Набросок разрешенных назначений задач на людей в зависимости от роли, проекта и команды в Targetprocess 3

У скетчей есть серьезный недостаток — отсутствие деталей. По определению от скетча не стоит ожидать всяких мелочей, он дает общую картину, общее представление, но вызывает много дополнительных вопросов на стадии разработки фичи.

Набросок таймлайнов в Targetprocess 3.

Я лично скетчи очень люблю.

Детальный дизайн

С дизайном все просто — он должен быть готов до стадии разработки. Не стоит надеяться, что дизайнер сможет за пару дней склепать что-то такое, за что ему самому будет не стыдно. Дизайнерам нужно время. Обычно много. Дизайн нужно начинать делать задолго до того, как фича попадет в разработку.

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

Готовый дизайн таймланов в Targetprocess 3

Итак, законченный дизайн должен быть непременным атрибутом любой спецификации. Может ли дизайн заменить всю спецификацию? К сожалению, нет. Обычно в дизайне не показаны все состояния системы, не описаны потоки взаимодействий, не проработаны все сценарии. Дизайн статичен. А нам нужна динамика. Можно и в дизайне показывать динамику:

Три варианта изменения карточки требования с течением времени

Но это долго и сложно. Лишь избранные способны так скрупулезно прорабатывать варианты.

Раскадровки / Storyboards

Раскадровки любят режиссеры. В общем-то это просто набор отдельных ключевых кадров какой-то сцены.

Типичная раскадровка к непонятному фильму.

Не обязательно быть великим художником, чтобы рисовать раскадровки. Достаточно уметь проводить кривые линии под произвольными углами:

Типичная быстрая раскадровка.

В нашей индустрии раскадровка — это набор отдельных состояний системы.

Раскадровки довольно компактны и позволяют понять, какие вообще состояния есть. Отличные раскадровки еще и показывают, как в эти состояния переходить.

Раскадровка быстрого добавления задач в Targetprocess 3 с альтернативным сценарием.

В отличие от статических скетчей интерфейса, раскадровки показывают взаимодействие пользователя с системой. Если взаимодействие сложное, то и раскадровки получаются сложными. Это знак подумать еще немного, вдруг можно сделать проще.

Потоки / Flows

Для хорошего понимания требования надо знать, какие действия может делать пользователь и в какие состояния может переходить система. BDD сценарии в целом дают такое понимание, но их нужно внимательно читать и транслировать в образы, понятные программистам класса 1. А это сложно. Гораздо проще нарисовать все действия и все состояния.

Диаграмма потоков может просто показывать, какие переходы состояний возможны в ответ на действия пользователя, а может и содержать в себе элементы UI (в этом случае она приближается к раскадровке).

Рисовать диаграммы потоков мне нравится ничуть не меньше, чем скетчи интерфейса.

Поток контекстного редактирования в Targetprocess 3.

Animation / gifs

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

Но все же раскадровки можно анимировать! Тогда получается крайне наглядная штука, которая позволяет представить, как все это будет работать.

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

Для того, чтобы делать анимационные гифы, нужна усидчивость, терпение и профессиональная деформация. У нас анимацией начал увлекаться Игорь Трафимович, и забомбил несколько хороших примеров:

Изменения в прогрессе карточки-требования с течением времени в Targetprocess 3.

Анимацией можно показать основные вещи, но анимировать сложные кейсы довольно проблематично и долго.

Быстрое редактирование данных в списках Targetprocess 3

Бумажные прототипы

Не все дети любят бумагу, ножницы и клей. Некоторых били по рукам указкой за попытку отрезать косичку соседке напротив, некоторым ни разу не удалось вырезать ровный круг, кого-то приклеили к стулу в середине урока. Ну а злостные любители клея просто не доживают до нужного профессионального уровня. Наверное поэтому бумажные прототипы не очень распространены.

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

Бумажный набор можно положить в рюкзак и отправиться на поиски непуганных пользователей, которые за простой латэ в старбаксе оценят ваш прототип и откроют вам глубины своей… оригинальности.

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

Бумажное прототипирование iPad приложения (которое мы начали делать, но не доделали).

Хороший пример бумажного прототипирования формы регистрации

Интерактивные спеки

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

Единственную интерактивную спецификацию, которую я видел в жизни, сделал Олег Серяга.

Интерактивная спецификация кастомизации карточек в Targetprocess 3. Кликабельно.

Тут мы можем переключать размеры карточек, типы карточек и быстро переходить к нужному элементу с описанием важных свойств.

Стоит ли делать интерактивные спецификации? Скорее всего, нет. Для прототипа их недостаточно, и есть более простые способы донести всю информацию не менее эффективно.

Живые прототипы

Большинство управляющих продуктами не умеют писать код. Им не чужды некоторые структуры данных, такие как списки, очереди и хеш таблицы (хотя они и не знают, как они на самом деле работают). Они в целом имеют представление о циклах и условных операторах. Но лишь небольшое количество управляющих продуктами имело опыт написания реального кода. Все это выливается в то, что они не могут сделать живой прототип системы своими силами, а значит им надо обращаться к программистам.

Хороший прототип дает ответы на огромное количество вопросов. Он позволяет пройти многие сценарии самостоятельно и увидеть наконец реальное взаимодействие. На прототипах можно запускать юзабилити тесты. Прототипы можно просто показывать клиентам и собирать их пожелания. Специалист по продажам может показать прототип потенциальному клиенту и соврать, что это уже в разработке и скоро (через 2 месяца) будет непременно выпущено.

Кажется, ничего и лучше желать нельзя. Но не все так радужно, прототип не может полностью заменить спецификацию.

К сожалению, практически всегда в прототипах реализуют только позитивные сценарии. Главная цель прототипа — работа на прорыв, доказательство работоспособности конкретного решения. Негативные сценарии никак не влияют на качество доказательства, поэтому их оставляют в сторонке. Однако для разработчика негативные сценарии крайне важны. Если разработчики не хотят о них думать, то тестировщики обожают. В результате придется терпеливо выяснять нюансы поведения системы, мучительно фиксить баги и править сообщения “You can’t do that!”.

Вторая проблема — отсутствие мелких деталей. Прототип обычно существенно отличается от законченного дизайна. Он может быть вообще довольно страшным на вид, главное рабочим.

Первый прототип Targetprocess 3, сделанный для проверки концепции. Показывался клиентам и вызывал общее одобрение. Кликабельно, но работает не все, что видно.

Через прототип очень нудно и долго придется выяснять требования типа “а какая же максимальная длина у этого поля?”. Мало того, что разработчику вообще надо вспомнить, что у поля есть длина, так еще и тыкать в прототип мышкой и смотреть код в тщетной попытке найти там что-то хорошее.

Так что прототип не заменяет спецификацию. Отлично дополняет — это пожалуйста. Но я бы поостерегся ходить в разведку с управляющим продуктом, который отдает разработчику прототип со словами “тут все все понятно, начинайте делать”.

Еще один минус — время. Прототипы делать долго. Вообще есть два типа разработчиков: быстрые и медленные. Быстрым можно доверять разработку прототипов, медленным — ни в коем случае. Качество кода в прототипе, как вы понимаете, может быть произвольно плохим. Главное, чтобы работали нужные сценарии. И вроде бы КО похлопывает сейчас меня сзади по плечу, но я сам совершал такие ошибки в прошлом.

Спецификация = визуальное объяснение

Цель спецификации — донести идеи в максимально понятной и полной форме. Лучше всего это работает, когда используются и текст, и графика. Поэтому нужен здоровый микс самых разных методов, о которых мы уже поговорили. Это всегда тяжело, требует творческого подхода и желания делать добро.

Ниже все методы сведены в единый график. По оси X у нас сложность создания контента. Ясно, что живой прототип сделать сложно, тогда как набросать скетчи довольно просто. По оси Y у нас полезность, то есть насколько эффективно данный метод доносит идею. Опять же, полезность псевдо-нарративных спецификаций не высока, тогда как полезность готового дизайна или прототипов высокая.

Все методы донесения идей в одном флаконе.

Желательно не использовать методы с низкой полезностью, такие как BDD и псевдо-нарративные. Хорошо работают скетчи, нарративы, диаграммы потоков, раскадровка, бумажные прототипы и готовый дизайн. На анимацию и живые прототипы стоит тратить время только в том случае, если его реально много.

Вступайте на путь добра, друзья! Создавайте понятные визуальные спецификации, которые рассказывают истории на простом языке.

Источник