Фраза «заказы должны удобно создаваться» не помогает решить, готова ли функция. Разработчик показывает форму с кнопкой сохранения, руководитель ожидает защиту от дублей, а оператор не может исправить ошибку в строке. Каждый оценивает свой результат.
Критерий приёмки делает ожидание проверяемым: задаёт исходную ситуацию, действие пользователя и наблюдаемое состояние после него. Подготовить такие критерии полезно до разработки, пока разногласие можно исправить несколькими предложениями.
Начните с пользовательского результата
Выберите один сквозной сценарий, например создание заказа на изготовление. Укажите, кто его выполняет, зачем и какое следующее действие должно стать возможным. Количество полей вторично по отношению к этому результату.
Руководство GOV.UK по пользовательским историям рассматривает критерии как перечень результатов, подтверждающих выполнение потребности. Для внутренней системы это означает, что критерий проверяет рабочую задачу, а не существование элемента интерфейса.
Плохой вариант: «есть фильтр по ответственному». Проверяемый вариант: «диспетчер выбирает сотрудника и получает только доступные ему незакрытые заказы этого сотрудника; количество соответствует подготовленному набору данных».
Критерий не обязан диктовать техническую реализацию. Но он должен исключать ситуацию, когда два проверяющих получают разные выводы из одного и того же поведения.
Заполненный пример: создание заказа
Возьмём учебную систему, где оператор создаёт заказ на детали. Правила ниже условные и предназначены для демонстрации формы критериев.
Исходные условия. Пользователь ОП-12 имеет роль оператора подразделения А. В справочнике есть клиент К-204 и изделие Д-18. Подготовлена одна позиция: 20 деталей по 1 500 рублей. Заказ с внешним номером клиента 457 для этого клиента ещё не зарегистрирован.
Действие. Оператор выбирает клиента, вводит номер 457, добавляет позицию и сохраняет заказ.
Ожидаемый результат. Создан один заказ с внутренним идентификатором. Количество — 20, сумма — 30 000 рублей, статус — «Черновик», подразделение — А. После повторного открытия значения сохраняются.
Доказательство. Проверяющий записывает идентификатор заказа, версию сборки, время проверки и фактический результат. Одной фотографии открытой формы недостаточно: она не подтверждает сохранение после повторного входа.
Теперь добавьте отрицательные проверки. При пустом клиенте заказ не создаётся, пользователь получает понятное сообщение. При отрицательном количестве сохранение отклоняется. Правило для нулевой цены обсуждается отдельно: нельзя вывести его автоматически из запрета отрицательного количества.
Проверьте повторное действие и границы
Если оператор дважды нажал «Сохранить» из-за медленного ответа, бизнес обычно ожидает один результат. Но механизм защиты и допустимое поведение необходимо согласовать, особенно при повторной отправке после обрыва связи.
Критерий для примера: повтор той же операции в согласованных условиях не создаёт второй заказ; пользователь видит результат первой операции либо понятный статус проверки. Если система не может определить исход, она не должна молча подтверждать успех.
Отдельно проверьте внешний номер 457 у другого клиента. Дубль определяется не внешним видом строки, а утверждённым правилом уникальности. Для одного проекта это сочетание клиента и номера, для другого — номер, год и подразделение.
Граничные значения берите из реального ограничения: максимальная длина номера, количество позиций, допустимая дата. Произвольные «большие числа» не заменяют проверку именно согласованной границы.
Пример: смена статуса
Сценарий изменения статуса описывает условия перехода и последствия.
- Дано: заказ З-018 находится в статусе «Подготовлен», обязательные поля заполнены, исполнитель назначен.
- Пользователь: диспетчер подразделения А.
- Действие: перевести заказ в работу.
- Результат: статус меняется на «В работе», сохраняются автор и время перехода.
- Связанный результат: заказ появляется в рабочем списке назначенного исполнителя.
- Запрет: без назначенного исполнителя переход отклоняется, прежний статус сохраняется.
- Повтор: повторное действие не создаёт вторую запись того же бизнес-перехода.
Не забудьте одновременную работу. Если один сотрудник отменил заказ, пока другой открывал его старую версию, система должна действовать по согласованному правилу конфликта. Например, отклонить устаревшее действие и предложить обновить данные. Это отдельный критерий, а не «редкая техническая мелочь».
Пример: ограничение доступа
Проверка доступа должна охватывать результат действия, а не только видимость кнопки. Скрытая кнопка не доказывает невозможность изменить чужую запись другим способом.
Для учебного сценария сотрудник подразделения Б не имеет права читать и изменять заказ подразделения А. Проверяют поиск, прямое открытие по идентификатору, выгрузку и изменение доступными средствами проверки.
Ожидаемый результат: содержимое недоступной записи не раскрывается, состояние заказа не меняется. Для разрешённой роли тот же сценарий должен работать. Иначе общий запрет можно ошибочно принять за корректное разграничение.
Настоящие чувствительные данные для такой проверки обычно не нужны. Подготовьте искусственные записи с явными признаками принадлежности. Техническую проверку обходов выполняет компетентный специалист в разрешённой среде.
Шаблон одного критерия
Для повседневной работы достаточно следующих полей:
- Идентификатор: ПР-023 и ссылка на требование.
- Рабочий результат: что должен получить пользователь.
- Роль и права: конкретная учётная запись или профиль.
- Исходные данные: известные объекты и их состояния.
- Условия: версия, окружение, включённые зависимости.
- Действие: однозначная последовательность.
- Ожидание: значения, состояние, сообщение и связанные эффекты.
- Недопустимый эффект: что не должно измениться.
- Доказательство: идентификатор результата, запись проверки, необходимый журнал.
- Решение: пройдено, не пройдено либо заблокировано с причиной.
Критерий «работает быстро» дополните операцией, объёмом, числом одновременных пользователей, способом измерения и допустимым результатом. Значения выбирайте по задаче. Не переносите случайную цифру из другого проекта как обязательную норму.
Отделите критерии от сценария испытания
Критерий описывает требуемый результат, а испытание — способ его проверить. Один критерий может требовать нескольких испытаний: обычного, граничного и ошибочного. Такая связь помогает не терять условия при изменении интерфейса.
Подготовьте тестовые данные заранее. Иначе участники тратят встречу на поиск клиента и спорят, допустима ли выбранная сумма. Для сложных расчётов ожидаемый результат вычисляют независимо от системы.
Пользовательская проверка также выявляет непонятные формулировки и неудобный порядок действий. Руководство GOV.UK по наблюдаемому тестированию предлагает давать человеку реалистичную задачу и наблюдать выполнение. Этот подход дополняет формальные проверки, но не заменяет технические испытания.
Как принять решение по результатам
Назначьте владельца приёмки, перечислите блокирующие отклонения и договоритесь, кто вправе принять оставшиеся ограничения. Не используйте общий процент успешных проверок без оценки важности: один провал запрета доступа может быть существеннее двадцати успешных фильтров.
Замечание должно содержать исходные условия, ожидаемый и фактический результат. «Не работает» не позволяет воспроизвести проблему. После исправления повторяют связанную проверку и затронутые сценарии.
Перед разработкой начните с десяти наиболее важных критериев. Обсудите их с пользователем и подрядчиком, затем расширяйте набор по рискам. Для подготовки пригодятся сценарное техническое задание и бриф внутренней системы. Эти материалы можно использовать как основу разговора о заказной разработке.
Разрешите противоречия до реализации
Иногда два согласованных критерия несовместимы. Например, один требует свободно менять сумму до отгрузки, другой запрещает любые изменения после финансового согласования. Разработчик не должен молча выбирать более удобное правило.
Для каждого такого случая подготовьте один конкретный заказ и попросите владельца процесса описать допустимое действие. Возможно, требуется повторное согласование, создание новой версии или отдельная корректировка. Выбранное правило затем отражают во всех связанных критериях.
Проверяйте также термины: «закрыт», «выполнен» и «отгружен» могут означать разные состояния. Краткий словарь рядом с критериями предотвращает спор о словах на финальной встрече. После согласования сохраняйте версию набора и дату. Если требования изменились, должно быть видно, какие проверки обновлены и почему прежний результат больше не считается достаточным.