Планування роботи

План перевірок до написання коду

У главах 18–21 ми сформували межу роботи, обрали вертикальний зріз, описали залежності й склали послідовність реалізації. Тепер до першої зміни коду…

Глава 22Заморожене українське видання

У главах 18–21 ми сформували межу роботи, обрали вертикальний зріз, описали залежності й склали послідовність реалізації. Тепер до першої зміни коду треба відповісти на інше запитання: за якими спостереженнями ми вирішимо, що потрібна поведінка з’явилася, а важливі суміжні сценарії не зламалися?

План перевірок — це домовленість про ризики, сценарії, очікувані результати, середовище та докази. Він не є переліком бажаних бібліотек, обіцянкою автоматизувати все чи звітом про вже виконану роботу. До реалізації в ньому є очікування та способи перевірки; після запуску до нього додаються фактичні результати й обмеження.

Ця глава продовжує планування після глав 10–21; детальну механіку різних видів тестів розглянуто в главах 48–49.

Приклади бронювання й імпорту нижче навчальні. Назви сервісів, записи, правила й результати вигадані. Коли приклад приймає конкретне продуктове правило, воно позначене як умова прикладу, а не як універсальна вимога.

22.1. Три різні речі: критерій, тест і доказ

Критерій приймання формулює, якою має бути поведінка або результат. Він відповідає: «Що повинно бути правдою для користувача, даних чи оператора?»

Тест описує дію або спостереження, за допомогою якого ми перевіряємо критерій. Він відповідає: «Що саме зробимо, у якому стані й на якому рівні системи?»

Доказ — фактичний результат виконання тесту: що спостерігали, на якій версії, у якому середовищі й коли. Він відповідає: «Що відбулося цього разу?» До запуску можна спланувати доказ, але не можна вже мати результат майбутнього запуску.

Рівень	Приклад
Критерій	Якщо бронювання вже зайняте іншим клієнтом, перенесення не відбувається, а чинний запис клієнта лишається без змін.
Тест	Створити бронювання A для клієнта, зайняти цільовий слот бронюванням Б, спробувати перенести A в цей слот.
Очікування тесту	Сервер повертає визначену відмову; A зберігає початковий час; Б лишається власником цільового слота; сповіщення про успіх не надсилається.
Доказ після виконання	Результат запуску конкретного тесту, фактичний стан записів до й після, ідентифікатор збірки або ревізії, налаштування середовища й часовий штамп.

Ці записи не можна підміняти один одним. Текст «тест успішний» без критерію не пояснює, яку обіцянку перевірили. Критерій без тесту може залишитися неперевіреним. Список тестів без результатів не доводить, що їх виконали. А зелений результат для іншої ревізії коду не доводить поведінку поточного кандидата.

Так само не зливайте критерій і очікуваний механізм. «Користувач побачить актуальний час бронювання» — поведінка. «Екран викличе функцію refreshBooking()» — гіпотеза про реалізацію. До написання коду спосіб ще може змінитися; очікування для користувача має лишитися сталим.

Тест як спостережуваний експеримент

Корисний тест можна відтворити. У ньому відомі:

початковий стан;
дія або подія;
умови середовища, що впливають на результат;
очікуване спостереження;
спосіб зафіксувати фактичне спостереження;
очищення даних або відновлення середовища, якщо це потрібно.

Нечітке «перевірити, що все працює» не задає ні дії, ні правильного результату. Перепишіть його: «Для користувача з роллю клієнта відкрити підтвердження бронювання з ідентифікатором тестового запису; на сторінці має бути показано той самий час і часовий пояс, що повертає джерело даних; знімок екрана та відповідь тестового API (Application Programming Interface — програмний інтерфейс застосунку) прикріпити до звіту». Коли приватні дані не можна показувати, доказ має містити синтетичний запис або безпечне узагальнення, а не приховані персональні відомості.

22.2. Від проблеми до покриття

План починається з проблеми та обіцяного результату, а не з того, які перевірки легко написати. Зв’язок із попередніми главами такий:

глава 18 задає межу зміни й невідомі, які треба зняти;
глава 19 формулює корисний наскрізний зріз і поведінку, доступну користувачу;
глава 20 показує залежності, спільний стан і місця одночасної роботи;
глава 21 задає кроки реалізації, переходи між етапами й докази;
ця глава переводить кожну обіцянку та суттєвий ризик у запланований спосіб спостереження.

План повинен робити прогалини видимими. Якщо критерій ще не погоджений, запишіть відкрите питання й власника рішення. Не вигадуйте відповідь самостійно, а потім не перетворюйте її на тест так, ніби вона вже була вимогою. Якщо поведінку неможливо перевірити через недоступне середовище, назвіть це обмеження окремо.

Обсяг перевірки

Почніть із того, що змінюється, а потім перевірте оточення зміни:

нова або змінена поведінка;
суміжні сценарії, які використовують ту саму функцію чи дані;
дозволи, ролі й межі між користувачами;
контракт із зовнішнім сервісом;
записи в базі, міграція й старі клієнти;
події, повторні спроби, черги та паралельні запити;
повідомлення, журнали, метрики й інструкції підтримки;
швидкість, доступність інтерфейсу й відновлення після помилки;
що свідомо не перевіряється і чому.

Обсяг має бути пропорційним наслідкам і ймовірності відмови. Помилка, яка відкриває чужі дані або втрачає єдине бронювання, потребує більше уваги, ніж зміна декоративного тексту. Але розмір зміни сам собою не гарантує низький ризик: дві строки конфігурації можуть змінити компіляцію всіх образів пристроїв.

Зручна оцінка — наслідок × правдоподібність. Це не точна формула й не привід вигадувати десяткові бали. Вона допомагає порівняти: «що станеться, якщо це зламається?» та «наскільки реальний цей шлях відмови?». Окремо врахуйте, чи можна помітити помилку й відновити стан. Незворотна дія може вимагати сильнішого доказу ще до запуску.

Матриця покриття

Початковий робочий формат:

ID (ідентифікатор)	Критерій або ризик	Сценарій і початковий стан	Рівень і дані	Очікуваний результат	Запланований доказ	Власник
T-01	Критерій C-1	Дія за нормальних умов	Компонентний; запис із синтетичними даними	Описана поведінка та стан	Результат автоматичного запуску, ревізія	Автор зміни
T-02	Ризик: зовнішній тайм-аут	Віддалена дія могла завершитися, відповідь загубилася	Інтеграційний із керованим сервісом-заглушкою	Немає дубля чи неправдивого успіху	Журнал події й підсумковий стан запису	Власник інтеграції
T-03	Критерій C-2	Людина користується зміненим екраном	Ручне дослідження на тестовому середовищі	Користувач знаходить і розуміє результат	Протокол спостереження без персональних даних	Дослідник

