Home

Автор: Джефф Найман (Jeff Nyman)
Оригинал статьи
Перевод: Ольга Алифанова

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

Цель этого подхода в:

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

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

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

Это хороший старт для покрытия фич (а это важная штука).

• Не все тест-сценарии должны быть готовы к этому моменту.
• Цель – предоставить достаточно репрезентативных примеров того, как фича приносит ценность.
• У вас достаточно примеров, когда
  • Все убеждены, что фича всем ясна.
  • Достигнуто общее понимание того, что значит "фича готова".

Это хороший старт для работы над готовностью фичи (еще одна важная штука).

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

• Разработчик оценивает на основании работы по разработке фичи.
• Тестировщик оценивает, сколько еще сценариев, возможно, понадобится, и сколько автоматизации можно применить.

Заметьте, что "тестировщик" тут – любой, способный тестировать. Это не значит, что нужно волноваться о названиях профессии, это означает только наличие умеющего тестировать человека.

Любой член команды может предлагать тест-сценарии для добавления в фича-спецификацию.

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

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

Тут есть важный момент: вы должны быть способны быстро просмотреть фича-спецификацию, она не должна выглядеть как набор JIRA-тикетов или страниц в Confluence, лишь частично покрывающий фичу и ее готовность. "Быстро просмотреть" ее должно быть можно не только в ходе спринта, в котором она создана – эти спецификации живут столько же, сколько существует сама фича. Поэтому важно понимать, что фича-спецификация – это требования, закодированные как тесты.

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

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

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

Обсудить в форуме