Нефункциональное требование часто звучит как пожелание: «быстро», «надёжно», «безопасно». Пока не определены наблюдаемый критерий и способ измерения, принять его нельзя.
«Быстро» превращается в проверку времени ответа для конкретного сценария и нагрузки. «Надёжно» — в допустимую долю повторных ошибок, восстановление и отсутствие потери данных. «Безопасно» — в список разрешений, запретов и проверяемых событий. Формулировка должна указывать субъект, границу и свидетельство.
Критерий связывается с артефактом: метрикой, логом, трассировкой, снимком состояния или результатом теста. Если внешний код исправил формат ответа, это нужно сохранить как часть evidence, иначе отчёт создаст ложное впечатление о качестве.
AI-агент может собрать измерения, сопоставить их с порогами и показать пропуски. Он не должен подменять отсутствие данных зелёным статусом. Нельзя принять NFR, если измерение не охватывает заявленную область.
Перед реализацией я проверяю: кто измеряет, каким инструментом, на каком наборе входов и что происходит при нехватке свидетельств. Эти ответы связывают качество с ответственностью, а не с красивым числом в дашборде.
Нефункциональный критерий становится частью требования только тогда, когда его можно воспроизвести и предъявить владельцу решения для приёмки.
Если порог нельзя измерить в реальном контуре, его нужно назвать гипотезой, а не требованием. После запуска сохраняю контекст замера: версию системы, набор входов, окно времени и ограничения. Иначе два зелёных отчёта могут описывать разные условия.
«Быстро» превращается в проверку времени ответа для конкретного сценария и нагрузки. «Надёжно» — в допустимую долю повторных ошибок, восстановление и отсутствие потери данных. «Безопасно» — в список разрешений, запретов и проверяемых событий. Формулировка должна указывать субъект, границу и свидетельство.
Критерий связывается с артефактом: метрикой, логом, трассировкой, снимком состояния или результатом теста. Если внешний код исправил формат ответа, это нужно сохранить как часть evidence, иначе отчёт создаст ложное впечатление о качестве.
AI-агент может собрать измерения, сопоставить их с порогами и показать пропуски. Он не должен подменять отсутствие данных зелёным статусом. Нельзя принять NFR, если измерение не охватывает заявленную область.
Перед реализацией я проверяю: кто измеряет, каким инструментом, на каком наборе входов и что происходит при нехватке свидетельств. Эти ответы связывают качество с ответственностью, а не с красивым числом в дашборде.
Нефункциональный критерий становится частью требования только тогда, когда его можно воспроизвести и предъявить владельцу решения для приёмки.
Если порог нельзя измерить в реальном контуре, его нужно назвать гипотезой, а не требованием. После запуска сохраняю контекст замера: версию системы, набор входов, окно времени и ограничения. Иначе два зелёных отчёта могут описывать разные условия.
Изменение источника редко ограничивается одной строкой в документе. Новое правило может сделать устаревшими требование, сценарий, тест, решение в журнале и уже написанную реализацию.
После смены авторитетной версии я сначала строю impact trace: какие записи ссылаются на источник, какие артефакты были из него выведены и где зафиксировано принятое решение. Агент способен найти широкий список кандидатов, но не должен молча переписывать его.
Для каждого кандидата фиксирую причину: изменился вход, критерий, разрешение, срок действия или только пояснение. Затем владелец решает, что инвалидировать, что оставить для истории и какие проверки запустить заново.
Например, если контракт меняет момент фиксации курса, устаревают не только пункт спецификации, но и сценарий оплаты, тест расчёта, отчёт сверки и инструкция поддержки. Decision Log хранит основание изменения и помогает определить границу повторной приёмки.
Полезно разделять состояния «реализовано», «проверено» и «принято». Технически зелёный тест показывает, что текущая версия прошла проверку; он не подтверждает, что проверялось ещё действующее требование.
Impact trace нужен не для тотального контроля, а чтобы изменение не оставляло за собой тихий хвост старых решений.
Такой список не обязан быть огромным. Достаточно начать с артефактов, которые влияют на решение пользователя или могут выпустить устаревшее поведение в эксплуатацию. Остальное можно проверить после того, как владелец подтвердит границу воздействия.
После смены авторитетной версии я сначала строю impact trace: какие записи ссылаются на источник, какие артефакты были из него выведены и где зафиксировано принятое решение. Агент способен найти широкий список кандидатов, но не должен молча переписывать его.
Для каждого кандидата фиксирую причину: изменился вход, критерий, разрешение, срок действия или только пояснение. Затем владелец решает, что инвалидировать, что оставить для истории и какие проверки запустить заново.
Например, если контракт меняет момент фиксации курса, устаревают не только пункт спецификации, но и сценарий оплаты, тест расчёта, отчёт сверки и инструкция поддержки. Decision Log хранит основание изменения и помогает определить границу повторной приёмки.
Полезно разделять состояния «реализовано», «проверено» и «принято». Технически зелёный тест показывает, что текущая версия прошла проверку; он не подтверждает, что проверялось ещё действующее требование.
Impact trace нужен не для тотального контроля, а чтобы изменение не оставляло за собой тихий хвост старых решений.
Такой список не обязан быть огромным. Достаточно начать с артефактов, которые влияют на решение пользователя или могут выпустить устаревшее поведение в эксплуатацию. Остальное можно проверить после того, как владелец подтвердит границу воздействия.
Зелёный результат завершает техническую проверку, но не принимает остаточный риск. Тест может подтвердить схему, наличие файла и прохождение сценария, а пользовательский исход всё равно оказаться не тем.
В конце цепочки я фиксирую, что именно проверено, какие ограничения остались и кто имеет право сказать «этого достаточно». Именованный владелец видит evidence, нерешённые конфликты и последствия альтернатив. Только после этого результат становится принятым.
Это особенно важно для AI-агента. Он может собрать артефакт, прогнать тесты, показать ссылки на источники и вернуть список неопределённостей. Но тот же исполнитель не должен единолично объявлять свою работу соответствующей потребности пользователя.
Приёмка — не формальность после зелёного CI. Это решение о том, что конкретный исход подходит в заданной области, при известных ограничениях и цене ошибки. Иногда правильный результат — вернуть задачу на уточнение, а не закрыть её.
Практическая запись может содержать четыре пункта: проверенное поведение, свидетельства, остаточный риск и имя принимающего. Если меняется исходное требование, старое решение нужно явно пересмотреть, даже когда все тесты продолжают проходить.
Так трассировка заканчивается не статусом «green», а понятной человеческой ответственностью за то, что система действительно готова к использованию.
Имя принимающего важно не для поиска виноватого. Оно показывает, где заканчивается механическая проверка и начинается решение о допустимости. Если такого имени нет, статус лучше оставить «проверено», а не превращать его в обещание готовности.
В конце цепочки я фиксирую, что именно проверено, какие ограничения остались и кто имеет право сказать «этого достаточно». Именованный владелец видит evidence, нерешённые конфликты и последствия альтернатив. Только после этого результат становится принятым.
Это особенно важно для AI-агента. Он может собрать артефакт, прогнать тесты, показать ссылки на источники и вернуть список неопределённостей. Но тот же исполнитель не должен единолично объявлять свою работу соответствующей потребности пользователя.
Приёмка — не формальность после зелёного CI. Это решение о том, что конкретный исход подходит в заданной области, при известных ограничениях и цене ошибки. Иногда правильный результат — вернуть задачу на уточнение, а не закрыть её.
Практическая запись может содержать четыре пункта: проверенное поведение, свидетельства, остаточный риск и имя принимающего. Если меняется исходное требование, старое решение нужно явно пересмотреть, даже когда все тесты продолжают проходить.
Так трассировка заканчивается не статусом «green», а понятной человеческой ответственностью за то, что система действительно готова к использованию.
Имя принимающего важно не для поиска виноватого. Оно показывает, где заканчивается механическая проверка и начинается решение о допустимости. Если такого имени нет, статус лучше оставить «проверено», а не превращать его в обещание готовности.
У AI-агента может быть завершённый запуск: процесс дошёл до конца, файлы записались, проверки вернули зелёный статус. Это важное техническое состояние, но ещё не решение задачи.
Завершение отвечает на вопрос: «Среда закончила работу?» Приёмка отвечает на другой вопрос: «Получен ли тот результат, которым команда готова пользоваться и за который владелец готов отвечать?»
Разница становится заметной, когда результат выглядит убедительно. Агент собрал документ, прогнал тесты и приложил логи. Проверяющий видит полный пакет и может незаметно принять его за доказательство правильности. Но пакет доказывает прежде всего то, что заданная процедура выполнилась.
Представьте изменение платёжной интеграции. Агент обновил код, тесты прошли, схема ответа соответствует формату. Позже владелец уточняет, что требование относилось к повторному запросу после тайм-аута: покупатель не должен получить второй платёж. Если сценарий не был зафиксирован заранее, зелёные тесты не отвечают на главный вопрос. Они подтверждают выбранную реализацию, а не пользовательский исход.
Поэтому до запуска полезно разделить контур на четыре записи.
Первая запись — условие завершения работы. Какие файлы созданы, какие команды выполнились, какие технические ошибки устранены.
Вторая — наблюдаемый результат. Что именно увидит пользователь или соседняя система в согласованном сценарии: например, повторный запрос с тем же ключом не создаёт второй платёж.
Третья — свидетельство проверки. Ссылка на тест, журнал или другой артефакт, который может открыть и повторить независимый проверяющий.
Четвёртая — решение о приёмке. Именованный человек подтверждает, что сценарий выражает потребность, ограничения приемлемы, а остаточный риск принят.
Агент может подготовить первые три записи. Он способен выполнить проверку, собрать свидетельства и вернуть результат в заданном формате. Но право считать сценарий достаточным появляется не из зелёной строки и не из полноты отчёта.
Практический протокол прост: сначала запишите пользовательский исход и границы допустимого, затем определите технический признак завершения и независимое свидетельство. После работы сравните результат с исходным сценарием, а не только с тем, что получилось реализовать.
Завершённая работа — это состояние процесса. Принятый результат — решение владельца по наблюдаемому исходу. Пока эти записи не разделены, команда легко путает аккуратно сделанное с нужным.
Завершение отвечает на вопрос: «Среда закончила работу?» Приёмка отвечает на другой вопрос: «Получен ли тот результат, которым команда готова пользоваться и за который владелец готов отвечать?»
Разница становится заметной, когда результат выглядит убедительно. Агент собрал документ, прогнал тесты и приложил логи. Проверяющий видит полный пакет и может незаметно принять его за доказательство правильности. Но пакет доказывает прежде всего то, что заданная процедура выполнилась.
Представьте изменение платёжной интеграции. Агент обновил код, тесты прошли, схема ответа соответствует формату. Позже владелец уточняет, что требование относилось к повторному запросу после тайм-аута: покупатель не должен получить второй платёж. Если сценарий не был зафиксирован заранее, зелёные тесты не отвечают на главный вопрос. Они подтверждают выбранную реализацию, а не пользовательский исход.
Поэтому до запуска полезно разделить контур на четыре записи.
Первая запись — условие завершения работы. Какие файлы созданы, какие команды выполнились, какие технические ошибки устранены.
Вторая — наблюдаемый результат. Что именно увидит пользователь или соседняя система в согласованном сценарии: например, повторный запрос с тем же ключом не создаёт второй платёж.
Третья — свидетельство проверки. Ссылка на тест, журнал или другой артефакт, который может открыть и повторить независимый проверяющий.
Четвёртая — решение о приёмке. Именованный человек подтверждает, что сценарий выражает потребность, ограничения приемлемы, а остаточный риск принят.
Агент может подготовить первые три записи. Он способен выполнить проверку, собрать свидетельства и вернуть результат в заданном формате. Но право считать сценарий достаточным появляется не из зелёной строки и не из полноты отчёта.
Практический протокол прост: сначала запишите пользовательский исход и границы допустимого, затем определите технический признак завершения и независимое свидетельство. После работы сравните результат с исходным сценарием, а не только с тем, что получилось реализовать.
Завершённая работа — это состояние процесса. Принятый результат — решение владельца по наблюдаемому исходу. Пока эти записи не разделены, команда легко путает аккуратно сделанное с нужным.
У завершённой задачи есть простой соблазн: считать её принятой, когда агент закончил работу и показал зелёные проверки. Но техническое завершение и решение о достаточности принадлежат разным уровням.
Завершение описывает состояние процесса. Команды отработали, файлы записались, формат ответа выдержан, проверяющий может открыть журнал. Это необходимая часть результата, но она не отвечает на вопрос, решена ли исходная задача.
Приёмка описывает ответственность. Кто-то должен подтвердить, что выбранный сценарий соответствует потребности, ограничения не нарушены, а оставшийся риск можно принять. Такой человек не просто читает отчёт. Он имеет право сказать: «Этого достаточно» или «Нужно вернуться к постановке».
Представьте агента, который обновляет платёжную интеграцию. Он выполнил миграцию, прогнал тесты и приложил логи. Все технические условия зелёные. Но владелец сценария имел в виду повторный запрос после тайм-аута: покупатель не должен получить второй платёж. Если это условие не попало в критерий заранее, агент может завершить работу без принятого результата.
Здесь полезно различать три роли.
Исполнитель собирает артефакт и свидетельства. Проверяющий устанавливает, что заданные проверки выполнены и их можно воспроизвести. Владелец решения сопоставляет наблюдаемый исход с потребностью и принимает остаточную неопределённость.
Иногда все три роли выполняет один человек. Это не отменяет различия функций. Если исполнитель сам объявляет свою работу принятой, команде сложнее заметить, что критерий был неполным или выбранный компромисс никем не принят.
Практический протокол начинается до запуска. Сначала назовите владельца решения и запишите наблюдаемое поведение в конкретном сценарии. Затем отдельно зафиксируйте техническое условие завершения и способ получить независимое свидетельство. После выполнения проверяющий сверяет результат с исходным сценарием, а владелец решает, достаточно ли этого для дальнейшего шага.
Зелёная проверка говорит: «заданный тест прошёл». Приёмка говорит: «команда готова считать этот исход своим». Первое можно автоматизировать. Второе требует явно названного права решения.
Завершение описывает состояние процесса. Команды отработали, файлы записались, формат ответа выдержан, проверяющий может открыть журнал. Это необходимая часть результата, но она не отвечает на вопрос, решена ли исходная задача.
Приёмка описывает ответственность. Кто-то должен подтвердить, что выбранный сценарий соответствует потребности, ограничения не нарушены, а оставшийся риск можно принять. Такой человек не просто читает отчёт. Он имеет право сказать: «Этого достаточно» или «Нужно вернуться к постановке».
Представьте агента, который обновляет платёжную интеграцию. Он выполнил миграцию, прогнал тесты и приложил логи. Все технические условия зелёные. Но владелец сценария имел в виду повторный запрос после тайм-аута: покупатель не должен получить второй платёж. Если это условие не попало в критерий заранее, агент может завершить работу без принятого результата.
Здесь полезно различать три роли.
Исполнитель собирает артефакт и свидетельства. Проверяющий устанавливает, что заданные проверки выполнены и их можно воспроизвести. Владелец решения сопоставляет наблюдаемый исход с потребностью и принимает остаточную неопределённость.
Иногда все три роли выполняет один человек. Это не отменяет различия функций. Если исполнитель сам объявляет свою работу принятой, команде сложнее заметить, что критерий был неполным или выбранный компромисс никем не принят.
Практический протокол начинается до запуска. Сначала назовите владельца решения и запишите наблюдаемое поведение в конкретном сценарии. Затем отдельно зафиксируйте техническое условие завершения и способ получить независимое свидетельство. После выполнения проверяющий сверяет результат с исходным сценарием, а владелец решает, достаточно ли этого для дальнейшего шага.
Зелёная проверка говорит: «заданный тест прошёл». Приёмка говорит: «команда готова считать этот исход своим». Первое можно автоматизировать. Второе требует явно названного права решения.
Перед запуском работы с AI-агентом полезно проверить не сам запрос, а то, что вы собираетесь считать результатом.
В требованиях часто описывают действие: «собери документы», «проверь интеграцию», «подготовь вывод». Но действие ещё не задаёт границу приёмки. Если заранее не определить, какой артефакт должен появиться, проверка начнётся слишком поздно: команда увидит красивый ответ и будет спорить уже о деталях реализации.
Представим интеграционный проект. Перед стартом нужно зафиксировать четыре вещи:
1. Какой результат существует физически: документ, запись в системе, изменение схемы или решение с указанным владельцем.
2. Какие свойства можно проверить автоматически: обязательные разделы, ссылки на источники, формат данных, наличие всех файлов.
3. Что считается неполным результатом: путь к будущему файлу, заглушка, фраза «уточняется», конфликт источников без вынесенного решения.
4. Кто принимает остаточный риск, если все технические проверки зелёные, а бизнес-ситуация всё ещё допускает несколько трактовок.
Без этого агент легко превращает неизвестное в уверенный текст. Например, в контракте указана одна версия API, в переписке с поставщиком — другая. Агент может выбрать одну и продолжить, хотя правильным исходом запуска было бы зафиксировать конфликт и вернуть его владельцу решения.
Поэтому evidence нужно собирать до запуска, а не после. Сначала записываем источники, их даты, владельцев и область действия. Затем формулируем критерий: что должно быть доказано и каким наблюдением это подтверждается. Только потом запускаем агента и проверяем, что он создал полный артефакт.
Такой порядок меняет и смысл зелёной галочки. Она показывает, что конкретная проверка прошла. Она не сообщает, что найден правильный ответ для пользователя. Проверка схемы не заменяет проверку содержания, а полный документ не означает, что его уже можно принять.
Практический минимум перед стартом:
— назовите будущий артефакт и место, где он должен появиться;
— выпишите обязательные свойства результата;
— перечислите известные отрицательные сценарии;
— укажите источники и владельцев спорных решений;
— назначьте человека, который имеет право принять остаточную неопределённость.
После этого агент получает измеримую границу работы. Аналитик сохраняет право остановить выполнение, если доказательства расходятся, а команда видит, что именно нужно пересмотреть.
В требованиях часто описывают действие: «собери документы», «проверь интеграцию», «подготовь вывод». Но действие ещё не задаёт границу приёмки. Если заранее не определить, какой артефакт должен появиться, проверка начнётся слишком поздно: команда увидит красивый ответ и будет спорить уже о деталях реализации.
Представим интеграционный проект. Перед стартом нужно зафиксировать четыре вещи:
1. Какой результат существует физически: документ, запись в системе, изменение схемы или решение с указанным владельцем.
2. Какие свойства можно проверить автоматически: обязательные разделы, ссылки на источники, формат данных, наличие всех файлов.
3. Что считается неполным результатом: путь к будущему файлу, заглушка, фраза «уточняется», конфликт источников без вынесенного решения.
4. Кто принимает остаточный риск, если все технические проверки зелёные, а бизнес-ситуация всё ещё допускает несколько трактовок.
Без этого агент легко превращает неизвестное в уверенный текст. Например, в контракте указана одна версия API, в переписке с поставщиком — другая. Агент может выбрать одну и продолжить, хотя правильным исходом запуска было бы зафиксировать конфликт и вернуть его владельцу решения.
Поэтому evidence нужно собирать до запуска, а не после. Сначала записываем источники, их даты, владельцев и область действия. Затем формулируем критерий: что должно быть доказано и каким наблюдением это подтверждается. Только потом запускаем агента и проверяем, что он создал полный артефакт.
Такой порядок меняет и смысл зелёной галочки. Она показывает, что конкретная проверка прошла. Она не сообщает, что найден правильный ответ для пользователя. Проверка схемы не заменяет проверку содержания, а полный документ не означает, что его уже можно принять.
Практический минимум перед стартом:
— назовите будущий артефакт и место, где он должен появиться;
— выпишите обязательные свойства результата;
— перечислите известные отрицательные сценарии;
— укажите источники и владельцев спорных решений;
— назначьте человека, который имеет право принять остаточную неопределённость.
После этого агент получает измеримую границу работы. Аналитик сохраняет право остановить выполнение, если доказательства расходятся, а команда видит, что именно нужно пересмотреть.
Зелёная проверка отвечает только на тот вопрос, который в неё заложили.
Если чекер подтвердил схему JSON, это ещё не значит, что найден нужный артефакт. Если артефакт на месте, это ещё не значит, что он решает задачу пользователя. А если критерии выполнены, всё равно остаётся вопрос: кто принимает остаточный риск?
Поэтому перед передачей результата я фиксирую не только pass, но и границу проверки: что именно она покрывает, чего не покрывает и кто должен принять следующий шаг.
Если чекер подтвердил схему JSON, это ещё не значит, что найден нужный артефакт. Если артефакт на месте, это ещё не значит, что он решает задачу пользователя. А если критерии выполнены, всё равно остаётся вопрос: кто принимает остаточный риск?
Поэтому перед передачей результата я фиксирую не только pass, но и границу проверки: что именно она покрывает, чего не покрывает и кто должен принять следующий шаг.
Результат полезен только тогда, когда другой человек может пройти тот же путь проверки.
Поэтому к выводу нужно приложить не красивый пересказ, а исходный артефакт, точную ссылку на источник, версию критерия и описание того, что именно было проверено. Если шаг нельзя повторить, это наблюдение, а не evidence для приёмки.
Воспроизводимость важнее уверенного тона.
Поэтому к выводу нужно приложить не красивый пересказ, а исходный артефакт, точную ссылку на источник, версию критерия и описание того, что именно было проверено. Если шаг нельзя повторить, это наблюдение, а не evidence для приёмки.
Воспроизводимость важнее уверенного тона.
❤1
Хороший gate должен уметь не только пропускать результат, но и вовремя сказать «нет».
Самый опасный сценарий — не падение агента. Это зелёный ответ, который выглядит завершённым, но не содержит того, что обещал.
Например, агент вернул все обязательные поля, но внутри лежат пути к будущим файлам. Или документ заполнен заглушками. Или полный артефакт собран, но в нём применено старое правило, которое уже не действует.
Поэтому отрицательный путь нужно описывать заранее:
— что считаем незавершённым результатом;
— какой признак переводит его в отказ;
— сохраняем ли исходный ответ до ремонта;
— кто решает, можно ли повторить запуск;
— какие зависимые проверки становятся устаревшими после изменения требования.
Gate, который умеет только ставить зелёную галочку, проверяет happy path. Gate, который сохраняет причину отказа и границу проверки, помогает понять, что именно чинить.
Отказ — не провал процесса. Иногда это единственное честное свидетельство, что система не выдала результат за готовый.
Самый опасный сценарий — не падение агента. Это зелёный ответ, который выглядит завершённым, но не содержит того, что обещал.
Например, агент вернул все обязательные поля, но внутри лежат пути к будущим файлам. Или документ заполнен заглушками. Или полный артефакт собран, но в нём применено старое правило, которое уже не действует.
Поэтому отрицательный путь нужно описывать заранее:
— что считаем незавершённым результатом;
— какой признак переводит его в отказ;
— сохраняем ли исходный ответ до ремонта;
— кто решает, можно ли повторить запуск;
— какие зависимые проверки становятся устаревшими после изменения требования.
Gate, который умеет только ставить зелёную галочку, проверяет happy path. Gate, который сохраняет причину отказа и границу проверки, помогает понять, что именно чинить.
Отказ — не провал процесса. Иногда это единственное честное свидетельство, что система не выдала результат за готовый.
Зелёный тест отвечает только на тот вопрос, который в него заложили.
Можно проверить JSON, обязательные поля и схему — и всё равно не получить результата для пользователя. В поле окажется путь к будущему файлу, заглушка или старое правило.
Поэтому перед приёмкой я задаю пять вопросов:
1. Запрос завершился без технического обрыва?
2. Все обещанные артефакты существуют и непусты?
3. Источники и решения относятся к актуальной версии задачи?
4. Проверка действительно покрывает пользовательский сценарий?
5. Кто по имени принимает остаточный риск?
Если на последний вопрос нет ответа, «готово» означает только конец работы агента. Не принятие результата.
Можно проверить JSON, обязательные поля и схему — и всё равно не получить результата для пользователя. В поле окажется путь к будущему файлу, заглушка или старое правило.
Поэтому перед приёмкой я задаю пять вопросов:
1. Запрос завершился без технического обрыва?
2. Все обещанные артефакты существуют и непусты?
3. Источники и решения относятся к актуальной версии задачи?
4. Проверка действительно покрывает пользовательский сценарий?
5. Кто по имени принимает остаточный риск?
Если на последний вопрос нет ответа, «готово» означает только конец работы агента. Не принятие результата.
Руководитель просит оставить сотруднице старый доступ до пятницы: ей нужно передать незакрытые обращения. В учебном сценарии перевода в другую команду это сообщение лежит рядом с HR-заявкой, действующей политикой безопасности и каталогом ролей. Если собрать из них одну гладкую постановку, просьба легко превращается в якобы согласованное исключение.
У каждого источника своя роль. HR-заявка подтверждает перевод. Каталог показывает старую и новую роли. Политика запрещает их одновременное назначение. Сообщение руководителя объясняет рабочую потребность, но не меняет правило.
Старая роль поддержки несовместима с новой ролью в команде проверки операций. Правило допускает временное исключение только после отдельного согласования с ответственным за безопасность и фиксации его срока. В переписке такого решения нет. Просьба «до пятницы» не становится требованием на выдачу двух ролей только потому, что её написал руководитель.
Здесь аналитику важно не потерять ни потребность, ни ограничение. Команде действительно нужно передать дела. При этом выдача новой роли со старым доступом нарушит действующее правило, пока уполномоченный владелец не оформит допустимое исключение. В карте источников это конфликт; в постановке — открытое решение с владельцем; в приёмке — отдельные проверяемые пути.
Без исключения старая роль снимается до выдачи новой, пересечение ролей не допускается. Если исключение будет одобрено, проверка должна увидеть само решение, ответственного и срок действия. Пока решения нет, второй путь остаётся закрытым. Даже если система технически умеет назначить обе роли, это не доказывает, что так разрешено поступить.
Когда аналитик пишет «сохранить доступ до пятницы», он уже сделал выбор за ответственного по безопасности. Точная запись пока другая: «руководитель просит время на передачу дел; текущее правило запрещает пересечение ролей; допустимость и срок исключения требуют отдельного решения». Так разработка видит, что реализовать сейчас, а какой вопрос нельзя спрятать в формулировке требования.
У каждого источника своя роль. HR-заявка подтверждает перевод. Каталог показывает старую и новую роли. Политика запрещает их одновременное назначение. Сообщение руководителя объясняет рабочую потребность, но не меняет правило.
Старая роль поддержки несовместима с новой ролью в команде проверки операций. Правило допускает временное исключение только после отдельного согласования с ответственным за безопасность и фиксации его срока. В переписке такого решения нет. Просьба «до пятницы» не становится требованием на выдачу двух ролей только потому, что её написал руководитель.
Здесь аналитику важно не потерять ни потребность, ни ограничение. Команде действительно нужно передать дела. При этом выдача новой роли со старым доступом нарушит действующее правило, пока уполномоченный владелец не оформит допустимое исключение. В карте источников это конфликт; в постановке — открытое решение с владельцем; в приёмке — отдельные проверяемые пути.
Без исключения старая роль снимается до выдачи новой, пересечение ролей не допускается. Если исключение будет одобрено, проверка должна увидеть само решение, ответственного и срок действия. Пока решения нет, второй путь остаётся закрытым. Даже если система технически умеет назначить обе роли, это не доказывает, что так разрешено поступить.
Когда аналитик пишет «сохранить доступ до пятницы», он уже сделал выбор за ответственного по безопасности. Точная запись пока другая: «руководитель просит время на передачу дел; текущее правило запрещает пересечение ролей; допустимость и срок исключения требуют отдельного решения». Так разработка видит, что реализовать сейчас, а какой вопрос нельзя спрятать в формулировке требования.
Система отправила команду на изменение доступа и получила
Только доступы ещё не изменились.
В учебном сценарии перевода сотрудника между командами API отвечает
Здесь смешиваются два разных факта:
- технический факт: сервис принял запрос;
- бизнес-факт: у сотрудника действительно появился нужный доступ и исчез старый.
Первый можно подтвердить сразу. Для второго нужно продолжить наблюдение.
Проверка начинается с идентификатора операции. По нему система отслеживает состояние до терминального результата и сохраняет итог каждого шага. Если новая роль выдана, а старая не отозвана, это не «почти готово». Это отдельное состояние частичного успеха с задачей на восстановление.
После терминального статуса всё равно остаётся ещё одна проверка: запросить фактический набор ролей и сопоставить его с ожидаемым. Только так можно отличить запись «шаг выполнен» от реального результата для пользователя и процесса.
В постановке это меняет само определение завершённости. Нельзя писать: «операция успешна, если API вернул 202». Нужна цепочка:
1. запрос принят и получил идентификатор;
2. операция дошла до терминального состояния;
3. каждый обязательный шаг подтверждён;
4. фактическое состояние сверено с ожидаемым;
5. частичный результат не скрыт за общим зелёным статусом.
Та же ошибка встречается далеко за пределами управления доступом. Задача поставлена в очередь, файл обещан в JSON, письмо передано провайдеру, платёж принят в обработку. Во всех этих случаях ответ системы может означать «начали», хотя интерфейс уже показывает «готово».
Поэтому асинхронный контракт нужно читать как протокол наблюдения. Команда запускает работу. Статусы описывают её ход. Сверка подтверждает результат. Если остановиться на первом зелёном ответе, аналитик проверит транспорт и пропустит бизнес-исход.
202 Accepted. В отчёте появилась зелёная отметка: операция завершена.Только доступы ещё не изменились.
В учебном сценарии перевода сотрудника между командами API отвечает
202, когда ставит запрос в очередь. Дальше операция может ждать исполнения, выполняться, завершиться успешно, упасть целиком или применить только часть изменений. Сам HTTP-ответ не говорит, какой из этих исходов произошёл.Здесь смешиваются два разных факта:
- технический факт: сервис принял запрос;
- бизнес-факт: у сотрудника действительно появился нужный доступ и исчез старый.
Первый можно подтвердить сразу. Для второго нужно продолжить наблюдение.
Проверка начинается с идентификатора операции. По нему система отслеживает состояние до терминального результата и сохраняет итог каждого шага. Если новая роль выдана, а старая не отозвана, это не «почти готово». Это отдельное состояние частичного успеха с задачей на восстановление.
После терминального статуса всё равно остаётся ещё одна проверка: запросить фактический набор ролей и сопоставить его с ожидаемым. Только так можно отличить запись «шаг выполнен» от реального результата для пользователя и процесса.
В постановке это меняет само определение завершённости. Нельзя писать: «операция успешна, если API вернул 202». Нужна цепочка:
1. запрос принят и получил идентификатор;
2. операция дошла до терминального состояния;
3. каждый обязательный шаг подтверждён;
4. фактическое состояние сверено с ожидаемым;
5. частичный результат не скрыт за общим зелёным статусом.
Та же ошибка встречается далеко за пределами управления доступом. Задача поставлена в очередь, файл обещан в JSON, письмо передано провайдеру, платёж принят в обработку. Во всех этих случаях ответ системы может означать «начали», хотя интерфейс уже показывает «готово».
Поэтому асинхронный контракт нужно читать как протокол наблюдения. Команда запускает работу. Статусы описывают её ход. Сверка подтверждает результат. Если остановиться на первом зелёном ответе, аналитик проверит транспорт и пропустит бизнес-исход.
Правдоподобная догадка не закрывает открытый вопрос
Открытый вопрос остаётся открытым, даже если агент предложил ответ, который выглядит технически разумно.
В синтетическом учебном кейсе Acme Pay документация требует использовать экспоненциальную задержку для повторной доставки вебхуков. На этом описание заканчивается. Сколько делать попыток? С какой задержки начинать? Какой установить предел? Когда считать доставку окончательно неудачной? В карте источников это пробел G01.
Агент легко достроит недостающие параметры. Например: три попытки с интервалами 1, 2 и 4 секунды, затем перенос события в отдельную очередь. Такой вариант похож на распространённую инженерную практику. Его можно аккуратно оформить, добавить схему и даже превратить в тесты.
Проблема возникает, когда правдоподобный вариант попадает в постановку как установленное правило. У него нет источника и владельца. Команда начинает писать обработчик, тестировщик фиксирует ожидаемые интервалы, а эксплуатация настраивает наблюдение. Одна догадка незаметно становится общей зависимостью.
Здесь полезно разделить три состояния.
Известно: провайдер требует экспоненциальную задержку.
Предложено: три попытки с интервалами 1, 2 и 4 секунды. Это вариант для обсуждения, а не часть контракта.
Открыто: точные параметры, предел ожидания и поведение после исчерпания попыток. Ответ должен дать владелец внешнего контракта или человек, уполномоченный принять риск внутри команды.
Пока ответа нет, аналитик всё равно может двигать работу. Можно описать места настройки, ограничения очереди, требования к идемпотентности, наблюдаемость и несколько сценариев отказа. Нельзя только выдавать выбранные числа за подтверждённое ожидание.
Для агента это тоже отдельное правило работы: он может предложить варианты и объяснить последствия каждого, но не должен менять статус вопроса с
Иначе тесты проверят не контракт, а первую убедительную догадку. Зелёный результат закрепит её ещё сильнее, хотя исходный пробел никуда не исчез.
Хорошая постановка показывает границу знания. В ней видно, что пришло из источника, что предложено для обсуждения и какое решение команда пока не имеет права считать принятым.
Открытый вопрос остаётся открытым, даже если агент предложил ответ, который выглядит технически разумно.
В синтетическом учебном кейсе Acme Pay документация требует использовать экспоненциальную задержку для повторной доставки вебхуков. На этом описание заканчивается. Сколько делать попыток? С какой задержки начинать? Какой установить предел? Когда считать доставку окончательно неудачной? В карте источников это пробел G01.
Агент легко достроит недостающие параметры. Например: три попытки с интервалами 1, 2 и 4 секунды, затем перенос события в отдельную очередь. Такой вариант похож на распространённую инженерную практику. Его можно аккуратно оформить, добавить схему и даже превратить в тесты.
Проблема возникает, когда правдоподобный вариант попадает в постановку как установленное правило. У него нет источника и владельца. Команда начинает писать обработчик, тестировщик фиксирует ожидаемые интервалы, а эксплуатация настраивает наблюдение. Одна догадка незаметно становится общей зависимостью.
Здесь полезно разделить три состояния.
Известно: провайдер требует экспоненциальную задержку.
Предложено: три попытки с интервалами 1, 2 и 4 секунды. Это вариант для обсуждения, а не часть контракта.
Открыто: точные параметры, предел ожидания и поведение после исчерпания попыток. Ответ должен дать владелец внешнего контракта или человек, уполномоченный принять риск внутри команды.
Пока ответа нет, аналитик всё равно может двигать работу. Можно описать места настройки, ограничения очереди, требования к идемпотентности, наблюдаемость и несколько сценариев отказа. Нельзя только выдавать выбранные числа за подтверждённое ожидание.
Для агента это тоже отдельное правило работы: он может предложить варианты и объяснить последствия каждого, но не должен менять статус вопроса с
OPEN на RESOLVED. Это делает человек и оставляет след решения: кто выбрал вариант, когда, для какой версии интеграции и на каком основании.Иначе тесты проверят не контракт, а первую убедительную догадку. Зелёный результат закрепит её ещё сильнее, хотя исходный пробел никуда не исчез.
Хорошая постановка показывает границу знания. В ней видно, что пришло из источника, что предложено для обсуждения и какое решение команда пока не имеет права считать принятым.
У аналитика есть соблазн считать результат принятым, если его содержание верно. Но у результата есть ещё форма доставки.
На этой неделе у нас вышел пост в LinkedIn. Текст был вычитан и принят, публикация появилась, ссылка сохранилась. Но платформа отобразила форматирование так, что читать стало заметно труднее.
Это не косметический дефект. Если структура помогает отличить условие от вывода, список от пояснения, а абзац от оговорки, то после публикации меняется не только внешний вид. Меняется то, как читатель восстанавливает смысл.
Поэтому для публичного материала полезно разделять три проверки:
1. Содержание соответствует принятой редакции.
2. Платформа сохранила логическую структуру.
3. Результат читается в конечном интерфейсе.
Статус «опубликовано» подтверждает доставку. Приёмка заканчивается после проверки того, что увидел читатель.
На этой неделе у нас вышел пост в LinkedIn. Текст был вычитан и принят, публикация появилась, ссылка сохранилась. Но платформа отобразила форматирование так, что читать стало заметно труднее.
Это не косметический дефект. Если структура помогает отличить условие от вывода, список от пояснения, а абзац от оговорки, то после публикации меняется не только внешний вид. Меняется то, как читатель восстанавливает смысл.
Поэтому для публичного материала полезно разделять три проверки:
1. Содержание соответствует принятой редакции.
2. Платформа сохранила логическую структуру.
3. Результат читается в конечном интерфейсе.
Статус «опубликовано» подтверждает доставку. Приёмка заканчивается после проверки того, что увидел читатель.
Критерий, который не умеет отклонять результат, ничего не проверяет.
Команда заранее описывает позитивный сценарий, превращает его в тест и получает зелёный статус. Кажется, что всё сделано правильно: критерий появился до реализации, агент выполнил работу, тест прошёл.
Но у такого Green есть слабое место. Мы знаем, какой результат проверка принимает. Не знаем, способна ли она отказать хотя бы одному правдоподобному, но неправильному результату.
Поэтому до реализации полезен negative-path gate, проверка отрицательного сценария: назовите один реалистичный исход, который выглядит убедительно, но должен быть отклонён. Затем убедитесь, что критерий действительно его отсекает.
Синтетический пример.
Система должна отменять заказ. Критерий приёмки проверяет три вещи:
— API вернул 200;
— в интерфейсе появился статус «Отменён»;
— создана операция возврата.
Все три условия могут пройти, даже если заказ уже передан в доставку. Получится согласованный набор зелёных сигналов и неправильный бизнес-результат: деньги возвращены, а товар продолжает ехать к клиенту.
Проверка становится содержательной, когда в ней появляется отрицательный сценарий:
если отправление уже передано перевозчику, отмена должна быть отклонена с определённой причиной; статус заказа не меняется; возврат не создаётся; попытка остаётся в журнале.
Теперь критерий умеет не только подтвердить ожидаемое поведение, но и остановить правдоподобную ошибку.
Это не означает, что на каждый сценарий нужно придумать десятки исключений. Достаточно начать с одного исхода, который команда действительно боится пропустить: повторного списания, обхода права доступа, потери ограничения, принятия устаревшего источника, успешного ответа без обещанного артефакта.
В TDPD Red gate нужен не ради красного цвета в отчёте. Он показывает, что проверка способна обнаружить отсутствие нужного поведения до реализации. Green после этого означает инженерное соответствие заданному сценарию, но ещё не финальную пригодность результата.
Последнее решение остаётся на UAT. Человек проверяет, тот ли риск был заложен в критерий, не потерялся ли смысл за формально правильными сигналами и можно ли принять остаточный риск.
Если проверка принимает всё, она не защищает от ошибки. Она только оформляет разрешение двигаться дальше.
Команда заранее описывает позитивный сценарий, превращает его в тест и получает зелёный статус. Кажется, что всё сделано правильно: критерий появился до реализации, агент выполнил работу, тест прошёл.
Но у такого Green есть слабое место. Мы знаем, какой результат проверка принимает. Не знаем, способна ли она отказать хотя бы одному правдоподобному, но неправильному результату.
Поэтому до реализации полезен negative-path gate, проверка отрицательного сценария: назовите один реалистичный исход, который выглядит убедительно, но должен быть отклонён. Затем убедитесь, что критерий действительно его отсекает.
Синтетический пример.
Система должна отменять заказ. Критерий приёмки проверяет три вещи:
— API вернул 200;
— в интерфейсе появился статус «Отменён»;
— создана операция возврата.
Все три условия могут пройти, даже если заказ уже передан в доставку. Получится согласованный набор зелёных сигналов и неправильный бизнес-результат: деньги возвращены, а товар продолжает ехать к клиенту.
Проверка становится содержательной, когда в ней появляется отрицательный сценарий:
если отправление уже передано перевозчику, отмена должна быть отклонена с определённой причиной; статус заказа не меняется; возврат не создаётся; попытка остаётся в журнале.
Теперь критерий умеет не только подтвердить ожидаемое поведение, но и остановить правдоподобную ошибку.
Это не означает, что на каждый сценарий нужно придумать десятки исключений. Достаточно начать с одного исхода, который команда действительно боится пропустить: повторного списания, обхода права доступа, потери ограничения, принятия устаревшего источника, успешного ответа без обещанного артефакта.
В TDPD Red gate нужен не ради красного цвета в отчёте. Он показывает, что проверка способна обнаружить отсутствие нужного поведения до реализации. Green после этого означает инженерное соответствие заданному сценарию, но ещё не финальную пригодность результата.
Последнее решение остаётся на UAT. Человек проверяет, тот ли риск был заложен в критерий, не потерялся ли смысл за формально правильными сигналами и можно ли принять остаточный риск.
Если проверка принимает всё, она не защищает от ошибки. Она только оформляет разрешение двигаться дальше.
У проекта может быть полный набор документов и всё равно не быть ответа, который можно безопасно передать разработке.
В Source Map пробелы выглядят менее впечатляюще, чем готовые строки. Например, документация говорит про exponential backoff, но не задаёт параметры retry policy. Формально материал есть. Практического правила, по которому можно написать проверку, нет.
Самая опасная реакция — позволить агенту заполнить пропуск правдоподобным значением. Так появляется спецификация, которая нигде не была принята. Она выглядит лучше, чем UNKNOWN, но хуже работает в эксплуатации: никто не знает, какое решение пересматривать, когда появится уточнение.
Я разделяю три состояния:
1. Известно. Есть источник, владелец и проверяемое решение.
2. Противоречит. Есть несколько источников, и конфликт вынесен отдельным вопросом.
3. UNKNOWN. Нужного правила нет или его нельзя вывести из доступных материалов.
У каждого состояния должен быть следующий шаг. Для UNKNOWN это не «попросить агента подумать ещё». Это указать, кому задать вопрос, какую часть системы он затрагивает и какая проверка появится после ответа.
Такой формат полезен и при приёмке. Пока вопрос открыт, зелёный технический тест не может считаться доказательством требования. После решения проверка получает основание, владельца и границу применимости.
UNKNOWN не означает, что работа остановлена. Он показывает, где работа ещё не стала решением.
В Source Map пробелы выглядят менее впечатляюще, чем готовые строки. Например, документация говорит про exponential backoff, но не задаёт параметры retry policy. Формально материал есть. Практического правила, по которому можно написать проверку, нет.
Самая опасная реакция — позволить агенту заполнить пропуск правдоподобным значением. Так появляется спецификация, которая нигде не была принята. Она выглядит лучше, чем UNKNOWN, но хуже работает в эксплуатации: никто не знает, какое решение пересматривать, когда появится уточнение.
Я разделяю три состояния:
1. Известно. Есть источник, владелец и проверяемое решение.
2. Противоречит. Есть несколько источников, и конфликт вынесен отдельным вопросом.
3. UNKNOWN. Нужного правила нет или его нельзя вывести из доступных материалов.
У каждого состояния должен быть следующий шаг. Для UNKNOWN это не «попросить агента подумать ещё». Это указать, кому задать вопрос, какую часть системы он затрагивает и какая проверка появится после ответа.
Такой формат полезен и при приёмке. Пока вопрос открыт, зелёный технический тест не может считаться доказательством требования. После решения проверка получает основание, владельца и границу применимости.
UNKNOWN не означает, что работа остановлена. Он показывает, где работа ещё не стала решением.
Не начинайте требование со слов «система должна».
Сначала ответьте на три вопроса:
— кто действует;
— в какой ситуации;
— что он пытается изменить.
«Система должна показывать статус заявки» почти ничего не объясняет.
«Оператор перед звонком клиенту проверяет, можно ли продолжить обработку заявки» уже показывает участника, момент и решение, которое ему нужно принять.
Техническое поведение можно описать следующим шагом. Сначала нужен смысл действия.
На этой неделе каждый день будем разбирать по одному простому вопросу, который делает требование проверяемым.
Сначала ответьте на три вопроса:
— кто действует;
— в какой ситуации;
— что он пытается изменить.
«Система должна показывать статус заявки» почти ничего не объясняет.
«Оператор перед звонком клиенту проверяет, можно ли продолжить обработку заявки» уже показывает участника, момент и решение, которое ему нужно принять.
Техническое поведение можно описать следующим шагом. Сначала нужен смысл действия.
На этой неделе каждый день будем разбирать по одному простому вопросу, который делает требование проверяемым.
CRM показывает
Названия поля недостаточно. В требовании нужно зафиксировать две вещи: какой источник имеет право определять решение и как долго его ответ считается актуальным.
В нашем синтетическом примере решение о продолжении обработки приходит из сервиса риска. CRM хранит состояние процесса, но не переопределяет риск. Поэтому оператор видит
Есть и вторая граница — свежесть. Допустим, ответ сервиса риска старше 15 минут. Эти 15 минут — учебное значение, не отраслевой норматив и не реальная политика. Правило примера простое: устаревший ответ нельзя показывать как текущий; сначала нужно запросить новый.
Так одно поле превращается в проверяемое требование:
— назван авторитетный источник;
— задан срок актуальности;
— описано поведение при конфликте;
— описано поведение при устаревании.
Если не записать авторитет и свежесть, система всё равно выберет значение. Только это будет технический порядок чтения данных, а не принятое решение.
APPROVED. Сервис риска — REVIEW_REQUIRED. Какой статус должен увидеть оператор?Названия поля недостаточно. В требовании нужно зафиксировать две вещи: какой источник имеет право определять решение и как долго его ответ считается актуальным.
В нашем синтетическом примере решение о продолжении обработки приходит из сервиса риска. CRM хранит состояние процесса, но не переопределяет риск. Поэтому оператор видит
REVIEW_REQUIRED, даже если в CRM осталось APPROVED.Есть и вторая граница — свежесть. Допустим, ответ сервиса риска старше 15 минут. Эти 15 минут — учебное значение, не отраслевой норматив и не реальная политика. Правило примера простое: устаревший ответ нельзя показывать как текущий; сначала нужно запросить новый.
Так одно поле превращается в проверяемое требование:
— назван авторитетный источник;
— задан срок актуальности;
— описано поведение при конфликте;
— описано поведение при устаревании.
Если не записать авторитет и свежесть, система всё равно выберет значение. Только это будет технический порядок чтения данных, а не принятое решение.
Позитивный сценарий обычно помещается в одну строку: оператор запускает проверку, сервис риска отвечает, обработка продолжается.
А что произойдёт, если сервис недоступен?
Плохой ответ — молча показать последнее известное решение. Интерфейс будет выглядеть рабочим, но оператор примет старые данные за текущие.
Проверяемый отрицательный путь выглядит иначе:
— обработка остаётся заблокированной;
— оператор видит, что проверка не завершилась;
— прошлый результат не помечается как актуальный;
— повторная попытка возможна, но не превращается в скрытое разрешение продолжить работу.
Такое описание не требует перечислять все будущие ошибки. Достаточно назвать один реалистичный сбой, видимый результат и действие, которое система точно не должна совершать.
Позитивный путь показывает демонстрацию. Отрицательный — границу доверия к результату.
А что произойдёт, если сервис недоступен?
Плохой ответ — молча показать последнее известное решение. Интерфейс будет выглядеть рабочим, но оператор примет старые данные за текущие.
Проверяемый отрицательный путь выглядит иначе:
— обработка остаётся заблокированной;
— оператор видит, что проверка не завершилась;
— прошлый результат не помечается как актуальный;
— повторная попытка возможна, но не превращается в скрытое разрешение продолжить работу.
Такое описание не требует перечислять все будущие ошибки. Достаточно назвать один реалистичный сбой, видимый результат и действие, которое система точно не должна совершать.
Позитивный путь показывает демонстрацию. Отрицательный — границу доверия к результату.
«Показывать статус заявки» — так требование выглядело в начале.
После уточнений оказалось, что важен не любой статус. Решение о продолжении обработки принимает сервис риска, а CRM только хранит состояние процесса. Старый или недоступный ответ нельзя выдавать за текущий.
Финальная формулировка стала другой:
«Показывать оператору актуальное решение сервиса риска. Если ответ недоступен или устарел, блокировать продолжение обработки и показывать причину».
Полезно сохранить рядом четыре записи:
— было: «показывать статус заявки»;
— вопрос: какой источник определяет решение;
— решение: авторитетен сервис риска;
— стало: показывать его актуальный ответ и явно обрабатывать отсутствие данных.
Так видно не только последнюю фразу, но и причину изменения. Если источник или правило свежести поменяются, команда поймёт, какое решение и какие проверки нужно пересмотреть.
Хорошее требование — не текст, который однажды красиво сформулировали. Это короткий след принятых уточнений.
После уточнений оказалось, что важен не любой статус. Решение о продолжении обработки принимает сервис риска, а CRM только хранит состояние процесса. Старый или недоступный ответ нельзя выдавать за текущий.
Финальная формулировка стала другой:
«Показывать оператору актуальное решение сервиса риска. Если ответ недоступен или устарел, блокировать продолжение обработки и показывать причину».
Полезно сохранить рядом четыре записи:
— было: «показывать статус заявки»;
— вопрос: какой источник определяет решение;
— решение: авторитетен сервис риска;
— стало: показывать его актуальный ответ и явно обрабатывать отсутствие данных.
Так видно не только последнюю фразу, но и причину изменения. Если источник или правило свежести поменяются, команда поймёт, какое решение и какие проверки нужно пересмотреть.
Хорошее требование — не текст, который однажды красиво сформулировали. Это короткий след принятых уточнений.
Что на самом деле доказывает зелёный тест?
Он показывает, что реализация соответствует записанному правилу.
Но если само правило неверно, тест может идеально охранять ошибку.
Независимая приёмка начинается не с повторения постановки. Она начинается с ожидаемого пользовательского сценария и решения команды, принятых до оценки реализации.
Проверьте один свой зелёный тест: откуда взялся ожидаемый результат?
Он показывает, что реализация соответствует записанному правилу.
Но если само правило неверно, тест может идеально охранять ошибку.
Независимая приёмка начинается не с повторения постановки. Она начинается с ожидаемого пользовательского сценария и решения команды, принятых до оценки реализации.
Проверьте один свой зелёный тест: откуда взялся ожидаемый результат?