Web та API Testing: питання для співбесіди

Відповідь

Перевіряйте призначену семантику операції, її безпечність (safety) та ідемпотентність, а не лише назву методу. Повторні PUT- або DELETE-запити повинні мати передбачувані наслідки, тоді як POST зазвичай створює ресурс або запускає роботу і може бути неідемпотентним без явного ключа ідемпотентності.

Сильна відповідь включає

• безпечність та ідемпотентність
• поведінка при повторних запитах
• тестує спостережувані побічні ефекти

Практичний приклад

Тестуючи платіжне API, тестувальник двічі надсилає той самий запит POST /payments без ключа ідемпотентності і підтверджує, що з клієнта списують кошти двічі — це реальний баг. Після того як команда додає обов'язковий заголовок Idempotency-Key, тестувальник повторює перевірку, надсилаючи ідентичний запит двічі з тим самим ключем, і підтверджує, що списання відбувається лише одне, тоді як оновлення PUT /orders/123/address, за перевіркою, завжди дає той самий кінцевий результат, скільки б разів його не повторювали.

Відповідь

Перевірте схему та правила полів, автентифікацію й авторизацію, дублікати та конкурентні запити, коди відповідей і заголовки, збереження даних, вплив на суміжні системи, ліміти запитів (rate limits), обробку чутливих даних та спостережуваність (observability).

Сильна відповідь включає

• не лише перевірка коду статусу
• безпека та конкурентність
• перевірка бази даних та суміжних систем

Практичний приклад

Для POST /users тестувальник перевіряє, що дублікат email повертає 409, а не створює другий акаунт, надсилає два ідентичні запити реєстрації одночасно, щоб переконатися, що жодна умова гонки (race condition) не створює дублікатів записів, перевіряє, що пароль ніколи не з'являється в тілі відповіді чи в логах, підтверджує, що створений користувач справді з'являється в базі даних з коректно захешованим паролем, і перевіряє, що вітальний лист коректно тригериться далі по системі.

Відповідь

Автентифікація підтверджує особу; авторизація вирішує, до чого ця особа має доступ. Тестуйте відсутні, прострочені та некоректні облікові дані окремо від випадків, коли валідний користувач намагається виконати заборонену дію, включно з доступом до чужих даних на рівні об'єкта. Відсутній чи недійсний обліковий запис має викликати виклик 401 згідно з контрактом API; валідна, автентифікована особа, що намагається виконати заборонену дію, все одно має отримати відмову — зазвичай через 403 Forbidden, або через 404 Not Found, коли API навмисно приховує саме існування ресурсу для цієї особи, що прямо дозволяє RFC 9110. Інваріант безпеки, який слід тестувати, — це відмова без недоречного витоку інформації, а не один універсально обов'язковий код статусу.

Сильна відповідь включає

• особа проти прав доступу
• негативні сценарії
• інваріант — відмова без витоку інформації; і 403, і приховувальний 404 задовольняють це, не один обов'язковий код

Практичний приклад

У банківському API запит без токена або з простроченим токеном має повертати 401 Unauthorized — це помилка автентифікації. Запит від авторизованого звичайного користувача, який намагається виконати GET /accounts/9999/statement, де рахунок 9999 належить іншому клієнту, має повертати 403 Forbidden — це помилка авторизації, а саме проблема зламаного контролю доступу на рівні об'єкта (BOLA), якщо API натомість повертає ці дані.

Відповідь

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

Сильна відповідь включає

• розуміє, де зберігається стан
• закінчення терміну дії та інвалідація
• ізоляція між користувачами

Практичний приклад

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

Відповідь

Контрактні тести раніше й дешевше за повноцінні середовища виявляють несумісні очікування між споживачем сервісу та постачальником. Вони не замінюють тестування бізнес-логіки постачальника, реалістичні наскрізні (end-to-end) сценарії, перевірки продуктивності чи спостережуваність у продакшені.

Сильна відповідь включає

• сумісність споживача та постачальника
• швидкий зворотний зв'язок
• чіткі межі контрактних тестів

Практичний приклад

Команда фронтенду споживає API /orders і пише Pact-контракт, що очікує поле totalAmount як число. Коли команда бекенду пізніше під час рефакторингу змінює його на форматований рядок на кшталт '$45.00', контрактний тест падає в їхньому CI-пайплайні ще до того, як зміна потрапляє в спільне staging-середовище. Команда все одно прогонить повні наскрізні тести перед релізом, бо самого контрактного тесту було б недостатньо, якби сума рахувалася неправильно, але мала коректний тип.

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

