Рекомендованная форма программы приёмочных испытаний¶
Статус: informative. Рекомендация касается человекочитаемого документа для заказчика. Структура самого артефакта AT — нормативна и задаётся
standard/09 §9.19; при расхождении заготовки и главы стандарта главенствует глава.Приложение не создаёт обязательств и не расширяет ни один закрытый список (§1.7.5).
14.1 Что это за документ¶
Программа приёмочных испытаний — сценарный документ, который предъявляется заказчику на сдаче. Это клиентская проекция множества AT: машина исполняет приёмочные тесты, человек читает программу. Такое разделение — продолжение общего принципа стандарта: заказчик видит человекочитаемое, машина работает с каноническим.
Программа выводится из итогового ТЗ (§7.14) — начального ТЗ с приложениями плюс всех подписанных ACTZ, — а не из начального ТЗ. Контракт живёт инкрементно, и предъявлять систему против устаревшей редакции нельзя: AT перегенерируются перед каждыми испытаниями от действующей редакции (§9.19.4), а вслед за ними перегенерируется и программа.
Программа генерируется, а не пишется руками: всё её содержимое уже есть в AT.
14.2 Поля программы¶
| Поле | Содержание | Источник в стандарте |
|---|---|---|
id |
Стабильный идентификатор пункта контракта (УС-NNN, ФТ-NNN) или пункта ACTZ. Не придумывается — берётся из документа |
reference/13 §13.3 |
source |
Откуда пункт: TZ §N или ACTZ-NNN §M, включая ТЗ подсистем |
verifies[], §9.19.3 |
tz_text |
Дословная цитата пункта итогового ТЗ или ACTZ | обязательный раздел тела AT, §9.19.3 |
steps |
Шаги проверки активными командами: «открыть…», «нажать…», «убедиться…» | тело AT |
expected |
Ожидаемый результат одним предложением | тело AT |
Пример одного пункта программы:
id: ФТ-014
source: "TZ §5.14"
tz_text: >
Система должна отклонить проведение документа, если сумма
по строкам расходится с указанной в шапке.
steps:
- "Открыть документ с расхождением суммы шапки и строк."
- "Нажать «Провести»."
- "Убедиться, что документ не проведён и показана причина отказа."
expected: "Документ остаётся черновиком, причина отказа названа явно."
Дословная цитата — ключевое поле. Заказчик видит текст контракта и проверку бок о бок: предъявляется не пересказ пункта, а сам пункт. Спорить о том, «что имелось в виду», не о чем — поэтому цитата и забрана в нормативную часть AT, а не оставлена рекомендацией.
14.3 Полнота покрытия¶
В программу входят все контрактные пункты — без пропусков и без объединения нескольких пунктов в один. Полнота считается по разделам итогового ТЗ и пунктам подписанных ACTZ; машинная сторона этого требования — отчёт ACCEPTANCE.md (§9.19.6).
Объединение пунктов выглядит экономией, но снимает адресность: провал объединённой проверки нельзя привязать к конкретному пункту контракта, и вердикт снова становится предметом обсуждения.
Программа может согласовываться с заказчиком очередным ACTZ (§7.13) — тогда сама программа становится утверждённым обязательством, и порядок сдачи известен обеим сторонам заранее.
14.4 Вердикт по классам дефектов¶
Вердикт приёмки рекомендуется вычислять по классам дефектов, а не бинарно. Механизм: каждый провал пункта программы классифицируется, и решение о подписании акта принимается по объявленным заранее коридорам качества.
Типичная градация — четыре уровня:
| Уровень | Название | Описание |
|---|---|---|
| 1 | Критический | Система неработоспособна, данные теряются или повреждаются, безопасность нарушена |
| 2 | Значительный | Ключевой функционал недоступен или работает неверно, обходного пути нет |
| 3 | Умеренный | Второстепенный функционал некорректен, обходной путь есть |
| 4 | Незначительный | Визуальные, текстовые и другие дефекты, не влияющие на работу |
Градация приведена как пример, а не как норма. Стандарт не устанавливает ни числовых порогов, ни самого числа уровней. Коридоры качества — какие уровни блокируют подписание акта, сколько дефектов каждого уровня допустимо к переносу — объявляет вендор в договоре либо в манифесте, опираясь на свой внутренний регламент качества. У банка и у внутреннего подразделения пороги будут разными, и оба будут правы: это коммерческая политика, а не свойство инженерии требований.
Что рекомендуется независимо от выбранных порогов: дефект, блокирующий подписание, оформляется с привязкой к пункту контракта (id, tz_text), описанием расхождения и ожидаемым результатом; неблокирующие дефекты фиксируются, а план их исправления согласуется с заказчиком до подписания акта.
Ценность механизма — в том, что правила игры объявлены до испытаний. Без него каждый найденный на приёмке дефект становится предметом торга.
14.5 Внутренний гейт и договорная приёмка — не одно и то же¶
Коридоры качества описывают поведение сторон на приёмке и не ослабляют внутренний гейт вендора.
| Контур | Правило | Кто находит дефекты |
|---|---|---|
| Внутренний, перед сдачей | Все AT в статусе passing — строго, без коридоров (§10.4.3) |
Вендор |
| Договорная приёмка | Вердикт по коридорам качества вендора | Заказчик |
Вендор не предъявляет систему с известными провалами — иначе коридоры превратятся в разрешение сдавать недоделанное. Но на реальной приёмке заказчик находит своё, и классификация даёт заранее согласованные правила для этой ситуации.
14.6 Уровень дефекта как диагностика¶
Уровень дефекта соотносится с маршрутизацией провалов AT и TC (§9.19.5):
- дефект уровня 1–2 при зелёных TC — почти всегда ошибка интерпретации: система соответствует ADAPT, но не контракту. Чинится в ADAPT и ACTZ, а не в коде;
- дефекты уровней 3–4 чаще указывают на недоспецифицированные детали — кандидаты в очередной ACTZ.
14.7 Связь с другими документами¶
| Документ | Связь |
|---|---|
standard/09 §9.19 |
AT — нормативная структура артефакта, из которого выводится программа |
standard/07 §7.13 |
ACTZ — протокол уточнения ТЗ и согласования программы |
standard/07 §7.14 |
Итоговое ТЗ — эталон, против которого идут испытания |
standard/10 §10.4 |
Внутренний релизный гейт |
reference/13 |
Рекомендованная форма ТЗ — источник стабильных идентификаторов пунктов |