Testing via API чи Testing of API: коли і що ми тестуємо?

Тестуванню API у силабусі ISTQB Foundation Level 4.0 приділяється досить небагато уваги, але на практиці одним із основних викликів є розібратися, яку саме роль відіграє API у кожному конкретному кейсі. 
Багато хто вважає API testing видом тестування, хоча насправді часто це обʼєкт тестування (як і mobile, desktop та web). Ще більша плутанина виникає, коли ми намагаємося співвіднести test levels та api testing - тобто на якому рівні тестування ви знаходитесь, тестуючи api. Наш випускник курсу підготовки до ISTQB Foundation Level, Software Test Engineer з SoftServe Михайло Ченчак під час підготовки до іспиту розклав по поличках особливості тестування API на різних рівнях тестування. А Інна Осінна, експертка з тестування АРІ та авторка курсу “Client-Server Architecture & API Testing” прокоментувала дослідження Михайла.
Тож давайте розбиратися разом!

Що таке API Testing

Під API Testing зазвичай розуміють:● Testing via API — тестування системи або компонента за допомогою API (відповідає визначенню API Testing з ISTQB Glossary). В цьому випадку API використовується як засіб доступу до об'єкта тестування - компонента або системи.● Testing of API — безпосереднє тестування самого API. API є об'єктом тестування.

“Я погоджуюся з логікою розмежування на Component Level та Component Integration Level, оскільки на цих рівнях дійсно можна чітко відокремити випадки, коли API є об’єктом тестування (Testing of API), і коли API використовується як інтерфейс для тестування іншого об’єкта (Testing via API). Це відповідає і підходам, описаним в ISTQB, і практиці роботи з різними видами внутрішніх інтерфейсів (internal APIs, method calls, SDK).
Проте, щодо System Level та System Integration Level я маю сумніви щодо доцільності їх суворого відокремлення. За визначенням, система — це множина взаємопов’язаних компонентів, що утворюють єдине ціле. На системному рівні ми завжди оцінюємо не лише поведінку кожного компонента, а й взаємодію між ними. Таким чином, елементи інтеграційного тестування невід’ємно присутні у системному тестуванні.
У сучасних архітектурах (наприклад, microservices, SOA, event-driven architectures) межа між System Testing та System Integration Testing стає ще більш розмитою. Для мікросервісної архітектури, наприклад, “система” часто — це набір сервісів, що взаємодіють виключно через API. У такому випадку тестування системи неминуче включає і перевірку інтеграцій, і перевірку самого API.
Отже, на системному рівні Testing of API та Testing via API найчастіше динамічно поєднуються:    ● Ми можемо паралельно перевіряти відповідність API контракту (of API) та коректність бізнес-логіки, яку API тригерить (via API).    ● Фокус змінюється залежно від цілей тесту: наприклад, у сценарії end-to-end ми починаємо “via API”, але при знаходженні дефекту можемо перейти у фокус “of API”.
Таким чином, на відміну від компонентного рівня, на системному рівні жорстке розділення Testing of API та Testing via API часто неефективне - реальні сценарії тестування вимагають їх комбінації."
Якщо вам цікаво глибше розібратися, чому в сучасних архітектурах так важко відокремити системне тестування від інтеграційного, і як будувати ефективні стратегії тестування для таких систем — я розбираю ці теми у своєму курсі Client-Server Architecture & API Testing. Це якраз та база, яка допоможе не плутатись у таких нюансах та впевнено пояснювати їх іншим.

Інна Осінна, експертка з тестування API

Висновки

Цікаво, що щільно працюючи з API ви могли ніколи не замислюватись над рівнями, на яких тестуєте. Тим не менш, розібравшись з цим для себе, ви не тільки зможете краще відповідати на питання про test levels на сертифікаційному іспиті, а й:● показати на співбесіді рівень експертності в практиці vs теорії - знаю “як тестувати” і розумію “для чого”;● розуміти, де чия зона відповідальності, коли над різними частинами продукту працюють різні команди;● прицільно робити root cause analysis упущених дефектів в зоні інтеграцій.