Тестуючи ендпоінт POST /orders, тестувальник варіює заголовок Content-Type між JSON і непідтримуваним form-encoded значенням, надсилає валідне й надто велике тіло запиту, а також підміняє токен авторизації на токен іншого користувача. Окрім перевірки схеми відповіді 200, він перевіряє, що замовлення справді з'явилося в базі даних, спрацював лист-підтвердження, і — що критично — що підміна токена повертає 403, а не показує замовлення іншого користувача, підтверджуючи, що авторизація забезпечується саме на сервері.

Відповідь

1xx — informational, 2xx — success, 3xx — redirect/cache, 4xx — проблема request/client side, 5xx — server або upstream failure. QA має знати не лише групи, а й конкретні коди: 200, 201, 202, 204, 301/302/307/308, 304, 400, 401, 403, 404, 405, 409, 412, 413, 415, 422, 429, 500, 501, 502, 503 і 504 найчастіше потрібні в API testing.

Сильна відповідь включає

• усі п'ять класів status codes
• конкретні коди, а не лише 2xx/4xx
• відрізняє client, server та gateway failures

Практичний приклад

POST повертає 202 замість 201. Tester не заводить bug автоматично: 202 може бути правильним для асинхронної обробки, тоді як 201 означав би, що створення resource вже завершено.

Відповідь

200 означає успішний request і часто повертає representation або результат operation. 201 означає, що resource створено. 202 — request прийнято, але processing ще не завершено, що типово для async jobs. 204 означає успіх без response content. Правильний code визначається contract та semantics endpoint, а не правилом «будь-який success = 200».

Сильна відповідь включає

• 201 означає created
• 202 — async/non-final acceptance
• 204 навмисно без response content

Практичний приклад

DELETE resource повертає 204 з empty body, а створення resource — 201 з Location header. Обидві відповіді успішні, але повідомляють різний результат operation.

Відповідь

400 — generic malformed/invalid request; 401 зазвичай означає missing/invalid authentication; 403 — caller не має permission; 404 — resource не знайдено; 409 — conflict з current state; 415 — unsupported request media type; 422 — syntax зрозумілий, але content семантично неможливо обробити; 429 — перевищено rate limit. QA має перевіряти точну відповідність failure до API contract.

Сильна відповідь включає

• 401 authentication проти 403 authorization
• 409 conflict проти 422 semantic validation
• 415 media type та 429 rate limiting

Практичний приклад

Request з expired token зазвичай має дати 401, а той самий endpoint з valid token користувача без admin role — 403. Це різні failure modes, а не одна authentication error.

Відповідь

500 — generic failure сервера, що відповідає. 502 означає, що gateway/proxy отримав invalid response від upstream. 503 — service тимчасово unavailable, наприклад через overload/maintenance, і може мати Retry-After. 504 — gateway/proxy не дочекався upstream. Ця різниця допомагає локалізувати application failure, availability problem або dependency path.

Сильна відповідь включає

• 500 local/general server failure
• 502 invalid upstream response
• 503 unavailable проти 504 upstream timeout

Практичний приклад

Public API повертає 504 рівно через 30 секунд, а downstream report service має повільні requests. Це схоже на gateway timeout dependency path, а не просто на generic backend bug.

Відповідь

У request дивіться Accept, Content-Type, Authorization, Cookie, Origin, Host, conditional headers If-Match/If-None-Match, Range та tracing/correlation headers. У response — Content-Type, Location, Set-Cookie, Cache-Control, ETag, Vary, Allow, WWW-Authenticate, Retry-After, Content-Disposition та CORS headers. Headers змінюють semantics і часто пояснюють failure, якого не видно лише з JSON body.

Сильна відповідь включає

• request Content-Type/Accept/authentication headers
• response Location/cookies/cache/auth challenge
• conditional, tracing та CORS headers

Практичний приклад

API повертає 415, хоча JSON виглядає valid. У request видно Content-Type: text/plain замість application/json, тому проблема в request construction, а не у значеннях JSON fields.

Відповідь

Типові механізми: HTTP Basic через TLS, Bearer tokens (opaque або JWT), API keys, OAuth 2.0 access tokens, session cookies, HMAC/request signing та mutual TLS. OpenID Connect часто дає identity/login поверх OAuth 2.0, а access token використовується для API authorization. Authentication визначає, хто caller, authorization — що йому дозволено. Треба тестувати expired/revoked credentials, wrong scope/audience та valid identity без потрібного permission.

Сильна відповідь включає

• Basic, Bearer/JWT, API key та OAuth
• session/signature/mTLS alternatives
• authentication проти authorization

Практичний приклад

