JSON and XML

JSON and XML are data exchange formats. For QA, they are part of the contract between systems. Invalid structure can break an integration even when its business logic is correct.

Beginners often stop at “a response arrived, so everything is fine.” The response's shape matters too. One incorrectly typed field, unexpected nesting level, missing value, or additional XML namespace can break a client, parser, integration, or automated test.

QA should therefore be comfortable reading both JSON and XML, even if a project rarely uses one of them.

JSON

JSON is a lightweight text format for structured data and is particularly common in modern web and mobile APIs. It is compact, readable, and maps conveniently to objects, arrays, strings, numbers, booleans, and null.

Basic JSON literacy means confidently recognizing:

→Objects versus arrays
→Strings versus numbers
→Missing values versus explicit null values
→How fields are nested
→Required versus optional fields

These distinctions seem obvious until real defects arise. A backend may replace an object with a one-element array, return a number as a string, or return null instead of omitting a field. These may look similar to a person, but they represent different contracts to a client.

JSON's readability does not make its structure optional. Many REST integration problems arise because teams treat structure casually and assume the client will somehow handle it.

XML

XML is an older, more formal text format. It is more verbose than JSON but well suited to strict schemas, complex hierarchies, enterprise integrations, and systems requiring formal structural validation.

XML is especially relevant to QA in:

→SOAP and legacy APIs
→Banking and government integrations
→Document exchange
→Systems using XSD schemas
→Complex B2B integrations

Alongside objects and arrays familiar from JSON, XML introduces several important concepts:

→Elements
→Attributes
→Nesting
→Namespaces
→Schemas and validation
→Encoding

XML is often harder to diagnose manually because it contains more structural overhead and more opportunities for defects in the document's form rather than its data.

That does not make XML inferior. It represents a different kind of contract requiring greater discipline.

What matters for QA

The useful question is what to verify in each format, rather than which format is better.

For JSON, inspect:

→Required and optional fields
→Data types
→Null, empty values, and omitted fields
→Nested objects and arrays
→Structural stability across API versions

For XML, also inspect:

→Correct tags
→Attributes and their values
→Valid nesting
→Namespaces
→Compliance with XSD or another schema
→Correct encoding

An important QA skill is distinguishing three situations:

→A field is absent
→A field is present but empty
→A field is present and explicitly null

These can represent different business and client states: an address was not submitted, an empty address was submitted, or an address was explicitly cleared. Overlooking the distinction can hide contract defects.

Common failures

→A field name differs from what the client expects
→A number becomes a string
→An array replaces an object
→Nesting changes
→A required field disappears
→A value uses an unexpected format
→An XML document is invalid
→A namespace is incorrect
→A schema changes without corresponding client or integration updates

Another class of problems involves changes assumed to be compatible. Adding a backend field is usually safe, but an overly strict client parser may still fail. Conversely, a team may remove an apparently unused field that an older consumer still depends on.

QA should test data formats as part of the contract, with the same care as behavior.

Practical example

Consider a user profile API that originally returned JSON with:

→id as a number
→name as a string
→phones as an array
→address as an object

After a change, the backend returns:

→id as a string
→phones as a single object when only one number exists
→address as null
→A new status field

A backend developer may see this as a small change. For clients, it risks breaking serialization, validation, display, automated tests, and compatibility with older versions.

XML has similar risks, often with more sensitive failure points. Changing a namespace, nesting structure, or required attribute can make an integration unable to interpret the document at all.

Key takeaways for QA

→JSON and XML form part of the API contract, beyond a way to display data.
→For JSON, focus on types, nesting, arrays, null, and missing fields.
→For XML, tags, attributes, namespaces, schemas, and encoding are also critical.
→A small structural change can break a client as severely as a business logic defect.
→Check data formats as rigorously as user scenarios.