Матриця не повинна бути багатою на рядки заради кількості. Один рядок на кожен критерій із окремою перевіркою може бути достатнім для простої зміни. Для складної операції один критерій може мати кілька рядків: від локальної перевірки правила до інтеграції, ручного сценарію й відновлення після часткового збою.

Для кожного критерію позначте один із трьох варіантів:

покритий конкретним тестом;
покритий свідомо вибраною ручною перевіркою;
поки не покритий — із причиною, власником ризику та наступною дією.

Прогалина, названа в плані, ще не стає безпечною автоматично. Її має прийняти людина, уповноважена вирішувати відповідний ризик. Непокритий сценарій не повинен губитися за загальним словом «протестовано».

22.3. Нормальні, негативні, граничні та паралельні сценарії

Звичний сценарій — лише перший рядок

Звичний або «щасливий» шлях — один типовий сценарій, який завершується очікуваним успіхом. Він потрібен, але не показує, як система поводиться при помилці, межі, повторі або суперечці за спільний ресурс.

Для кожного критичного критерію запитайте:

Що змінюється, коли вхід невалідний, неповний або застарілий?
Що стається на межі допустимого значення, а також відразу по обидва боки від неї?
Чи може користувач не мати потрібної ролі або втратити її під час операції?
Що буде, якщо дія надійде двічі?
Що буде, якщо дві дії відбуваються одночасно?
Які частини могли завершитися до помилки?
Що показує система, якщо зовнішній сервіс повільний, недоступний або повернув неповну відповідь?
Чи залишається старий клієнт сумісним із новим контрактом?

Застосовуйте ці запитання там, де вони стосуються предметної області. Для суми платежу межа нуль і граничне значення можуть бути важливі. Для перегляду списку — порожній результат, остання сторінка й повторне завантаження. Для доступу — дозволена роль, заборонена роль і зміна власника даних. Не треба механічно додавати всі види до кожної функції.

Негативні й граничні випадки

Негативний випадок перевіряє, як система відмовляє без небажаного побічного ефекту. Граничний випадок перевіряє поведінку на краю правил.

Залежно від предметної області розгляньте:

порожнє, відсутнє або надто довге поле;
мінімальне значення, найбільше дозволене значення й значення на одиницю вище;
дату на межі дня, часовий пояс або зміну календарної дати;
вже використаний, прострочений або скасований запис;
повторний токен, ідентифікатор чи файл;
непередбачену послідовність статусів;
відмову в доступі;
завеликий обсяг даних або довгу затримку;
неправильну, стару або відсутню конфігурацію.

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

Повтори й ідемпотентність

Ідемпотентна операція зберігає той самий бізнес-результат, якщо її випадково повторити. Наприклад, повторна доставка повідомлення про одну й ту саму оплату не повинна стягнути оплату вдруге. Це не обов’язково означає ідентичну відповідь на кожен повтор: друга відповідь може прямо сказати «вже оброблено», якщо стан не дублюється.

Для ризикованої операції перевірте:

перше звернення завершується успішно;
клієнт повторює його з тим самим ключем або ідентифікатором;
два однакові запити надходять паралельно;
повтор настає після тайм-ауту, коли результат першої спроби невідомий;
новий ключ справді означає нову бізнес-дію, якщо це дозволено.

Критерій має уточнювати, що рахується «однією дією»: ідентифікатор події, операції, запису чи запиту. Автоматичне повторення саме собою не робить систему безпечною. Повтор може лише збільшити кількість списань або зовнішніх записів.

Конкурентні дії

Конкурентний сценарій перевіряє дії, що перекриваються в часі. Послідовний тест може проходити, хоча в реальності два клієнти одночасно забирають один слот або два процеси обробляють одну подію.

Запишіть точну передумову: скільки ресурсів є, хто за нього змагається, які запити стартують до завершення інших, і який інваріант має зберегтися. Інваріант — правило, яке має залишатися правдивим у всіх допустимих результатах, наприклад «в один час активним власником слота є не більше одного бронювання».

Визначте, де синхронізується дія: транзакція бази даних, блокування, унікальне обмеження, зовнішній постачальник чи інший механізм. План до реалізації може назвати питання без того, щоб нав’язувати реалізацію: «Який шар гарантує єдиного власника слота, якщо обидва клієнти надсилають запит одночасно?» Якщо відповідь невідома, глава 18 називає це невідомим, яке слід зняти до ставки на повну реалізацію.

Тайм-аути й часткові відмови

Часткова відмова виникає, коли одна частина операції завершилась, а наступна — ні. Приклад: зовнішній календар створив новий запис, але з’єднання обірвалося до відповіді; локальна система не знає, чи треба повторити команду. Інший приклад: зміна вже збережена, але сповіщення не надіслано.

План має розкласти операцію на видимі переходи:

що система вважає підтвердженим;
де записується намір;
що можна повторити без дублювання;
який стан позначає невідомий результат;
хто або що звіряє його із зовнішньою стороною;
що повідомляємо користувачу;
як оператор відновлює або завершує дію.

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

22.4. Рівень перевірки відповідає місцю ризику

Рівні перевірки — це вибір найдешевшого місця, яке здатне виявити саме цей дефект. Це не обов’язкове змагання за максимальну кількість повних сценаріїв.

Рівень	Що перевіряється	Для чого особливо корисний	Що сам не доводить
Перевірка одиничного правила	Одна функція або чисте перетворення даних	Межі значень, правило доступу, обчислення	Підключення компонентів чи справжній зовнішній контракт
Перевірка взаємодії	Кілька компонентів разом, часто з керованою базою чи сервісом-заглушкою	Транзакція, запис даних, обробка помилки, повтор	Поведінку реального постачальника в його середовищі
Перевірка контракту	Взаємну домовленість між сервісом і споживачем	Формат, типи, статуси, сумісність версій	Доступність реального постачальника й повний користувацький шлях
Наскрізна перевірка	Повний шлях через кілька систем до видимого результату	Критичні інтеграції та випускні ризики	Повноту всіх значень та рідкісних станів
Ручне дослідження	Людина пробує сценарії й спостерігає непередбачені проблеми	Зрозумілість інтерфейсу, дослідження незнайомої поведінки, контекст	Повторювану перевірку кожної комбінації або сталу регресійну гарантію

