Backend testing: What does it actually mean?

I had an HR tell me I didn’t have experience in “Backend Testing” :man_shrugging:
I mean, don’t we test the “Backend” when we’re going about our normal testing? or is it expected that the individual services that are integrated should be tested in isolation? I guess API testing would fall in Backend testing but what if one seldom write’s any new APIs and all the existing ones are already optimized. What more could there be? Putting certain modules under load and checking the results? That’s performance testing and I don’t think it’s done on a daily basis.
All said though, when we interact with the UI and put the system under several tests, we’re trying to create an impact on every nook and cranny of the whole architecture right?


For me API testing is practically BE testing, I suppose you could include knowledge of SQL under backend testing too, as well as knowing a thing or two about servers (in most cases Linux servers), having knowledge of the command line to use CLIs and test console apps which have no GUI, knowing how to use certain cloud providers and services, etc.


I think when people say “backend testing”, they usually mean testing the system through other means than UI. Apparently, there are many folks in testing that only ever interacted with their systems through graphical UI, and apparently some of these folks even created automation. I have my doubts.

Testing the server itself, including data flows, database interactions and any background processes - I would count these among “backend testing”, but I’m unsure if these are the things interviewers are looking for.

Personally, I would not ask about “backend testing”, at least not without first explaining what I mean. But I would rather ask to explain the architecture of the system that candidate worked with, or common architecture built around RESTful communication, or I would ask to imagine that clicking “submit” on website form does nothing visible, and walk me through the process of discovering what could be wrong.

I don’t know what is the situation where you are, and I don’t know the details of the conversation this was brought up. But over here the market is crazy - there are stories of companies receiving hundreds, even thousand of applications for single opening. Nobody can process that much data and obviously some good candidates are being left out without having the opportunity to show off their real value. HR is usually one of the first contacts and all too often they don’t have enough knowledge to have in depth conversation - so all they know is that this role needs backend testing experience, and they ask people if they have it, and having that checkbox checked makes all the difference between going forward and being rejected.

So, I would not hang on to this too much, unless they can explain what they actually mean and what they were looking for. If you are still in touch with them, it won’t hurt to ask.

Now, to some of the specific questions

It’s certainly a good idea to test individual services in isolation. Usually such testing reveals that services are more coupled than the team though they are. What usually happens next is that team agrees that certain things can’t be tested in isolation, but other things can and should.

While this is often quoted as one of the benefits of backend and frontend decoupling (and having single backend serving multiple frontend apps), in my experience APIs change and evolve with the product. It’s rare to see backend that does not change at all for extended period of time (assuming it is still maintained).

While they might have meant load, stress or performance testing, I agree that usually when people mean these, they use these exact words.

You are correct, but I think most people share the belief that things should be tested at the lowest level they can be tested. If you can test something at unit level, it should be tested at unit level. If you can test something using API, don’t open the browser. This is especially relevant in the context of automation that runs periodically, as lower levels are usually faster to run.

1 Like

In this scenario I would say you might be able to figure it out from the job spec. Did they highlight any areas you maybe didn’t mention in your CV. Could be some clues in the tools that they request you have experience with.

That being said from my experience backend testing is a very broad term. Could be API testing, DB queries, log analysis or some places might want experience with observability, infrastructure deployments, performance, etc.

Some companies of type B2B2C refer to the user-facing interface as the frontend and the client-company-facing interface as the backend.
There’s also frontend to refer to the user-facing features and backend to refer to the administration systems/modules/tools (operations, support, development/configuration).
I’ve also experienced the saying that anything that non-developers can access is called frontend, otherwise, it’s backend.

Mirek already covered the classical backend context.
I recommend clarification.

1 Like

Explicit backend testing focuses more directly on testing server-side functionality. For example, it may refer to some or all of the following things.
Checking logs on the server helps identify errors, performance bottlenecks, and security issues. DB testing ensures data integrity by checking field types, constraints, indexing, and validating data migrations.
Job scheduling testing that background processes and scheduled jobs run as expected, independent of UI or API actions. Resource testing to check server resources like CPU, RAM, and disk space under various conditions.
Of course, API testing verifies the functionality, security, and performance of backend APIs. Service layer testing to ensure that individual services work correctly and validate their integration points.
Security testing for example checking for vulnerabilities like SQL, command injection and ensuring proper authentication and authorization. Performance and load testing, high-load conditions to evaluate the backend’s performance and scalability.
You know that in software testing, there are different approaches to testing different parts of a system :slight_smile: Some tests focus on the BE, while others focus on the FE (UI). There are different testing methods specifically designed for backend or UI. For example, when conducting backend testing on a client (UI), the focus is on testing the backend features, skipping the UI tests. This requires an understanding of the backend specifics and how to effectively test them

1 Like