Client–server architecture is a model in which one part of a system requests data or an action, and another part provides it. The client initiates a request; the server processes it and returns a result.
That sounds simple, but it is one of the foundational models for QA. Once you start viewing a product this way, many bugs stop looking like "strange UI behavior" and become identifiable points of failure: the client, network, server, database, external integration, cache, queue, or authorization.
How it works
In a typical web or mobile product, the client is a browser, mobile application, or another service. The user clicks a button, and the client collects data and sends a request. The server receives it, checks permissions, validates the input, executes business logic, and, if necessary, accesses a database or external systems.
- →A client can be a browser, mobile application, another service, or an external partner.
- →The server is not always a single process or a monolith.
- →Gateways, load balancers, caches, queues, databases, and external integrations often sit along the path between the client and the server.
A single user click can therefore trigger an entire chain of actions rather than a single operation.
A simple example
A user clicks "Pay for order." The client sends a request containing the order ID, amount, and user details. The server checks whether the order exists, whether the user may pay for it, and whether its current status permits payment. It then calls the payment provider, saves the result, and returns a response to the client.
The user sees only the button and the final message. QA needs to see the entire chain. Otherwise, it is easy to misidentify the cause of a defect.
What QA needs to check
- →Whether a request was sent at all.
- →Exactly which request was sent.
- →What the server returned.
- →How the client interpreted the response.
- →Whether data changed wherever it should have changed.
- →Whether an external service or an unstable environment is involved.
If the UI displays an incorrect amount, there are several possible causes: the server returned the wrong value, the database contains incorrect data, an external service returned an unexpected response, or the client rendered a correct response incorrectly. The visible symptom is the same, but the points of failure differ.
The layers most often tested
- →Client layer: whether the request was sent, the parameters were assembled correctly, and the result was displayed correctly.
- →Server layer: whether validation, access control, and business logic worked correctly.
- →Data layer: whether data was created, updated, or deleted as expected.
- →Integration layer: how the system handles failures, timeouts, and unexpected responses from external services.
Where this helps in practice
First, defect investigation. A tester who sees only the screen writes "it doesn't work." A tester who understands the architecture writes: the request contained an incorrect parameter; the server returned 403 even though the role should have access; the database was not updated. This is a much higher standard of reporting.
Second, test design. Understanding the layers involved in a scenario helps you design stronger checks: the UI happy path, network errors, repeated requests, partial failures, inconsistent data, and integration problems.
Third, team communication. This model helps you be specific: the problem is in the client, server, data, or external provider. That saves time and makes triage more straightforward.
Key takeaways for QA
- →A single user action often involves several technical steps.
- →The same visible UI bug can originate in different system layers.
- →To isolate a problem, examine the request, response, data, and dependencies as well as the screen.
- →Understanding client–server architecture makes bug reports more precise and speeds up investigations.
Further reading
- →In this knowledge base: What Is an API? — an introduction to the interface used for communication.
- →In this knowledge base: HTTP and HTTPS — for a better understanding of the transport layer for requests and responses.
- →In this knowledge base: Methods, Status Codes, and Headers — for greater confidence interpreting technical API signals.
Trace one action from browser to storage
Fictional scenario: a learner saves a profile display name. The expected result is that a subsequent read shows the new name for the same authorized account. A success toast alone proves only that the client displayed a message; it does not establish the stored state.
Layer Observation What it can establish
Browser Action, input, request payload and timing What the client actually sent
Network/API Method, URL, status, body, correlation ID The observed API response
Service logs Same correlation ID and validation outcome Which server path handled the request, if logs are available
Storage Authorized test read of the target record Persisted value at the observed time
Follow-up API read GET response for the same account Whether the read path exposes the saved valueUse an authorized test read or fixture rather than assuming database access exists. In asynchronous systems, immediate consistency may not be promised: agree the completion signal and time window first. If the browser timed out after sending a write, inspect the result before retrying. The server may already have committed it.
To isolate a failure, compare neighboring observations. Wrong request data points toward client preparation; a correct request with a documented validation error points toward contract/input interpretation; a success response with missing data requires investigation of the write path or an asynchronous workflow. These are investigation directions, not proven causes. Preserve timestamps and correlation IDs and remove secrets from evidence.