Критерии приема

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

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

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

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

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

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

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

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

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