Valid JWT дозволяє normal user читати власний profile, але admin endpoint повертає 403. Authentication пройшла, а failure знаходиться на authorization boundary, не в token validity.

Відповідь

Endpoint може приймати raw binary body з конкретним media type або application/octet-stream. Коли разом із file треба передати text fields чи metadata, типовий варіант — multipart/form-data: кожен part має власні Content-Disposition та за потреби Content-Type, тому один part може бути file, інший — text або JSON metadata. Base64 у JSON можливий, але збільшує payload/processing. Інша схема — pre-signed storage URL і окреме збереження metadata.

Сильна відповідь включає

• raw binary проти multipart/form-data
• file та metadata можуть бути окремими multipart parts
• trade-offs base64 та pre-signed upload

Практичний приклад

Profile endpoint приймає displayName та avatar одним multipart request. Tester перевіряє text part, filename, image Content-Type, zero-byte/oversized files і що інший user не може потім download цей object.

Відповідь

GET читає representation; HEAD має GET semantics без response content; POST виконує resource-specific processing; PUT створює/замінює target state; PATCH робить partial modification; DELETE видаляє target; OPTIONS описує communication options і використовується для CORS preflight; CONNECT створює tunnel; TRACE — diagnostic loop-back. GET, HEAD, OPTIONS, TRACE — safe. GET, HEAD, PUT, DELETE, OPTIONS, TRACE — idempotent. POST не idempotent за визначенням, PATCH не гарантує idempotency.

Сильна відповідь включає

• покриває GET/HEAD/POST/PUT/PATCH/DELETE/OPTIONS
• відрізняє safe та idempotent
• PUT проти PATCH semantics

Практичний приклад

Повторний PUT /users/42 з тією самою complete representation має залишити resource у тому самому intended state, тоді як повторний POST /orders може створити ще одне замовлення без окремого idempotency mechanism.

Відповідь

CORS — browser-enforced механізм на HTTP headers, який дозволяє server послабити same-origin policy для дозволених origins. Origin — це scheme + host + port. Коли browser JavaScript звертається до іншого origin, browser може спочатку відправити OPTIONS preflight з Origin, Access-Control-Request-Method і Access-Control-Request-Headers. Server має повернути відповідні Access-Control-Allow-* headers. Request може працювати в curl/Postman і падати в browser, бо ці clients не enforce same-origin policy. CORS не замінює authentication/authorization.

Сильна відповідь включає

• same-origin policy та scheme/host/port origin
• OPTIONS preflight та Access-Control headers
• browser-only enforcement не є API authorization

Практичний приклад

Frontend на app.example.com надсилає JSON з Authorization header до api.example.com. Browser робить OPTIONS preflight, але API не дозволяє Authorization в Access-Control-Allow-Headers, тому browser блокує actual call, хоча endpoint працює в Postman.

Відповідь

WebSocket — persistent full-duplex protocol, який дозволяє client і server надсилати messages у будь-який момент через одне long-lived connection. Він підходить для chat, live notifications, collaborative editing, games, dashboards, trading feeds, telemetry та інших interactive low-latency features. Звичайний HTTP кращий для типового request/response CRUD, polling може бути простішим для рідких updates, а SSE часто достатньо, якщо events ідуть лише server → browser. Вибір залежить від напрямку, частоти, latency та operational complexity.

Сильна відповідь включає

• persistent bidirectional connection
• конкретні real-time use cases
• порівнює WebSocket з polling та SSE

Практичний приклад

Dashboard оновлюється раз на п'ять хвилин, тому WebSocket лише додасть connection management. Collaborative editor із постійними edits від багатьох users — значно кращий WebSocket use case.

Відповідь

У класичному HTTP/1.1 flow client надсилає GET з Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Key та Sec-WebSocket-Version; browser також передає Origin. Успішний server відповідає 101 Switching Protocols і Sec-WebSocket-Accept. Після handshake це вже не звичайні HTTP request/response на цьому connection, а WebSocket text, binary та control frames. Ping/Pong використовуються для liveness, Close — для closing handshake, а logical message може бути fragmented у декілька frames.

Сильна відповідь включає

• HTTP Upgrade та 101 Switching Protocols
• Sec-WebSocket handshake headers
• text/binary/control frames після upgrade

Практичний приклад

DevTools показує успішний 101, але UI не отримує chat messages. Це означає, що transport handshake пройшов, і далі треба перевіряти subscriptions, schema, authorization, server publishing та frame traffic, а не лише HTTP status.

Відповідь