«Ми перевіряємо тільки наскрізно» звучить переконливо, але часто створює повільний і нестабільний набір, де важко зрозуміти причину падіння. «Ми перевірили кожну функцію окремо» теж може приховати несумісність між частинами. Розташуйте перевірки там, де вони найраніше й надійніше бачать потрібне порушення; критичні наскрізні ризики все одно перевірте повним шляхом.

У документації Playwright приклади перевірок сторінки використовують твердження, що повторно зчитують елемент до очікуваного тексту або завершення часу очікування. Такий механізм допомагає зі звичайним асинхронним оновленням інтерфейсу, але не виправляє хибне очікування чи повільне середовище. Там само документація попереджає, що твердження без повторної перевірки можуть спричиняти нестабільність у вебсценаріях із відкладеним оновленням. Playwright: Assertions, переглянуто 26 вересня 2026 року.

Вибір інструмента не визначає правильну стратегію. Перед написанням тестів уточніть, що саме він може виміряти: один і той самий браузер чи кілька; ізольовані записи чи спільний обліковий запис; контрольований сервіс чи реального зовнішнього постачальника. Документація Playwright, наприклад, описує проєкти як спосіб конфігурувати різні браузери та середовища. Кількість паралельних працівників можна обмежити, коли вони використовували б один спільний ресурс. Playwright: Projects і Parallelism, переглянуто 26 вересня 2026 року.

22.5. Звідки тест знає правильну відповідь

Тестовий оракул — джерело, за яким ми вирішуємо, чи результат правильний. Ним може бути погоджене бізнес-правило, формула, контракт, закон, незалежно обчислений очікуваний результат, попередня затверджена версія чи фізичне спостереження.

Оракул не повинен непомітно копіювати ту саму логіку, яку перевіряє. Якщо функція помилково додає комісію двічі, а тест викликає цю саму функцію для обчислення очікуваної суми, обидві частини можуть помилитися однаково й тест лишиться зеленим. Краще визначити приклад незалежно: базова ціна — 100, комісія — 5, очікувана сума — 105. Для складного алгоритму можна порівняти невеликі вручну обчислені приклади, властивості, еталонні дані, попередню реалізацію або незалежну бібліотеку; джерело кожного очікування треба назвати.

Приклади оракулів:

Вимога: користувач без ролі адміністратора не може змінити іншого власника.
Контракт: сервіс приймає дату у визначеному форматі й повертає один із погоджених статусів.
Інваріант даних: після одного платежу баланс списаний один раз, навіть якщо подія доставлена двічі.
Незалежне обчислення: підсумок чеків розрахований вручну з явними складниками.
Людське спостереження: тестові користувачі можуть без підказки знайти кнопку перенесення й зрозуміти наслідок.

Слово «очевидно» не є оракулом. Якщо продакт-власник, документ і чинна система дають різні правила, тест не повинен вирішувати суперечку замість них. Поверніть питання тому, хто має право затвердити поведінку, і позначте, які роботи залежать від відповіді.

22.6. Дані й середовище — частина плану

Той самий тест може дати різні результати через відмінні записи, часовий пояс, перемикач функції, версію зовнішнього контракту, дозволи або конфігурацію. Тому «пройшов на моїй машині» без опису умов слабкий доказ.

Опишіть потрібні дані

Для кожного важливого сценарію вкажіть стани записів, а не тільки загальне слово «тестові дані»:

запис належить поточному користувачу;
той самий запис належить іншому користувачу;
цільовий ресурс вільний, зайнятий або видалений;
операція ще не запускалась, уже успішна або має невідомий результат;
залежний запис відсутній, застарілий чи архівний;
обсяг звичайний, порожній або граничний.

Не використовуйте реальні приватні дані без дозволу та обґрунтованої потреби. Синтетичні дані повинні зберігати властивість, яку тестуємо. Якщо потрібна локаль успішної оплати, вигаданий клієнт і запис можуть підійти. Якщо перевіряємо продуктивність на розподілі реальних розмірів файлів, зручний штучний файл не замінить репрезентативний набір; потрібна безпечна процедура отримання або генерації даних.

Запишіть, як утворити дані, чи мають вони стабільні ідентифікатори, хто може їх бачити й як їх видалити. Вкажіть, чи тестова база спільна. Два паралельні запуски не мають видалити записи одне одного, якщо саме ця колізія не є предметом тесту.

Опишіть конфігурацію

Для запуску важливі:

версія застосунку, гілка або хеш ревізії;
версія інтерпретатора, браузера та залежностей, якщо вони впливають;
середовище й область мережевого доступу;
перемикачі функцій і ролі тестових користувачів;
версія контракту або заглушки зовнішнього сервісу;
локаль, часовий пояс, годинник і регіональні налаштування;
підготовка схеми даних та послідовність міграцій;
обмеження квот, пропускної здатності чи паралельних сесій;
кроки очищення та відновлення.

Не копіюйте робочі секрети до звіту або набору даних. Для підключення застосовуйте тестові облікові дані з мінімальними правами, якщо постачальник їх дозволяє. Назвіть, які зовнішні системи замінено заглушками: це впливає на те, що саме тест доводить.

Підготовка й очищення

План має сказати, як почати з відомого стану. Це може бути нова ізольована база, транзакція з відкатом, фабрика записів, окрема організація чи одноразове середовище. Вкажіть також, чи є побічна дія поза системою: лист, повідомлення, платіж, webhook (вебхук — виклик URL у відповідь на подію) чи витрата квоти.

Очищення може саме спричинити проблему. Скажімо, тест видаляє бронювання після запуску, хоча інший тест ще перевіряє його. Або повторне очищення видаляє потрібний для аналізу доказ. Визначте власника даних, правила ізоляції та строк зберігання артефактів.

22.7. Регресія: що поза зміною могло зламатися

Регресія — це втрата поведінки, яка раніше працювала, через нову зміну. Не потрібно повторювати всі перевірки продукту після кожного редагування. Треба назвати суміжні ділянки, які мають реальний шлях впливу.

Запитайте:

Чи змінився спільний контракт або спосіб зберігання?
Чи використовують ту саму функцію інші сторінки або клієнти?
Чи є старі версії клієнта, фонові процеси або інтеграції?
Чи торкається зміна прав доступу, фільтрації чи ідентифікації власника?
Чи може міграція вплинути на старий і новий код одночасно?
Чи зачеплена продуктивність на інших пристроях або розмірах даних?
Чи лишились створення, читання, скасування та відновлення чинними?

У плані достатньо назвати перевірку й причину зв’язку. Якщо змінюється схема бронювання, перевірте принаймні старий шлях читання, створення, скасування й міграцію. Якщо змінилася лише мітка кнопки, повна перевірка історичних таблиць може бути недоречною. Якщо зміна глобальна в компіляторі, область регресії може бути значно ширша за два файли.

