Інна Осінна
QA Lead & Senior Manual QA
- 6+ років у тестуванні
- QA Team Lead і засновниця QARMA — освітнього онлайн простору для QA
- Веду курси про клієнт-серверну архітектуру й тестування API та про тест-дизайн
- Пишу про тестування в соцмережах і періодично виходжу на сцену, щоб сказати вголос те, про що в командах домовляються пошепки
- Переконана, що документація, яку ніхто не звіряє з реальністю, шкодить більше, ніж її відсутність
Тема доповіді:
«Контракт бреше: OpenAPI проти реальної поведінки»
Опис:
OpenAPI-спеку звикли читати як документацію. Насправді це тестовий оракул — і якщо його ніхто не звіряє з рантаймом, він тихо розходиться з сервісом: enum виріс, тип поля змінився, «необовʼязкове» поле зникло. Тести при цьому зелені, бо написані по тій самій спеці, яка вже бреше.
Розберемо, звідки береться дрейф контракту, як він виглядає в реальних відповідях і як ловити його в CI.
З живим демо: сервіс зі зламаним контрактом, який ручна перевірка в Postman пропускає. І з чесною межею інструмента — один із чотирьох дефектів не впіймає навіть валідація за схемою.
Тези доповіді:
- Звідки береться дрейф контракту: спека пишеться руками або генерується з іншої гілки, власника в неї немає, а тести зелені — бо оракул і обʼєкт перевірки взяті з одного джерела.
- Таксономія дрейфу з прикладами й ціною для клієнта: nullable, який віддає null; enum, що виріс; поле, що зникло; integer, що став рядком; off-by-one у пагінації; 200 з тілом помилки
- Як ловити: валідація відповіді проти схеми прямо в тестах, diff двох версій спеки, breaking change detection у CI
- Чесна різниця між schema validation і contract testing — і де перша не рятує
- Демо: сервіс із прапорцем DRIFT і чотирма розходженнями
- Що з цим зробити в понеділок.
Для кого:
- Для тих, хто вже тестує API — руками, кодом або і так, і так — і читає OpenAPI-спеку як даність
- Мануальним, автоматизаторам і лідам, які вирішують, що ставити в CI
- Досвід contract testing не потрібен: достатньо розуміти, що таке HTTP-запит і схема відповіді.