Почніть із connection path: endpoint, TLS, handshake, Origin, authentication та subprotocol negotiation. Потім тестуйте кожен message type: schema, required fields, boundaries, malformed payloads, text/binary, acknowledgement і правильний recipient/room. Додайте ordering, duplicates, concurrent clients та fan-out. Перевірте graceful/abrupt disconnect, reconnect, restore subscriptions, missed messages, heartbeat та close codes. Далі — authorization per message, rate/size limits, slow consumers, багато concurrent connections, reconnect storms та observability через connection/message correlation IDs.

Сильна відповідь включає

• handshake плюс message-contract coverage
• disconnect/reconnect/heartbeat та close-code scenarios
• concurrency, security, performance та observability

Практичний приклад

Для private chat підключіть двох authorized users і одного стороннього. Перевірте ordering та acknowledgements між першими двома, забороніть третьому subscribe до private room, потім перезапустіть server і перевірте reconnect без duplicate messages.

Відповідь

Ping/Pong control frames або application heartbeat допомагають виявляти dead/idle peers, але heartbeat/reconnect policy визначається application. Тестуйте interval, missing response, slow network, proxy idle timeout та cleanup dead sockets. Варто знати 1000 normal closure, 1001 going away, 1002 protocol error, 1008 policy violation, 1009 message too big та 1011 unexpected server condition. Reconnect має використовувати bounded backoff і зазвичай jitter, відновлювати auth/subscriptions, не створювати duplicate active sockets і мати визначену поведінку для missed/in-flight messages.

Сильна відповідь включає

• heartbeat виявляє dead/idle peers
• знає важливі close codes
• reconnect backoff, resubscription та duplicate prevention

Практичний приклад

Reverse proxy закриває idle sockets через 60 секунд, а application heartbeat іде раз на 90 секунд. Users бачать disconnects при здоровому backend. Тест має виявити timeout mismatch і перевірити виправлений heartbeat/reconnect behavior.

Відповідь

Розглядайте opening connection і кожну application action як окремі trust boundaries. Тестуйте missing/expired/revoked credentials, зміну token/session під час active socket, unauthorized room/object/tenant subscriptions та server-side revocation. Browser WebSocket handshake передає Origin, тому перевіряйте origin policy, особливо при cookie auth, але Origin validation не замінює authorization і не є CORS. Для scale моделюйте concurrent connections, connection churn, messages/sec, message sizes, fan-out, reconnect storms, slow consumers/backpressure, memory per socket, CPU, file descriptors, network throughput та proxy/load-balancer limits.

Сильна відповідь включає

• connection та message-level authorization boundaries
• Origin validation не замінює auth
• моделює connection count і message/fan-out load

Практичний приклад

Service тримає 20,000 idle sockets, але падає, коли один event кілька разів на секунду broadcast на всіх clients. Тому load test має змінювати fan-out та slow-consumer behavior, а не оцінювати capacity лише за idle connection count.

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

Продукт захардкоджує англійський шаблон речення 'You have {n} new messages', тож навіть цілком точний переклад слів українською зламається граматично, щойно число вимагатиме іншого відмінкового закінчення; це проблема інтернаціоналізації, яку жодне поліпшення самого перекладу не виправить.

Відповідь

Обирайте репрезентативні локалі, які відрізняються роздільниками десяткових і розрядних груп, позицією та точністю валюти, порядком елементів дати, календарями, початком тижня та системами вимірювання. Перевіряйте форматування і зворотний парсинг (round trip), від'ємні та нульові значення, великі числа та fallback на локаль користувача. Зберігання даних і API тримайте нейтральними щодо локалі там, де це можливо, і виводьте очікувані значення для відображення з довірених даних локалі (наприклад, CLDR), а не з вручну написаних правил під англійську мову.

Сильна відповідь включає

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

Практичний приклад

Форматувальник цін, протестований лише на en-US, проходить із результатом $1,234.56, але при перемиканні на de-DE виявляється, що він видає 1.234,56 зі знаком валюти не на тому боці; матриця тестів, що включає de-DE та RTL-локаль на кшталт ar-EG, ловить і помилку роздільників, і помилку напрямку розміщення, які набір тестів лише під одну локаль пропустив би.

Відповідь

Категорії множини залежать від локалі й можуть включати zero, one, two, few, many та other; дробові числа можуть підпорядковуватись іншим правилам, ніж цілі. Використовуйте CLDR-правила конкретної локалі і тестуйте мінімальний репрезентативний набір значень навколо переходів між категоріями, включно з 0, числами від 11 до 19, числами, що закінчуються на 1 чи 2, і дробами, де це доречно. Перевіряйте все перекладене повідомлення цілком, бо можуть змінюватись і іменники, і дієслова, і відмінки.