План регресії не мусить бути повністю автоматизованим. Залиште перелік повторно використовуваних автоматичних перевірок, а окремі ручні перевірки виберіть за ризиком. Зафіксуйте, якщо матриця пристроїв, локалей чи ролей скорочена, і на якій підставі.

22.8. Автоматизація, огляд коду й дослідження користування

Різні види перевірки відповідають на різні запитання:

Автоматичний тест швидко й повторювано перевіряє задану поведінку або інваріант. Він не знаходить вимогу, якої ніхто не сформулював.
Огляд коду шукає суперечності, пропущені гілки, небезпечні припущення, надмірні зміни й помилки в самому тесті. Він не виконує автоматично кожну поведінку.
Ручне дослідження допомагає з’ясувати, чи зрозумілий сценарій, що людина помітить у незвичній ситуації та де припущення продукту не збігаються з її очікуванням. Воно не є повторюваним доказом кожної комбінації.
Перевірка безпеки, доступності або продуктивності застосовує спеціальні методи та експертні критерії, які не варто зводити до звичайної зеленої збірки.

DORA (DevOps Research and Assessment — дослідницька програма DevOps) описує автоматизовані перевірки як практику, що дає швидкий зворотний зв’язок упродовж процесу доставки. При цьому в матеріалах DORA ручні дослідження, перевірка зручності користування й приймальні перевірки також описані як діяльність, що виконується протягом розробки. Висновок не в тому, що треба автоматизувати кожен клік, а в тому, що окрема фінальна фаза забезпечення якості наприкінці може відкласти знання про ризик. DORA: Test automation та Continuous delivery, дата оновлення на сторінках не зазначена; переглянуто 26 вересня 2026 року.

Книга Accelerate: The Science of Lean Software and DevOps Ніколь Форсґрен, Джеза Гамбла й Джина Кіма описує результати дослідження практик, пов’язаних із продуктивністю доставки програмного забезпечення. Тут її використано як дослідницький контекст; конкретні рекомендації про автоматизацію й швидкий зворотний зв’язок прив’язані до актуальних сторінок DORA, а не подані як гарантія для кожної команди. IT Revolution: Accelerate, опубліковано 27 березня 2018 року; сторінку видавця переглянуто 26 вересня 2026 року.

Матеріали Shape Up радять під час формування роботи виявляти «rabbit holes» — технічні невідомі, невирішені дизайнерські питання та заплутані залежності — перш ніж брати на себе повний обсяг. План перевірок допомагає перетворити таку невідомість на невеликий експеримент: наприклад, до реалізації всього потоку перевірити, чи тестовий постачальник гарантує однозначне визначення результату після тайм-ауту. Це спосіб зменшити ризик ставки, а не обіцянка, що експеримент зніме всі ризики. Shape Up, Chapter 5: Risks and Rabbit Holes, сторінка без видимої дати оновлення; переглянуто 26 вересня 2026 року.

Не обіцяйте повне покриття одним типом перевірки

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

Деякі види ручної роботи згодом можна автоматизувати, якщо команда вже розуміє точне правило й тест буде підтримуваним. Інші потребуватимуть регулярного людського спостереження. Розрізняйте автоматичне підтвердження виконання кроків і реальну перевірку зручності: сценарій, де браузер натиснув п’ять кнопок, не доводить, що людина розуміє текст помилки.

22.9. Старт, завершення й чесний статус

План перевірки задає не лише список сценаріїв, а й умови, коли вони можуть дати корисний результат.

Умови старту

Приклади умов, які слід перевірити до запуску:

розгорнуто потрібну ревізію;
тестова база має потрібну схему й завантажені дані;
зовнішню залежність можна досягти або встановлена заглушка;
обліковий запис має визначену роль;
увімкнено потрібний перемикач функції;
браузер чи пристрій входить до обсягу;
артефакти можна зберегти без розкриття секретів;
попередні тести не лишили спільний ресурс у невідомому стані.

Якщо передумова не виконана, результат може бути «заблоковано», а не «пройшло» й не «помилка продукту». Запишіть, яка саме передумова відсутня, хто може її надати та що залишається неперевіреним.

Умови завершення

Визначте конкретний критерій виходу до початку реалізації. Наприклад:

усі визначені як критичні критерії мають принаймні один виконаний доказ;
жоден критичний сценарій не має статусу «не виконано» чи «заблоковано» без явного прийняття ризику;
часткові відмови не призводять до дублювання або прихованої втрати даних;
обов’язкові суміжні регресії пройшли на актуальній ревізії;
відомі нестабільні результати задокументовані, власник аналізу призначений;
вручну перевірені сценарії мають протокол, автора, умови й результат;
тестові дані та зовнішній стан очищені або передані відповідальному.

«Усі тести, які запускали, зелені» — недостатній критерій, якщо частину не запускали або запускали проти іншої ревізії. «Оглядач схвалив» — не замінює поведінкового доказу. Умови можна налаштувати для ризику й випуску, але вони мають бути зрозумілі до моменту рішення.

Розрізняйте статуси

Статус	Що він означає	Що робити далі
Заплановано	Перевірку описано, але її ще не запускали	Не робити висновку про якість коду
Пройшло	Спостереження відповідає визначеному очікуванню на записаній ревізії	Зберегти результат і умови
Не пройшло	Отримане спостереження суперечить очікуванню	З’ясувати, це дефект, помилка тесту, середовища чи критерію
Нестабільне (flaky)	Повторні запуски дають різні результати без зміни, що це пояснює	Зберегти невдалий і успішний запуски; шукати причину
Заблоковано	Запуск неможливий через відсутню передумову, доступ чи залежність	Назвати блокер, наслідок і власника
Не запускали	Перевірку не виконали	Не трактувати як успішну; зафіксувати причину та залишковий ризик
Не застосовується	Сценарій не стосується цієї зміни	Записати обґрунтування, щоб його можна було переглянути

Нестабільний тест не стає повністю пройденим від того, що повторний запуск дав зелену відповідь. У документації Playwright невдалий тест, який проходить під час повтору, класифікується окремо як flaky; типовою поведінкою за замовчуванням є відсутність повторів. Повтор може бути інструментом діагностики, але не стирає перший збій і не встановлює причину. Playwright: Test retries, переглянуто 26 вересня 2026 року.

