JSON и XML - это форматы обмена данными. Для QA это не "техническая мелочь", а часть контракта между системами. Если структура данных нарушена, интеграция может сломаться даже тогда, когда бизнес-логика сама по себе написана правильно.
Новички обычно смотрят на данные слишком поверхностно: "ответ пришёл, значит всё ок". На практике важно не только наличие ответа, но и его форма. Одно поле с неправильным типом, одна неожиданная вложенность, одно пропавшее значение или один лишний namespace в XML могут сломать клиент, парсер, интеграцию или автотесты.
Поэтому QA должен уметь уверенно читать и JSON, и XML, даже если в проекте один из них встречается редко.
JSON
JSON - это лёгкий текстовый формат для представления структурированных данных. В современных web и mobile API он встречается чаще всего. Его популярность объяснима: он компактнее, проще читается человеком и удобно маппится на объекты, массивы, строки, числа, boolean и null.
Для QA базовая грамотность по JSON означает, что ты уверенно видишь:
- →где объект, а где массив
- →где строка, а где число
- →где значение отсутствует, а где оно явно равно null
- →какие поля вложены друг в друга
- →какие поля обязательны, а какие опциональны
Это кажется очевидным, пока не начинаются реальные баги. Например, backend раньше возвращал один объект, а после изменения стал возвращать массив из одного элемента. Или число стало строкой. Или поле не исчезло, а стало null. Для человека визуально это может выглядеть почти одинаково, а для клиента это уже разные контракты.
Ещё один важный момент: JSON обычно очень удобен для чтения, но это не значит, что он "нестрогий". Наоборот, многие проблемы интеграций в REST API связаны именно с тем, что команда слишком легкомысленно относится к структуре JSON и считает, что клиент "как-нибудь разберётся".
XML
XML - более старый и более формальный текстовый формат. Он многословнее, чем JSON, но его сильная сторона в том, что он хорошо подходит для строгих схем, сложных иерархий, enterprise-интеграций и систем, где важна валидация структуры на формальном уровне.
Для QA XML особенно важен в таких сценариях:
- →SOAP и legacy API
- →банковские и государственные интеграции
- →обмен документами
- →системы с XSD-схемами
- →сложные B2B-интеграции
Если в JSON ты чаще думаешь категориями "объект и массив", то в XML добавляются ещё несколько важных понятий:
- →элементы
- →атрибуты
- →вложенность
- →namespaces
- →схемы и валидация
- →encoding
Именно из-за этого XML обычно сложнее для ручной диагностики. Там больше шума, больше служебной структуры и больше мест, где ошибка может быть не в данных как таковых, а в самой форме документа.
Но это не делает XML "хуже". Это просто другой тип контракта, который требует большей дисциплины.
Что важно QA
Для тестировщика главное не спорить, что лучше, а понимать, что именно нужно проверить в формате данных.
Если перед тобой JSON, полезно смотреть на:
- →обязательные и опциональные поля
- →типы данных
- →null, пустые значения и отсутствие поля
- →вложенность объектов и массивов
- →стабильность структуры между версиями API
Если перед тобой XML, к этому добавляются:
- →правильность тегов
- →атрибуты и их значения
- →корректность вложенности
- →namespaces
- →соответствие XSD или другой схеме
- →корректная кодировка
Очень важный навык для QA - различать три разных ситуации:
- →поле отсутствует
- →поле есть, но пустое
- →поле есть и равно null
С точки зрения бизнеса и клиента это могут быть три разных состояния. Например, "адрес не передавался", "адрес передавался, но пустой", "адрес явно очищен". Если QA не различает эти случаи, он легко пропускает дефекты контракта.
Где реально ломается
- →поле называется не так, как ожидает клиент
- →изменился тип: было число, стала строка
- →вместо объекта пришёл массив
- →изменилась вложенность
- →обязательное поле исчезло
- →значение пришло в неожиданном формате
- →XML-документ формально невалиден
- →namespace указан не тот
- →схема обновилась, а клиент или интеграция нет
Есть ещё один важный класс проблем - "почти совместимые" изменения. Например, backend добавил новое поле и решил, что это безопасно. Чаще всего это и правда безопасно. Но если какой-то клиент парсит ответ слишком жёстко, он может сломаться даже от такого изменения. Или наоборот: команда убрала поле, считая его "неиспользуемым", а на самом деле на него завязан старый consumer.
Для QA это означает простую вещь: формат данных нужно тестировать как часть контракта, а не как косметику.
Практический пример
Представь API профиля пользователя. Раньше он возвращал такой JSON по смыслу:
- →id как число
- →name как строку
- →phones как массив
- →address как объект
После изменения backend начинает возвращать:
- →id как строку
- →phones как один объект, если номер только один
- →address как null
- →новое поле status
С точки зрения разработчика backend это может казаться "небольшой правкой". С точки зрения клиента это уже риск поломки сериализации, валидации, отображения, автотестов и совместимости старых версий.
В XML будет похожая история, только проблемные места обычно ещё чувствительнее. Достаточно поменять namespace, структуру вложенности или обязательный атрибут, и интеграция может перестать понимать документ вообще.
Что должен вынести QA из этой темы
- →JSON и XML - это часть API-контракта, а не просто способ красиво показать данные.
- →В JSON особенно важно следить за типами, вложенностью, массивами, null и отсутствующими полями.
- →В XML дополнительно критичны теги, атрибуты, namespaces, схемы и encoding.
- →Небольшое изменение структуры может сломать клиента так же сильно, как и ошибка в бизнес-логике.
- →Формат данных нужно проверять с той же серьёзностью, что и сами сценарии.
Что ещё почитать
- →Внутри базы: Методы, статус-коды, заголовки
- →Внутри базы: Contract testing
- →Внешний материал: RFC 8259 JSON