Сильна відповідь включає

• знає, що категорії множини залежать від локалі
• тестує значення навколо переходів правил і дроби
• перевіряє повні повідомлення, а не окремі іменники

Практичний приклад

Для повідомлення на кшталт '{n} файлів' українській мові потрібні три форми множини — один файл, два/три/чотири файли, і п'ять і більше файлів — тож система перекладу, розрахована лише на англійську пару one/other, видасть '5 файл' замість '5 файлів', якщо логіка плюралізації не реалізує повноцінно категорії few/many/other CLDR для uk.

Відповідь

Візуально ідентичний текст може використовувати різні послідовності кодових точок (code points), а один сприйманий користувачем символ може складатись із кількох кодових точок. Тому підрахунок байтів, code units, code points і графемних кластерів відповідає на різні запитання. Тестуйте композиційну (composed) та декомпозиційну (decomposed) форми, комбіновані діакритичні знаки, послідовності емодзі та змішані писемності; чітко визначте, де відбувається нормалізація, зберігайте відмінності, важливі для безпеки, і застосовуйте орієнтовані на користувача правила довжини саме до графемних кластерів, де це доречно.

Сильна відповідь включає

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

Практичний приклад

Поле імені користувача відхиляє 'cafe' з попередньо складеною літерою з діакритикою, але мовчки приймає візуально ідентичне ім'я, набране з комбінованим знаком наголосу як окремою кодовою точкою, дозволяючи зареєструвати два візуально однакових імені користувача, які наївна побайтова перевірка на рівність вважає різними рядками, — баг, виявлений лише завдяки тестуванню форм NFC проти NFD того самого слова.

Відповідь

Розділяйте момент часу (instant) і його відображуваний локальний час, і зберігайте призначений ідентифікатор часового поясу, коли майбутні локальні розклади мають слідувати за регіональними змінами правил. Тестуйте прогалини (gaps) і повторювані години DST, перетин півночі та меж дати, пояси зі зсувом, що не кратний годині, зміну поясу користувача та розбіжність між сервером і клієнтом. Перевіряйте повторення подій, сортування, сповіщення та експортовані дані відносно незалежної бібліотеки часових поясів чи календаря.

Сильна відповідь включає

• розділяє моменти часу, локальний час і ідентифікатори поясу
• охоплює пропущені та повторювані години переходу на літній/зимовий час
• тестує подальші ефекти для сортування, повторення та сповіщень

Практичний приклад

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

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

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

Відповідь

Доставляйте один і той самий ідентифікатор події кілька разів — послідовно, конкурентно та після перезапуску споживача, а потім перевіряйте, що бізнесові побічні ефекти відбуваються не більше одного разу, тоді як підтвердження (acknowledgments) і метрики залишаються коректними. Тестуйте дублікати до і після часткового збою, застарілий стан дедуплікації та семантично повторювані події з різними ID. Використовуйте авторитетний збережений стан як оракул, а не лише логи споживача.

Сильна відповідь включає

• тестує дубльовану доставку при перезапусках і конкурентності
• охоплює частковий збій навколо побічного ефекту та підтвердження
• використовує збережений бізнесовий стан як оракул

Практичний приклад

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

Відповідь

Визначте, де саме гарантується порядок — глобально, в межах ключа чи взагалі ніде — і публікуйте перемежовані повідомлення через кілька партицій і споживачів. Вносьте отруйні повідомлення (poison messages), таймаути і збої навколо моменту підтвердження; перевіряйте ліміти повторних спроб, backoff, метадані dead-letter, і те, що непов'язані повідомлення продовжують оброблятись. Відтворюйте (replay) обмежений діапазон і підтверджуйте ідемпотентні результати, збережене походження (provenance) даних та видиме відставання (lag), без мовчазного пропуску даних.

Сильна відповідь включає

• формулює фактичну область дії гарантії порядку
• вносить збої навколо обробки та підтвердження
• перевіряє безпеку replay, докази dead-letter та прогрес обробки

Практичний приклад

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

Відповідь

Генеруйте валідні запити зі схеми, а потім мутуйте граничні значення, опціональні поля, кодування та структурні обмеження, щоб отримати цілеспрямовані невалідні випадки. Перевіряйте протокольні інваріанти — наприклад, що клієнтські помилки не спричиняють серверних помилок (5xx), що відповіді відповідають схемі, що ізоляція авторизації дотримується, і що ідемпотентність узгоджена. Обмежуйте темп кампанії fuzz-тестування, зберігайте seed-и й мінімізовані запити, і додавайте важливі падіння як детерміновані регресійні тести.

