Критерии приёмки программы: как описать проверяемый результат

В чек-листе двадцать пунктов. Восемнадцать выполнены, а ещё два не удалось проверить: для одного нет тестовой учётной записи, для другого недоступна связанная система. Можно ли принимать программу? Нет: отсутствие проверки не подтверждает готовность результата.

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

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

Что именно должен подтверждать критерий?

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

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

ISO/IEC/IEEE 29148 рассматривает требование как точное и недвусмысленное выражение конкретной потребности. Стандарт также связывает работу с требованиями с их проверкой, подтверждением и сопровождением на протяжении жизненного цикла. Для заказчика практический вывод прост: каждое важное ожидание нужно выразить так, чтобы его можно было проверить наблюдением или измерением.

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

Из каких частей собрать проверяемое условие?

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

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

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

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

1. Исходные условия — кто выполняет проверку и какие данные уже есть.
2. Действие — один законченный шаг пользователя или системы.
3. Ожидаемый результат — видимое состояние интерфейса, данных или интеграции.
4. Граница — допустимое время, объём, формат либо перечень сред.
5. Подтверждение — экран, выгрузка, запись журнала или сверка в связанной системе.

Как превратить требование в сценарий проверки?

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

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

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

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

Как подготовить и провести приёмку?

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

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

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

Scrum Guide использует общее определение готовности, которое даёт участникам единое понимание завершённой работы; элемент, не соответствующий ему, не считается готовым к выпуску. Критерии приёмки решают более узкую задачу — проверяют конкретную функцию. Вместе они закрывают два уровня: общие требования к качеству и результат отдельной работы.

Итог проверки оформляют перечнем пройденных критериев и замечаний с доказательствами.

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

Источники

• ISO/IEC/IEEE 29148:2018 — International Organization for Standardization
• Руководство по Scrum, версия 2020 — Кен Швабер и Джефф Сазерленд
• Web Content Accessibility Guidelines 2.2 — W3C