Зберігайте зв’язок доказу з ревізією. Для автоматичного запуску це може бути посилання на конкретний запуск CI (continuous integration — безперервної інтеграції), commit (зафіксована зміна), звіт і конфігурацію. Для ручного спостереження — дата, тестове середовище, кроки, результат, а для візуального випадку — скриншот або короткий запис екрана без секретів. Якщо після цього код змінився, визначте, які перевірки слід повторити.

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

22.10. Роль кодового агента та доступ до середовища

Кодовий агент може допомогти перетворити вимоги на матрицю покриття, знайти суперечності, запропонувати негативні й граничні сценарії, підготувати тестові дані, додати автоматичні перевірки та виконати доступні команди. Відповідальна людина все одно має затвердити продуктові правила, оцінити пропущені ризики й перевірити достовірність доказу.

Перед тестовим запуском агент має встановити:

які команди й зовнішні сервіси справді доступні;
чи є середовище ізольованим і які дані та секрети воно бачить;
чи дозволений мережевий доступ до тестового постачальника;
чи має агент право виконати саме цю команду;
чи можна зберегти журнали або знімки без витоку приватної інформації.

Офіційна документація OpenAI описує окремо агентський рушій і середовище, або ізольовану тестову пісочницю (sandbox), де виконуються команди; для розміщених середовищ можна налаштувати мережу як дозволену, вимкнену або обмежену списком вузлів. Це означає, що назва продукту сама по собі не доводить наявність доступу до конкретної бази чи пісочниці зовнішнього постачальника. Потрібно звірити фактичні налаштування сеансу. OpenAI Developers: OpenAI-hosted sandboxes і Sandbox security, переглянуто 26 вересня 2026 року.

Anthropic описує для Claude Code окремі межі ізоляції файлової системи й мережі, які можуть обмежувати доступ команд до директорій і зовнішніх вузлів. Наявність або режим таких обмежень залежить від конфігурації та середовища; план має підтвердити, що потрібний тестовий ресурс реально доступний, а не припускати це за назвою агента. Anthropic: Making Claude Code more secure and autonomous with sandboxing, опубліковано 20 жовтня 2025 року; переглянуто 26 вересня 2026 року.

Агент не має права:

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

Коли виконати перевірку неможливо, агент має повернути точну умову блокування та запропонувати безпечні альтернативи: тест контракту, локальну заглушку, ручний сценарій для власника доступу, короткий експеримент або документоване прийняття ризику. Кожен варіант доводить різні властивості; обмеження слід зберегти поруч із доказом.

22.11. Повний приклад 1: перенесення бронювання

Цей приклад продовжує бронювання з глав 19 і 21. Припустімо, власник продукту затвердив такі правила для навчального сценарію:

Клієнт може перенести тільки своє майбутнє активне бронювання.
Клієнт обирає доступний слот тієї самої послуги.
Старий слот залишається закріпленим за клієнтом, доки новий не підтверджений.
Якщо перенесення не вдалося, старий запис не зникає й клієнту показують, що сталося.
Один слот не може бути зайнятий двома активними бронюваннями.
Після успішного перенесення надсилається рівно одне підтвердження з новим часом.
Підтвердження показує час у збереженому часовому поясі клієнта; для тесту B-08 профіль має зону America/New_York.

Це припущення має бути затверджене до тестового плану. Якби бізнес хотів звільняти старий слот раніше, це інша поведінка й інший ризик.

Спочатку зафіксуймо критерії

ID	Критерій
C-1	Клієнт бачить і може перенести власне майбутнє активне бронювання на доступний слот тієї самої послуги.
C-2	Клієнт не може прочитати або змінити бронювання іншого клієнта; неактивний запис перенести не можна.
C-3	Якщо обраний слот зайнято або він перестав бути доступним до підтвердження, перенесення відхиляється, а первинний час зберігається.
C-4	Повтор тієї самої операції не створює дубльованого перенесення чи повторного підтвердження.
C-5	При невідомому результаті зовнішнього календаря система не повідомляє про успіх, доки стан не звірений.
C-6	Після успіху підтвердження містить новий час у збереженому часовому поясі клієнта (`America/New_York` у тесті B-08).

Критерії C-1—C-6 визначають спостережувані правила. Вони не встановлюють, чи реалізація використовує блокування, ідемпотентний ключ, чергу чи інший механізм. Технічне рішення можна обрати під час планування, але оракул тесту лишається тим самим.

Тепер план тестів

Тест	Сценарій і дані	Рівень	Очікування	Доказ
B-01	Власник бронювання A обирає вільний слот тієї самої послуги.	Взаємодія, потім наскрізний шлях	A має новий слот, старий звільнився після підтвердження; інші записи незмінні; надіслано одне підтвердження.	Автоматичний звіт; стан обох бронювань до/після; подія сповіщення; ревізія.
B-02	Клієнт X намагається відкрити й перенести бронювання Y.	Правила доступу та інтеграція API	Доступ заборонено; відповідь не розкриває час або дані Y; запис Y незмінний.	Тест ролей і журнал без приватного вмісту.
B-03	Бронювання завершене або скасоване; також перевіряється перенесення минулого часу.	Перевірка правила	Сервер відмовляє; стан не змінюється; не надходить сигнал успіху.	Результати для кожного статусу, початковий та кінцевий стан.
B-04	Два клієнти одночасно намагаються зайняти єдиний вільний слот.	Конкурентна перевірка з контрольованим стартом запитів	Рівно одне активне бронювання володіє слотом; друга дія отримує зрозумілу відмову; обидва старі записи не втрачені.	Лічильник активних власників, відповіді обох запитів, журнали транзакцій із тестовими ідентифікаторами.
B-05	Слот стає зайнятим між показом списку та підтвердженням.	Взаємодія, конкурентна зміна	Сервер повторно перевіряє доступність; клієнт бачить відмову; старий час лишається чинним.	Послідовність подій і стан записів у момент підтвердження.
B-06	Календар прийняв новий слот, але відповідь загубилася до локального підтвердження.	Інтеграційна перевірка з керованою заглушкою	Користувач не бачить неправдивого успіху; повтор не створює другий зовнішній запис; стан позначений для звірки, доки результат не встановлений.	Трасування запиту із тестовим ключем, стан зовнішньої заглушки й локального запису.
B-07	Запит успішний, але сервіс сповіщень не відповідає.	Часткова відмова	Результат бронювання не втрачається; сповіщення не дублюється при повторній доставці; відмова видима оператору.	Стан бронювання, черги сповіщень та журналу помилок.
B-08	Серверне значення `2026-01-15T00:30:00Z`; профіль клієнта налаштовано на `America/New_York`.	Локальна перевірка формату й ручне спостереження	Підтвердження показує `14 січня 2026, 19:30` у зоні `America/New_York`: це той самий момент UTC, а локальна календарна дата попередня.	Початковий timestamp, налаштування профілю, зафіксоване значення в інтерфейсі, зона браузера й результат автоматичного форматування.
B-09	Регресія: переглянути, створити та скасувати бронювання без перенесення.	Взаємодія й короткий ручний прохід	Незмінені сценарії зберігають погоджену поведінку.	Результати попереднього автоматичного набору й ручний протокол лише для зміненого суміжного екрану.