Сильна відповідь включає

• генерує як валідні за схемою, так і цілеспрямовано невалідні запити
• перевіряє інваріанти безпеки та протоколу
• зберігає мінімізовані падіння як регресійні кейси

Практичний приклад

Fuzz-тестування ендпоінта, описаного через OpenAPI, глибоко вкладеними й надто великими JSON-навантаженнями спричиняє помилку 500 замість очікуваної 400 для невалідного вводу, розкриваючи необроблений виняток переповнення стеку; мінімізоване падаюче навантаження зберігається як постійний регресійний тест, а не втрачається після завершення кампанії fuzz-тестування.

Відповідь

Клієнт визначає адресу хоста, встановлює з'єднання, за потреби узгоджує TLS, надсилає HTTP-запит, отримує заголовки та вміст, а потім браузер парсить ресурси і виконує логіку сторінки. Кеші, проксі, CDN та service worker-и можуть змінювати цей шлях.

Сильна відповідь включає

• DNS, з'єднання та HTTP
• рендеринг у браузері
• проміжні вузли й кеш

Практичний приклад

Тестувальник, який дебажить повільне завантаження сторінки, відкриває вкладку мережі в браузері та проходить по waterfall-діаграмі: пошук DNS зайняв 200 мс через повільний резолвер, потім промах кешу CDN додав ще 300 мс, перш ніж прийшов сам HTML, — виявляється, вузьке місце в інфраструктурі, а не в коді застосунку.

Відповідь

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

Сильна відповідь включає

• заголовки й тіло запиту
• семантика й побічні ефекти
• спостережуваність

Практичний приклад

Тест перевіряє лише, що виклик POST /orders повертає 201 з правильним JSON-тілом, але пропускає, що у відповіді відсутній заголовок Location і що замовлення фактично записалося в базу даних двічі — перевірка заголовків і зіставлення зі станом на сервері виявили б обидві проблеми.

Відповідь

1xx — інформаційні, 2xx — успіх, 3xx — переспрямування, 4xx — помилка на боці клієнта, 5xx — помилка сервера. Тести також мають перевіряти конкретний код, контракт відповіді, поведінку кешування та те, чи справді відбулася задумана зміна стану.

Сильна відповідь включає

• усі п'ять сімейств
• семантика конкретного коду
• перевіряє стан за межами статусу

Практичний приклад

Тест перевіряє лише, що виклик DELETE повертає код 2xx, і проходить, хоча API насправді повернув 202 Accepted замість 204 No Content, а ресурс видалявся асинхронно у фоновому режимі. Строгіша перевірка точного коду плюс наступний GET-запит виявили б цю прогалину в eventual consistency.

Відповідь

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

Сильна відповідь включає

• заміна проти часткової зміни
• ідемпотентність
• пропущені та конфліктні поля

Практичний приклад

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

Відповідь

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

Сильна відповідь включає

• свіжість і валідатори
• інвалідація
• ізоляція приватних даних

Практичний приклад

Тестувальник заходить під користувачем A, завантажує сторінку з балансом рахунку, потім виходить і заходить під користувачем B в тій самій вкладці браузера в межах вікна кешування CDN — і виявляє, що користувач B на мить бачить закешований баланс користувача A. Це критичний витік через спільний кеш, причина якого — відсутній заголовок Vary: Authorization.

Відповідь

REST зазвичай використовує HTTP-ресурси та різноманітні представлення, тоді як SOAP використовує XML-конверти й формальні контракти сервісів з розширеннями протоколу. В обох випадках тестуйте контракт, транспорт, автентифікацію, фолти (faults), сумісність та бізнес-побічні ефекти, а не покладайтеся лише на назву технології.

Сильна відповідь включає

• орієнтація на ресурси проти повідомлень
• контракти й фолти
• уникає твердження, що щось за замовчуванням краще

Практичний приклад

Тестуючи застарілий SOAP-сервіс, тестувальник валідує відповідь за XML-схемою, визначеною у WSDL, і перевіряє коди SOAP fault для помилкових сценаріїв, тоді як для REST-аналога валідує відповідь за схемою OpenAPI й перевіряє HTTP-статуси — базові ризики, такі як порушений контракт чи необроблені помилки, ті самі, відрізняється лише механіка.

Відповідь

Перевірте семантику прийняття запиту та кореляційні ID, а потім спостерігайте за ресурсами статусу, колбеками, чергами чи подіями до досягнення визначеного термінального результату. Покрийте повторні відправлення, повтори (retries), таймаути, порядок, часткові збої та eventual consistency без фіксованих затримок (sleep).

Сильна відповідь включає

