Backend Testing: What Is It and How It’s Done at EGO

Every one of us has at least bumped into an app bug that would provide no details at all. Whether it’s an “Unknown server error” or just a blank page instead of an app’s screen, it’s always frustrating to find yourself being unable to even figure out what went wrong and who’s responsible for the bug.

These and some other kinds of bugs and errors can and should be eliminated through backend testing. As a quality assurance/testing company we know from our experience that the better it is performed, the more reliable, predictable, and efficient your app will be.

Since this is a technical post, let’s first make sure we’re on the same page with the technical vocabulary. Then we’ll explain the differences between testing products leveraging our and third-party APIs. After that, we’ll talk a bit about the most popular tool for back-end testing, i.e. Postman.

Backend, API, frontend: what’s the difference?

Any application consists of the frontend and the backend. The picture below represents a common app architecture, though deviations are possible.

The frontend is what the user sees when interacting with the app. Texts, buttons, input fields, pictures, animations, and so on. Small apps might have a front-end consisting of only a few screens, while big projects will include lots of sophisticated graphics and interactive elements.

The backend, on the contrary, can’t be seen by a user. It contains almost all of the apps’ business and functional logic. The main goal of the backend is to process and modify data that will be presented to the user through the frontend.

If we take a spreadsheet, for example, the frontend will show its columns, titles, icons, buttons, but it will be the backend that’ll prepare the necessary data for each cell and actions for each button.

However, the frontend and the backend must communicate somehow. This is where API comes in handy. If a user enters some data, it is then sent to the API so that it could send a request to the database to validate it. The answer then gets back to the frontend, and, ultimately, to the user. That’s how the user figures out what they have done and what the outcome was.

API stands for Application Programming Interface, i.e. it’s an interface used to help programs interact with each other, no human is involved in this process.

Let’s show it with an example. Imagine you’ve implemented the authentication feature in your app. The user wants to log in to it. What happens next?

1. The user inputs their credentials on the Login page
2. The front-end part sends requests to the API communicating a message like: “Can I log in with these credentials?”
3. API returns an answer, “yes”, or “no”, based on the validity of the received credentials and the user’s data in the database.
4. API then makes a record in the log file, stating who wanted to log in to the app and when.
5. The backend part sends the API answer to the frontend.
6. Depending on the answer, the user proceeds to the app’s main page or gets a warning/error message.

As a software testing services company, we can list many technical examples, so a simpler analogy here would be a restaurant: when you visit it, you don’t go to the kitchen to see the available ingredients and analyze the cooks’ possibilities and knowledge, you sit in the main room and ask the waiter to bring you the menu. Here, the menu, which is a list of available dishes, serves as a frontend. It might be represented as a printed catalog, as a web page available via the QR code, and/or via the waiter’s voice. The backend is the kitchen. And the waiter represents users’ requests to the kitchen and the kitchen’s responses to the user.

As a bottom line, in most cases, backend testing means API testing, since all other parts of your app’s backend are data storage of some kind (logs, and databases).

Pros and Cons of Backend Testing

Representing another approach to ensuring the quality of your digital product, backend testing brings many advantages.  

First of all, it allows finding bugs and vulnerabilities that can’t be found with any other QA method.

At the same time, you can also test the backend to find and fix frontend issues much earlier. In our QA/testing services company practice, we also had specific cases when we had required functionality already implemented, but the UI was still lacking due to the design department being overloaded with other tasks. So instead of testing this functionality on the frontend, we would test it on the backend.

As you will find out in the section with Postman, backend testing implies writing special tests. You do that once and then can launch them on every iteration, thus saving enormous amounts of time during smoke and regression testing.

Finally, only a properly tested backend lets you be sure your app is secure, protected, and reliable enough.  

The only obvious disadvantage of backend testing is that it might require additional time and resources from the QA department. But in the long run, this point is doubtful since with backend testing you can get the working product faster without compromising on its quality.  

Testing Third-party APIs vs Our APIs