У таблиці C-1 і C-2 мають власні успішні й негативні випадки. C-3 пов’язаний і з граничним станом, і з конкуренцією за слот. C-4 і C-5 потребують сценарію повтору після втраченої відповіді; тест одиничного вдалого запиту їх не доводить. C-6 потребує чітко визначеного часового поясу та незалежного очікуваного значення.

Розберімо B-06 крок за кроком

Початковий стан: у тестового клієнта є активне бронювання A о 10:00; слот 11:00 вільний; заглушка календаря знає стан A. Власник бронювання ідентифікується тестовим користувачем, а не ім’ям реальної людини.

Клієнт надсилає запит перенесення з ідентифікатором операції R.
Заглушка приймає слот 11:00 і записує його зовнішній ідентифікатор.
Заглушка імітує втрату мережі до відповіді застосунку.
Клієнт бачить повідомлення «результат перевіряється» або інший погоджений стан невизначеності. Він не бачить «перенесення успішне», якщо система не має достатнього доказу.
Система звіряє стан за ідентифікатором R або узгодженим зовнішнім ключем.
Після звірки в системі рівно один актуальний слот; старий час не відновлюється помилково; підтвердження містить 11:00.
Той самий R надсилається повторно. Кількість зовнішніх записів і підтверджень не збільшується.

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

Регресія та середовище

Потрібні синтетичні користувачі X та Y, один керівник календаря, два майбутні слоти, один зайнятий слот, скасоване та минуле бронювання. Для конкурентного сценарію потрібна можливість синхронно запустити два запити, а не просто два кліки з інтервалом. Для B-06 — заглушка, яка може втратити відповідь після фіксації зовнішньої дії. Для B-08 — середовище з контрольованим часовим поясом. Перед тестами слід очистити записи й перевірити, що немає попередньої події із тим самим ключем.

Перед запуском визначте ще одне продуктове питання: що показувати, якщо результат календаря лишився невідомим після повторної звірки? Наприклад, чи може клієнт спробувати знову, чи він має чекати, чи оператор вручну звіряє дію? План може включити статус pending_review лише якщо це ім’я й поведінку погоджено; інакше запишіть відкрите рішення без вигаданого контракту.

Завершення перевірки: критичні B-02, B-04, B-05 і B-06 мають фактичні докази; дані не мають двох активних власників слота; повідомлення про успіх з’являється тільки після підтвердженого стану; B-07 не створює дубля сповіщення. Якщо календарний sandbox недоступний, це не зупиняє локальні й заглушкові перевірки, але інтеграційний ризик B-06 позначається окремо і не називається закритим.

22.12. Повний приклад 2: повторний імпорт після мережевого збою

Імпорт отримує подію від зовнішнього партнера, створює або оновлює один запис рахунку та зберігає факт обробки. Партнер може доставити ту саму подію повторно. Мережа може обірватися після локального commit, тобто після фіксації запису, але до відповіді партнеру.

Для прикладу власник інтеграції затвердив правила:

однаковий зовнішній ідентифікатор події має один бізнес-ефект;
повтор тієї самої події не додає другу копію рахунку і не повторює побічне сповіщення;
якщо стан після збою невідомий, система звіряє результат перед повторним створенням;
інша подія для того самого рахунку може оновити суму лише за погодженим правилом версій;
помилка перевірки даних не змінює чинний коректний запис.

Ці правила розрізняють повторну доставку однієї події й нове оновлення. Якщо продукт не визначив цю різницю, потрібне рішення до коду.

Критерій, тест, доказ

ID	Критерій	Тест	Очікування	Доказ
I-1	Одна подія створює один рахунок	Імпортувати подію E один раз із початковою порожньою базою	Один запис із зовнішнім ідентифікатором E та очікуваною сумою	Звіт тесту, кількість записів, точна сума
I-2	Повтор не повторює бізнес-ефект	Повторити E послідовно й паралельно	Один рахунок; одна побічна дія; повтор має зрозумілий результат	Історія доставок і кількість записів/сповіщень
I-3	Загублена відповідь після фіксації не породжує дублі	Заставити імпорт зафіксувати запис, потім зірвати відповідь	Наступна доставка E знаходить попередній результат і не створює другий запис	Стан перед/після, ключ E, журнал звірки
I-4	Некоректна сума відхиляється без зміни чинного рахунку	Подія E2 містить суму поза допустимим діапазоном	Відмова видима; попередній рахунок і журнал подій узгоджені	Результат валідації та незмінений контрольний запис
I-5	Новіша погоджена версія оновлює, стара не відкочує	Спершу доставити версію 5, потім із затримкою версію 4	Сума лишається з версії 5; застаріла подія не перезаписує її	Номер версії та стан після кожної доставки
I-6	Часткова відмова помітна й відновлювана	Зупинити базу або чергу в різних точках обробки	Подія або безпечно не приймається, або лишається для повтору; ні тиха втрата, ні подвійний рахунок не допускаються	Журнал черги, лічильники повторів, контрольний звіт записів

Що доводить тест одиничного успіху — і чого не доводить

Один успішний запуск I-1 доводить лише те, що нормальна доставка може створити запис. Він не перевіряє повтор, дубль, паралельність, загублену відповідь, відновлення після падіння черги чи застарілу версію. Це окремі ризики і різні початкові стани.

Щоб перевірити I-3, тестовий транспорт має створити точно визначений збій: базовий запис і ключ події вже зафіксовані, але партнер не отримав відповідь. Потім той самий ключ E надходить знову. Оракул — число бізнес-записів, стан рахунку та число сповіщень, а не тільки повідомлення про те, що функція повернула true.

Для I-2 одночасні доставки мають стартувати до завершення першої. Інакше це два послідовні повтори, а не конкурентний тест. Якщо платформа не може керовано синхронізувати запити, позначте обмеження, додайте інше підтвердження унікальності на нижчому рівні та не заявляйте, що реальна гонка перевірена.

