kazminaviktoriya1
Перейти в профиль
Выйти из профиля
![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="42" height="42"><rect fill-opacity="0"/></svg>)
Добавить аккаунт
Спринт 9/18: Agile-практики → Тема 2/7: Истории → Урок 3/6
Для чего нужны критерии приёмки
Изначально критерии приёмки (Acceptance Criteria) назывались приёмочными тестами (Acceptance Tests). Ещё одно название — условия удовлетворённости (Conditions of Satisfaction).
Критерии приёмки назвали тестами, потому что они должны напоминать команде разработки о том, что ей нужно протестировать после реализации истории. Таким образом, критерии приёмки отвечают на вопрос: «Что команда должна проверить перед тем, как представить функцию пользователям?»
Участники команды разработки проверяют карточку истории в три этапа:
- Системный аналитик выявляет и записывает критерии приёмки на карточке истории.
- В сценариях приёмки СА записывает шаги, которые нужно выполнить для проверки критериев.
- Тестировщики дополняют сценарии приёмки и пишут на их основе автоматизированные тесты.
После обсуждения истории с пользователями команда разработки может вернуться на предыдущие этапы, чтобы добавить, удалить и изменить критерии приёмки.
Команда разработки может завершить реализацию истории, только если программный код успешно прошёл все автоматизированные тесты.
Как СА выявляет критерии приёмки
Представьте, что СА участвует в разработке клиентского приложения для банка. В текущей итерации команда автоматизирует формирование выписки по счёту клиента. Раньше её вручную формировали сотрудники банка.
Системный аналитик записал на карточке историю по шаблону:
Шаблона истории достаточно для понимания задачи и цели пользователя, но недостаточно для её реализации. Системному аналитику нужно спросить себя: «Что команда разработки должна проверить перед тем, как передать функцию клиентам?» Чтобы ответить на этот вопрос, СА должен подробнее обсудить с заказчиками особенности этой функции.
Системный аналитик может спросить у них:
- Как должна выглядеть выписка (по их представлению)?
- Какой период должна охватывать выписка по счёту?
- Могут ли клиенты иметь несколько счетов? Должна ли выписка формироваться по всем счетам сразу?
- В каком формате визовый центр принимает выписки по счетам? Например: PDF, DOCX, RTF?
В ходе обсуждения системный аналитик получил образец выписки и выяснил, что в зависимости от страны требования визовых центров к периоду выписки разнятся: одним требуется выписка за месяц, другим за полгода. СА также узнал, что у большинства клиентов несколько счетов и что визовые центры принимают выписки только в формате PDF и JPEG.
После обсуждения системный аналитик записывает на карточку истории соответствующие критерии приёмки:
В критериях приёмки системный аналитик не должен записывать содержание (например информацию о клиенте банка) и особенности оформления выписки. Чтобы передать эту информацию, гораздо удобнее показать команде разработки образец выписки, который СА может приложить к карточке истории.
Почему СА важно помнить о нефункциональных требованиях
Системный аналитик должен помнить о нефункциональных требованиях, обсуждать возможности ПО с заказчиками и записывать в виде критериев приёмки достигнутые в ходе обсуждения договорённости.
Критерии приёмки могут описывать функциональные и нефункциональные требования. Источник функциональных требований — пользователи и заказчики, нефункциональных — команда разработки.
Заказчики могут знать, каким функциональным требованиям должно соответствовать ПО, и не задумываться о нефункциональных требованиях. Например, им может казаться, что ПО по умолчанию должно работать быстро. Команда разработки, зная его возможности, может объяснить заказчикам, что иногда ПО требуется время на выполнение функции. Команда разработки должна договориться с ними о том, в течение какого времени допустимо выполнять функцию.
Вернёмся к примеру с выпиской по счёту. Помня про нефункциональные требования, системный аналитик обсуждает с командой разработки и заказчиками время, которое допустимо для автоматизированного формирования выписки. По итогу обсуждения он записывает ещё один критерий приёмки: «Выписка формируется не дольше пяти минут».
Какими должны быть критерии приёмки
Недостаточно просто обсудить критерии с пользователями и командой разработки. Каждый критерий приёмки также должен соответствовать ряду характеристик:
- Описывать типичные ситуации.
- Быть независимо реализуемым.
- Быть неделимым.
- Описывать результат, а не процесс его достижения.
Описывать типичные ситуации
Системному аналитику нужно записывать только те критерии приёмки, которые позволяют лучше понять ожидания пользователей. Это значит, что критерии приёмки должны описывать типичные ситуации, а не исключительные.
Что такое типичная ситуация? Например, часто клиенты банка открывают несколько счетов и могут получить выписку по каждому из них. Поэтому системный аналитик должен включить в историю критерий «Можно выбрать счёт для формирования выписки».
Нередко для получения визы выписка по счёту должна охватывать несколько месяцев. Это тоже типичная ситуация. Поэтому СА должен включить в историю критерий приёмки «Можно выбрать период, за который формируется выписка».
Не попадёт на карточку истории, например, критерий приёмки «Дата начала периода должна совпадать с датой его окончания или предшествовать ей», потому что он описывает лишь одну из множества исключительных ситуаций.
Другая исключительная ситуация — попытка получить выписку за 30 февраля. Клиент банка может случайно ввести несуществующую дату, но вероятность такой ситуации низкая.
Программистам нужно учитывать исключительные ситуации при написании программного кода. В нём они должны описывать алгоритм действий ПО в ответ на любую исключительную ситуацию, поскольку ПО не умеет принимать решения самостоятельно. Некоторые исключительные ситуации во время проверки могут определить тестировщики. Тогда они просят программистов учесть их в программном коде.
СА не должен записывать критерии приёмки для всех исключительных ситуаций. На карточке истории просто не хватит места для записи всех возможных исключений. Системному аналитику нужно помнить, что изначально истории писали на маленькой индексной карточке. Такой формат выбран осознанно, чтобы ограничить объём описания.
Быть независимо реализуемым
Критерии приёмки должны быть такими, чтобы команда разработки могла написать программный код и протестировать каждый критерий независимо от других. Системный аналитик должен обсудить с командой записанные им критерии приёмки, чтобы узнать, соответствуют ли они этой характеристике.
СА должен расположить критерии приёмки истории по приоритету в порядке убывания. В соответствии с этим порядком разработчики и тестировщики должны брать в работу критерии приёмки.
Важно приоритизировать критерии приёмки. Если команда разработки неверно оценит размер истории и не успеет полностью реализовать её в итерации, она всё равно сможет реализовать хотя бы часть критериев приёмки этой истории и показать заказчикам, чтобы получить от них обратную связь или даже передать эту часть клиентам, чтобы они смогли ею пользоваться. Так команда быстрее получит от заказчиков обратную связь или позволит клиентам быстрее получить пользу от работы с ПО, даже если остались доработки.
В истории «Выписка по счёту клиента» команда разработки может реализовать сначала выбор счёта для формирования выписки, например, формируя выписку:
- Всегда за один выбранный клиентом месяц.
- В течение любого времени.
Затем она может приступить к реализации выбора периода формирования выписки. Если команда разработки не успеет реализовать этот критерий, она может предоставить пользователям возможность отправить в визовый центр несколько отдельных выписок за месяц, а не одну выписку за весь требуемый период.
Последовательная реализация критериев приёмки позволяет:
- Сфокусировать команду разработки на небольшой части истории, не распыляя внимание на множество деталей в один момент. Если команда будет думать обо всей истории сразу, то вероятность пропустить важную деталь будет выше.
- Программистам быстрее получить обратную связь от тестировщиков о качестве программного кода. Если программист передаёт тестировщику объёмный программный код, который он писал всю итерацию, то к тому моменту, когда тестировщик начнёт находить дефекты, программист может забыть о том, как именно работает его код. А значит, он потратит больше времени на исправление дефекта. Чтобы лучше представить эту ситуацию, попробуйте посмотреть на ваше предыдущее домашнее задание или проект этого курса и попытайтесь вспомнить поставленную перед вами задачу и разобраться в результате её выполнения. Вы можете увидеть, что чем раньше была выполнена задача, тем больше времени вам нужно, чтобы понять её суть.
Быть неделимым
Критерий приёмки может быть либо выполнен на 100%, либо не выполнен полностью. Он не может быть выполнен, например, на 50%. Это значит, что критерий приёмки должен быть простым, неделимым. Наличие в формулировке критерия приёмки союза «и» может подсказать системному аналитику, что один сложный критерий можно разделить на несколько простых.
Например, критерий приёмки «Можно скачать выписку в PDF и JPEG» не соответствует этой характеристике. Если выписку можно скачать в PDF, а в JPEG нельзя, то команда разработки не может оценить, выполнен ли этот критерий. Этот сложный критерий нужно разделить на два простых:
- Можно скачать выписку в PDF
- Можно скачать выписку в JPEG
Описывать результат
Критерий приёмки должен описывать только ожидаемый результат, а не процесс его достижения. Наличие в формулировке критерия приёмки названий элементов интерфейсов может подсказать СА, что критерий приёмки описывает процесс.
Например, критерий приёмки «При нажатии на кнопку „Скачать“ выписка скачивается в PDF» описывает процесс.
Подведём итоги
Изначально критерии приёмки (Acceptance Criteria) назывались приёмочными тестами (Acceptance Tests). Такое название им дали потому, что критерии приёмки должны напоминать команде разработки о том, что она должна протестировать после реализации истории. То есть критерии приёмки отвечают на вопрос: «Что команда должна проверить перед тем, как передать функцию пользователям?»
Критерии приёмки могут описывать функциональные и нефункциональные требования. Источником функциональных требований являются пользователи и заказчики, а нефункциональных — команда разработки.
Каждый критерий приёмки должен соответствовать набору характеристик:
- Описывать типичные ситуации.
- Быть независимо реализуемым.
- Быть неделимым.
- Описывать результат, а не процесс достижения результата.
После выявления и записи критериев приёмки СА записывает шаги их проверки в виде сценариев приёмки.
Чат поддержки