• кореляція та термінальні стани
• eventual consistency
• повтори та ідемпотентність

Практичний приклад

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

Відповідь

Перевіряйте рукостискання (handshake) й авторизацію, поведінку heartbeat і таймауту, backoff при переприєднанні, повторну підписку, дубльовані чи втрачені повідомлення, порядок, стан UI в офлайні та відновлення після рестарту сервера. Переконайтеся, що переприєднання не обходить контроль доступу.

Сильна відповідь включає

• життєвий цикл з'єднання
• цілісність повідомлень
• авторизація після переприєднання

Практичний приклад

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

Відповідь

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

Сильна відповідь включає

• перевірки на основі схеми
• можливості генерації
• чіткі межі контракту

Практичний приклад

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

Відповідь

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

Сильна відповідь включає

• поведінка схеми й резолверів
• авторизація на рівні поля
• складність і часткові помилки

Практичний приклад

Тестувальник виявляє, що GraphQL-запит профілю користувача повертає частковий результат: дані для більшості полів, але null для поля «зарплата» разом з помилкою в масиві errors, бо резолвер саме цього поля перевіряє авторизацію окремо — такий клас багів не виявити звичайним тестуванням HTTP-статусів у REST.

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

Ендпоінт сервісу зображень повертав заголовки ETag, і команді треба було підтвердити, що у відповідь на повторний If-None-Match клієнт отримує саме 304 Not Modified. Запити проходили через CDN, який автоматично повторював невдалі звернення до origin-сервера, а це могло подвійно застосувати неідемпотентний запис, якщо кешування не продумати ретельно. Такий послідовний розбір перетворив розпливчасту скаргу на короткий відтворюваний опис, за яким хтось інший міг діяти без зайвого перепитування.

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

Ендпоінт сервісу зображень повертав заголовки ETag, і команді треба було підтвердити, що у відповідь на повторний If-None-Match клієнт отримує саме 304 Not Modified. Старі мобільні клієнти, які досі працювали в продакшні, очікували попередню форму відповіді, тож контрактний тест мав перевіряти і стару, і нову схему. Поставивши цей ризик вище за косметичні проблеми в беклозі, команда полагодила його того ж дня, а не поставила в чергу наступного спринту.

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

Ендпоінт сервісу зображень повертав заголовки ETag, і команді треба було підтвердити, що у відповідь на повторний If-None-Match клієнт отримує саме 304 Not Modified. Два клієнти надіслали PATCH-запити на той самий ресурс з різницею в мілісекунди, і виграти мав лише один, не перезаписавши мовчки зміни іншого. Підсумковий тест-план покрив ті два-три сценарії, які справді мали значення, і свідомо пропустив решту, щоб залишатися швидким і легким у підтримці.

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

Ендпоінт сервісу зображень повертав заголовки ETag, і команді треба було підтвердити, що у відповідь на повторний If-None-Match клієнт отримує саме 304 Not Modified. Сервіс ціноутворення, від якого залежав ендпоінт, почав час від часу відповідати з таймаутом, і питання було в тому, чи ендпоінт деградує коректно, чи віддає застарілі неправильні дані. Перевіривши спершу точний час, вхідні дані й оточення — ще до того, як чіпати код, — команда знайшла справжню причину менш ніж за годину замість цілого дня здогадок.

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

Ендпоінт сервісу зображень повертав заголовки ETag, і команді треба було підтвердити, що у відповідь на повторний If-None-Match клієнт отримує саме 304 Not Modified. Кожну відповідь треба було перевірити, щоб переконатися, що запит у межах тенанта A ніколи не витікає кешованим чи резолвленим полем, яке належить тенанту B. Повторювану частину, що не потребувала експертної оцінки, заскриптували в CI, а крок, який вимагав людського рішення, свідомо залишили ручним.

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

Ендпоінт PATCH /orders/{id} за специфікацією OpenAPI мав повертати 200 з повним ресурсом у тілі, але одна з клієнтських бібліотек мовчки приймала й 204 без тіла відповіді. Запити проходили через CDN, який автоматично повторював невдалі звернення до origin-сервера, а це могло подвійно застосувати неідемпотентний запис, якщо кешування не продумати ретельно. Реліз випустили лише тоді, коли хтось зміг показати конкретні докази, назвати, хто погодив рішення, і чітко сформулювати, який ризик свідомо залишили відкритим.

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