Для I-5 згенеруйте два повідомлення з одним зовнішнім ідентифікатором, але різними номерами версії та сумами, наприклад 4 → 100, 5 → 125. Спершу застосуйте версію 5, а потім затриману версію 4. Очікування — 125. Числа тут умовні; оракулом є правило «новіша прийнята версія не може бути затерта старою», затверджене для прикладу.

Дані, середовище й очищення

Створіть синтетичного партнера, рахунок з одним зовнішнім ключем, дублі події з тим самим ключем, інший ключ для некоректної суми та дві версії однієї події. Ключі мають бути ізольовані між тестовими запусками й не потрапляти до робочого середовища. Зовнішні повідомлення й сповіщення надсилаються тільки у заглушку. Очистіть тестові рахунки, події та чергу після запису звіту; зберігайте мінімальний журнал, необхідний для діагнозу.

Схема бази, черга та зовнішня заглушка мають відповідати погодженій версії контракту. Запишіть, чи відповідає тестова модель часу очікування реальному партнеру. Якщо невідома верхня межа повторної доставки, не підбирайте довільну кількість спроб і не називайте обмежений тест повним доказом.

Умови завершення: один бізнес-ефект на E; жоден повтор не збільшує число рахунків чи сповіщень; стан після часткового збою можна однозначно відновити або чесно показати як невідомий; стара версія не перезаписує нову; обов’язкова взаємодія з партнером або окремо перевірена, або позначена як неперевірена.

22.13. Якщо потрібний sandbox недоступний

Припустімо, постачальник дозволяє перевіряти API лише через власний sandbox, але обліковий запис агента чи команди ще не має доступу. Перевірка поведінки із заглушкою доступна; перевірка справжнього прийняття події партнером — ні.

Чесний запис статусу:

Перевірка	Статус	Що відомо	Чого цей результат не доводить	Наступний крок
Формат і валідація контракту	Пройшло локально на погоджених прикладах	Внутрішня сторона формує очікуваний запит	Прийняття запиту реальним партнером	Зберегти commit і версію прикладів
Повтор доставки із заглушкою	Пройшло; дубля локально не створено	Застосунок поводиться правильно на заданій моделі відповіді	Справжній порядок повторів і часові межі постачальника	Звірити документований контракт
Виклик sandbox постачальника	Заблоковано: доступу немає	Обліковий запис і перевірена причина блокування записані	Реальне створення, тайм-аут, повтор чи помилка авторизації	Власник інтеграції отримує доступ або погоджує тест
Ручне відновлення	Не запускали	Розроблено протокол кроків	Що оператор реально виконає його без помилки	Запланувати спостереження оператора

План фіксує, хто запросить доступ, кого саме це блокує, який критерій лишається неперевіреним і яке рішення потрібне для продовження. Альтернативи можуть зменшити ризик:

перевірити формат контракту локально з незалежними прикладами;
отримати підписаний або документований sandbox-контракт постачальника;
моделювати специфічні відповіді заглушкою й протестувати локальне відновлення;
запросити уповноваженого власника доступу провести операцію в sandbox та надати безпечний доказ;
зробити обмежений ручний пілот після того, як буде визначене відновлення й нагляд.

Ці варіанти закривають різні частини ризику. Локальна заглушка не доводить справжню інтеграцію. Підтримка власника не доводить усі варіанти помилок. Ручний пілот не автоматизує повторювану перевірку. Обмеження має залишатися видимим у тестовому звіті та рішенні про запуск.

«Не запускали» — це не «успішно». «Заблоковано» — це не помилка продукту. Якщо тест залежить від доступу, якого немає, не записуйте вигадану відповідь, не просіть агента обійти ізоляцію й не знижуйте критерій мовчки. Попросіть правомочного власника середовища надати мінімально необхідний доступ або вирішити, чи приймається залишковий ризик.

22.14. Реальний pull request: тест-план і пропущена перевірка

У публічному репозиторії OpenIPC pull request (PR — запит на злиття) №2260 змінює прапорець оптимізації для двох цілей GK7102. Автор описав план двома пунктами: перебудувати userspace (простір користувача) і перевірити, що обгортка toolchain (ланцюжка інструментів) передає параметр; потім перевірити стабільність SSH (Secure Shell — захищений протокол віддаленого доступу) і WPA2 (Wi-Fi Protected Access 2 — протокол захисту Wi-Fi) на GK7102 із перебудованим SDK (Software Development Kit — комплект засобів розробки) toolchain. Обидва пункти в описі лишились непозначеними. OpenIPC/firmware #2260, створено 11 серпня 2026 року; переглянуто 10 жовтня 2026 року.

Цей план корисний тим, що називає реальні цілі й ручну перевірку на апаратному пристрої. Проте він не називає перевірку збереження попереднього рівня оптимізації. Оглядовий бот у тому самому pull request звернув увагу: значення параметра замінювало рядок оптимізації тільки на -mno-unaligned-access, що потенційно прибирало очікуваний -O* режим і могло вплинути на розмір та швидкість інших пакетів. Це інший ризик, ніж «чи компілятор передав прапорець» і «чи працює Wi-Fi».

Перевірка GitHub API 10 жовтня 2026 року показала для head-коміту цього pull request нуль check runs і порожній список commit statuses із загальним станом pending; отже, доступного зеленого результату перебудови немає. У pull request були запитані огляди від власників коду, а його закрили 16 серпня після коментаря «Closing this since no reply». Сторінка перевірок #2260. PR закритий і не злитий; це не доводить, що код потрапив у продукт або що припущення бота було остаточно підтверджене. Це показовий приклад різниці між запланованими спостереженнями, реально виконаними перевірками й незалежно знайденою прогалиною.

Як покращити план до коду:

додати перевірку, що системні параметри оптимізації зберегли потрібні значення;
вказати команди або точні артефакти збірки для відтворення;
не ставити прапорець виконання, доки немає журналу чи ідентифікатора результату;
назвати плату, прошивку, драйвер, спосіб підключення та тривалість перевірки Wi-Fi;
після відгуку оглядача доповнити план і перевірити актуальну ревізію ще раз;
записати, які цілі збірки не запускались і чому.

Огляд коду допоміг помітити ризик, який не був у плані. Він не замінив компіляцію, перевірку розміру/швидкодії чи роботу пристрою. І навпаки: навіть зелена збірка не довела б, що користувач може надійно працювати з мережею на апаратній платі. Кожен вид доказу має свою межу.

22.15. Коротка форма плану, яку можна використати перед PR

Цей шаблон призначений для робочого плану. Видаліть непотрібні поля, але залиште незакриті ризики видимими.

## Обіцянка зміни
Для кого й що стане можливим? Яка межа роботи?