Most of the apps use more than one API. For instance, if you’re building a taxi service, instead of building a map from scratch, you can integrate Google Maps or Bing Maps via their API. The same goes with Stripe and Paypal payments and authentication via your social accounts.

When it comes to testing third-party APIs, it’s obvious we are not responsible for their correct functionality as we don’t have access to the corresponding code and servers.

Thus, our software/QA company’s main goal is to make sure that the app gets the response we expect from such third-party APIs. We do not test bad requests, do not cover possible errors and behaviors, and do not try to reach the “service unavailable” status.

To make sure the responses are correct, we check the validity of the requests the app sends against the requirements from the API documentation.

90% of the third-party APIs we’ve been working with have rich functionality and great documentation listing all the requests we might need to send. Yet if we see that we lack API functionality, we either see if we can make a series of requests to get the data we need or, the project’s timeline allows it, we contact the third-party API developers and see if they could help us and implement the lacking functionality.

Sometimes, third-party APIs have various limitations. For instance, they limit the number of requests you can send per time unit. If you reach the threshold, you’ll need to wait for some time before you’ll be able to send new requests. Thus, QA engineers need to be careful and plan their testing activities when it comes to third-party API.

One last peculiarity of third-party APIs is that they can change over time in a way that will lead to app malfunction. Most often, the API developers change the API logic or the way the request should look. In this case, Postman really helps to quickly find out which our request is wrong and fix it.

In the case of APIs that we develop, we test them inside and out. Unlike with third-party apps, we check not only the responses but also all kinds of mistakes that might appear, object properties, quality of the data, and so on.

Since we have full control over our API, we always can get explanations on its work from the developers and ask them to extend their functionality. And vice versa, if the API gets significantly updated, the developers understand possible consequences and can report about them before the update causes errors and malfunction.

However, if the project we work on is huge and involves multiple teams, API testing and updates should be performed carefully to make sure all teams will be able to keep their velocity if anything goes wrong.

To see the difference, let’s compare it using the next examples.

If we have an Instagram API connected, it provides the next basic request for regular users:

______

GET /{user-id}, GET /{media-id}

______

Since usually, we don’t care about users’ media, API integration requires us only to make sure that the GET /{user-id} is sent properly and gets the expected response in return.

Now, say, we have an API of our own revealing data on store sales. Here’s what we can check with it:

• If the actual number of items sold on day X is equal to the data in the database.
• If the database is stopped, the API should return the “Error 500: Service unavailable” response.
• The current status of the exact shipment.
• If the non-existing userID is sent to the API, the API should return code 404 shown as a “Record is not found in the database” error.  

How the backend is tested at EGO

For backend testing, we use Postman. Initially created for API development, it contains functionality for exploratory and automated testing of existing APIs.

We’ve been using Postman for a few years now. For us, it helps test APIs as it allows sending requests to it, getting responses, and write tests to check those responses.

To test every feature, you create a collection in Postman. In this collection, you create the requests you want to test. For each request, you get a response from the API, so you can write tests to make sure the responses API sends are correct.

As a result, backend testing with Postman allows eliminating many possible mistakes and bugs that would later be found on the frontend.

And the later you find a bug, the more resources you need to fix it. Finding a bug on the frontend might require your developers to dive back into the backend code; once the necessary changes are made, you’ll also need another regression test performed.

However, it’s important to notice that sticking to Postman is not our software tester company’s standard. Our QA experts can use any apps they like as soon as they help them get the work done, we just find Postman the most convenient and handy as of now.

Bottom line

This post was inspired by the internal meeting we had at EGO a couple of weeks ago. On it, we were discussing whether backend testing should become an integral part of every project we take to ensure the top quality of the work we do.

Until this moment, it was optional for the sake of the client’s flexibility. However, the demands for digital products constantly grow. The risks of personal data hijacking are higher than ever, just like the users’ expectations from the apps they install.

So while we’re still discussing this point internally, we definitely recommend adding backend testing to your QA activities if you run a digital project.