Ендпоінт PATCH /orders/{id} за специфікацією OpenAPI мав повертати 200 з повним ресурсом у тілі, але одна з клієнтських бібліотек мовчки приймала й 204 без тіла відповіді. Старі мобільні клієнти, які досі працювали в продакшні, очікували попередню форму відповіді, тож контрактний тест мав перевіряти і стару, і нову схему. Такий послідовний розбір перетворив розпливчасту скаргу на короткий відтворюваний опис, за яким хтось інший міг діяти без зайвого перепитування.

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

Ендпоінт PATCH /orders/{id} за специфікацією OpenAPI мав повертати 200 з повним ресурсом у тілі, але одна з клієнтських бібліотек мовчки приймала й 204 без тіла відповіді. Два клієнти надіслали PATCH-запити на той самий ресурс з різницею в мілісекунди, і виграти мав лише один, не перезаписавши мовчки зміни іншого. Поставивши цей ризик вище за косметичні проблеми в беклозі, команда полагодила його того ж дня, а не поставила в чергу наступного спринту.

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

Ендпоінт PATCH /orders/{id} за специфікацією OpenAPI мав повертати 200 з повним ресурсом у тілі, але одна з клієнтських бібліотек мовчки приймала й 204 без тіла відповіді. Сервіс ціноутворення, від якого залежав ендпоінт, почав час від часу відповідати з таймаутом, і питання було в тому, чи ендпоінт деградує коректно, чи віддає застарілі неправильні дані. Підсумковий тест-план покрив ті два-три сценарії, які справді мали значення, і свідомо пропустив решту, щоб залишатися швидким і легким у підтримці.

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

Ендпоінт PATCH /orders/{id} за специфікацією OpenAPI мав повертати 200 з повним ресурсом у тілі, але одна з клієнтських бібліотек мовчки приймала й 204 без тіла відповіді. Кожну відповідь треба було перевірити, щоб переконатися, що запит у межах тенанта A ніколи не витікає кешованим чи резолвленим полем, яке належить тенанту B. Перевіривши спершу точний час, вхідні дані й оточення — ще до того, як чіпати код, — команда знайшла справжню причину менш ніж за годину замість цілого дня здогадок.

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

У GraphQL-схему каталогу товарів додали нове nullable-поле, і резолвер для нього робив окремий запит до бази даних на кожен елемент у списку з 200 товарів. Запити проходили через CDN, який автоматично повторював невдалі звернення до origin-сервера, а це могло подвійно застосувати неідемпотентний запис, якщо кешування не продумати ретельно. Повторювану частину, що не потребувала експертної оцінки, заскриптували в CI, а крок, який вимагав людського рішення, свідомо залишили ручним.

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

У GraphQL-схему каталогу товарів додали нове nullable-поле, і резолвер для нього робив окремий запит до бази даних на кожен елемент у списку з 200 товарів. Старі мобільні клієнти, які досі працювали в продакшні, очікували попередню форму відповіді, тож контрактний тест мав перевіряти і стару, і нову схему. Реліз випустили лише тоді, коли хтось зміг показати конкретні докази, назвати, хто погодив рішення, і чітко сформулювати, який ризик свідомо залишили відкритим.

Відповідь

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

Сильна відповідь включає

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

Практичний приклад

У GraphQL-схему каталогу товарів додали нове nullable-поле, і резолвер для нього робив окремий запит до бази даних на кожен елемент у списку з 200 товарів. Два клієнти надіслали PATCH-запити на той самий ресурс з різницею в мілісекунди, і виграти мав лише один, не перезаписавши мовчки зміни іншого. Такий послідовний розбір перетворив розпливчасту скаргу на короткий відтворюваний опис, за яким хтось інший міг діяти без зайвого перепитування.

Відповідь

Окремо перевіряйте встановлення connection та authentication і окремо — поведінку повідомлень. Покрийте обидва напрями передачі, message schema й authorization, кілька клієнтів, subscribe/unsubscribe state, коректне закриття, heartbeat або timeout, disconnect/reconnect і повторну subscription. Ін'єктуйте duplicates, delayed та reordered messages і короткі bursts, після чого перевіряйте задокументовані правила ordering, deduplication і recovery продукту, а не припускайте, що TCP автоматично вирішує application-level state.

Сильна відповідь включає

• відокремлює handshake та authorization від перевірок самих повідомлень
• покриває disconnect, reconnect, resubscription і кілька одночасних клієнтів
• перевіряє duplicates, delay, reordering і burst traffic за явними правилами продукту

Практичний приклад

Дві browser sessions підключаються до одного support chat. QA перевіряє, що обидві отримали message A, розриває одне connection перед message B, відновлює його та перевіряє, чи продукт правильно повертає subscription без дублювання A або втрати B; неавторизована третя session при цьому не повинна мати можливості підписатися на цю розмову.