## Критерії приймання
| ID | Очікувана поведінка | Джерело/власник правила |
| --- | --- | --- |

## Обсяг і ризики
- Змінюється:
- Суміжні сценарії:
- Високий наслідок або ймовірність:
- Поза обсягом:
- Відкрите питання й власник рішення:

## Перевірки
| ID | Критерій/ризик | Початковий стан і дія | Рівень | Очікування | Дані/середовище | Доказ |
| --- | --- | --- | --- | --- | --- | --- |

## Сценарії, які розглянуто
- Звичний:
- Негативний:
- Граничний:
- Повтор:
- Конкурентна дія:
- Тайм-аут або часткова відмова:
- Регресія:
- Ручне дослідження:

## Умови
- Перед запуском:
- Умова завершення:
- Відповідальний:
- Очищення й відновлення:

## Не перевірено
| Перевірка | Чому | Ризик | Наступна дія/власник |
| --- | --- | --- | --- |

## Фактичні результати
| Перевірка | Статус | Ревізія й середовище | Посилання на доказ | Примітка |
| --- | --- | --- | --- | --- |

Порожній розділ «Фактичні результати» перед запуском — це чесний стан. Після запуску додайте точні результати. Не змішуйте їх із очікуваннями плану.

Швидка перевірка якості плану

Перед передаванням у реалізацію дайте відповіді:

Чи можна для кожного критерію вказати конкретну перевірку або видиму прогалину?
Чи має кожен тест однозначний оракул?
Чи охоплені відповідні негативний, граничний, повторний, конкурентний та частковий сценарії?
Чи названо стан даних, середовище, конфігурацію та зовнішні залежності?
Чи включена регресія для реальних суміжних шляхів?
Чи розрізняються автоматична перевірка, огляд коду й ручне дослідження?
Чи відомі умови старту, завершення й очищення?
Чи всі статуси не виконаних тестів видимі, а залишкові ризики мають власника?
Чи зможе інша людина повторити тест і перевірити його доказ?
Чи не переписав агент критерій, щоб код пройшов?

Якщо відповідь «ні», це не завжди означає зупинити всю роботу. Для очевидної дрібної зміни може вистачити короткого уточнення. Для платежу, авторизації, міграції, бронювання, імпорту чи іншої операції з частковими наслідками невідомість може бути підставою спершу зробити невеликий експеримент або повернутися до власника правила.

22.16. Підсумок

План перевірок перекладає критерії та ризики у спостережувані сценарії до того, як деталі реалізації почнуть підміняти продуктову поведінку. Критерій каже, що має бути правдою; тест — як ми це спостерігаємо; доказ — що фактично побачили на конкретній ревізії, у конкретних даних і середовищі.

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

Зафіксуйте початковий стан і спосіб очищення; безпечні тестові дані; середовище й залежності; умови старту й завершення; власника рішення; статус кожної перевірки. Нестабільний, заблокований або не запущений тест лишається видимим. Зелений повтор не стирає попередній збій. Заглушка не доводить доступність реального постачальника. Перегляд не є виконанням, а список сценаріїв, написаний агентом, не є результатом запуску.

DORA допомагає думати про швидкий зворотний зв’язок упродовж доставки; Shape Up — про зняття небезпечних невідомих до великої ставки. Кодовий агент може запропонувати покриття й виконати доступні перевірки, але критерій, безпечні межі й прийняття залишкового ризику мають залишатися явними рішеннями людей.

Джерела

DORA, Test automation, дата оновлення на сторінці не зазначена; переглянуто 26 вересня 2026 року. Підхід до швидкого та надійного автоматизованого зворотного зв’язку й згадка ручного дослідження, usability та приймальних перевірок.
DORA, Continuous delivery, дата оновлення на сторінці не зазначена; переглянуто 26 вересня 2026 року. Швидкий зворотний зв’язок, автоматизація тестування, безперервна перевірка протягом циклу доставки.
IT Revolution, Ніколь Форсґрен, Джез Гамбл і Джин Кім, Accelerate: The Science of Lean Software and DevOps, видано 27 березня 2018 року. Сторінка видавця ідентифікує книгу й дослідницький контекст; прикладні рекомендації в тексті підтверджено актуальними сторінками DORA.
Basecamp, Ryan Singer, Shape Up, Chapter 5: Risks and Rabbit Holes, дата оновлення на сторінці не зазначена; переглянуто 26 вересня 2026 року. Пошук технічних невідомих, невирішеного дизайну та заплутаних залежностей до початку повної ставки.
Playwright, Assertions, документація перевірена 23 вересня 2026 року. Твердження, що повторно зчитують вебелементи, та пояснення ризику для нестабільних асинхронних сторінок.
Playwright, Retries, документація перевірена 23 вересня 2026 року. Повторні запуски, класифікація passed/flaky/failed і значення першого результату.
Playwright, Projects та Parallelism, документацію перевірено 26 вересня 2026 року. Конфігурація браузерів і середовищ; обмеження паралельності, коли тести використовують спільний ресурс.
OpenAI Developers, OpenAI-hosted sandboxes і Sandbox security, документацію перевірено 26 вересня 2026 року. Налаштування виконувального середовища й мережевих меж для агентів. Це опис можливостей продукту, а не підтвердження доступу конкретного користувача до конкретного сервісу.
Anthropic, Making Claude Code more secure and autonomous with sandboxing, опубліковано 20 жовтня 2025 року; переглянуто 26 вересня 2026 року. Опис файлової та мережевої ізоляції Claude Code. Це джерело про межі середовища, а не гарантія правильності згенерованої перевірки.
OpenIPC, Pull request #2260: gk7102 optimization flag та його сторінка перевірок, створено 11 серпня 2026 року й закрито без злиття 16 серпня 2026 року; переглянуто 10 жовтня 2026 року. Реальний план перебудови та ручної перевірки мережі, непозначені пункти, оглядовий коментар про збереження оптимізації, відсутність check runs і commit statuses із загальним станом pending. Не використовується як доказ випуску або підтвердженої виробничої помилки.

Межі висновків. Рекомендації DORA узагальнюють її дослідницьку програму й не гарантують результат окремого тесту. Shape Up описує власний метод формування ставки, а не стандарт якості. Документація Playwright, OpenAI й Anthropic підтверджує лише описані властивості їхніх інструментів та середовищ; її треба звіряти з фактичною конфігурацією проєкту. Відкритий приклад бронювання та всі його результати вигадані. Аналіз pull request OpenIPC обмежений його описом, видимими оглядовими повідомленнями й сторінкою перевірок станом на дату перегляду.