Tips and Tricks... what can I learn from you in backend testing

🗄️ Archive
1

Hi all,

I’m new in this field of testing backend applications.

My first seven years of QA here dedicated testing applications based in Java Gui configuring HW equipment or testing the HW reacting to some external stimulus. Another part of that time was testing C GUI for network planning.

Now I embraced a new challenge, although the working methodology doesn’t change a lot, the technology and testing boundaries changed a lot.

From GUI to no-GUI interfaces

I’m now debating myself with testing API, DB, REST, KAFKA topics…a tech stack quite different.

I’ve some question to all of you (and I’m asking for help :slight_smile: )

The last stories that I’ve been testing it’s been quite stressful and not so many free time to implement a framework for autonomous testing.

But first I will try to explain more or less the application that I’m testing.

The is a box that receives triggers from REST API and that is reading Kafka Topics. It is mainly triggered with REST API Call and complements it with information from Kafka Topic (this part is async)

The results will be a call to an external application (and normally before the call is made, all information is gathered in a DB - SQL Server )

Today I’m using Postman (or Swagger) to perform REST API calls to my application. SQL Server to connect to DB and verify that information is correct. And browser to the external application to see if the post is correctly made by mine application.

What tips can you give me, or teach me?

I was trying to implement an automation framework based on NodeJS, and like probably this backend application will get a “back office” UI, I’m investing some time in Cypress. But for now, I’m only looking to NodeJS, Cucumber (Gherkin) and all the library that NodeJS provides.

Thanks in advance!

PS. I’ve been reading many topics that I can in the ministry of testing club, and getting inspired. But question a more focus problem may help me better :slight_smile:

1 Like
2

Hi David,
I’m not sure if this is your case, but I would consider to put all the activities in a CI env., e.g. Jenkins.
I got similar SUT and created pipelines which can run Postman tests (via newman) in first step, then I can perform SQL queries in next step and at the end I’m running Robot Framework. All together triggered by changes from GIT.
Or, you are looking for something else perhaps… :thinking:

Michal

3

Hi Michal,

First of all, thanks for your answer.

Second, sorry for my delay :slight_smile:

In the company, we have already a CI/CD Pipeline, e.g. Jenkins 2.0 if I’m not wrong, although I don’t think they are ready for running Postman tests (is a very tight system :stuck_out_tongue: , complex and so on… :no_mouth:

I really didn’t spend enough time with Postman Test, I’ve to put that on my list and spend some time.

I can use that test workflow. I can trigger an action in my application, then check if the application DB is ok and after that visit the external application to check if the post was correct.

But, do you think that checking DB is really important?

In my case, I can check if the DB is OK by the only check if the post in the external application was correct since is a copy paste of that DB line.

Maybe check DB is redundant and only putting more time to test.

Cheers

4

Hello David!

I like your approach so far - I think you are correct in saying the working methodology doesn’t change a lot. With that in mind, I think you can complete a lot of testing before considering automation. In my opinion, Postman is capable of exercising your API and can be used to experiment with some domain-type testing.

There are a couple of levels to review in an API: a response to a specific request (behavioral), and functionality within the API (logic, database interaction, subsequent API calls). The functionality within the API should be evaluated through unit tests. Typically, these are written and maintained by the development team. If these are available, then I would agree that your explorations into the database may be redundant.
The behavioral aspect warrants exploration with respect to responses to odd data, incomplete data, errors in data in the request. For example, if the API expect numbers in a field, what happens when you send it letters? Another area I like to explore is errors in the API response. These can be created, most times, through Postman. Errors I have seen in an API response include HTTP 400 and 500 errors.

In my opinion, all of this is possible with Postman. While I have not explored it, there is some test case management within Postman that may be beneficial. I think @skuco has some good thoughts as well.

Lastly, by building a suite of Postman tests, you are building your regression suite. It can execute quickly and provide feedback on the APIs with every check in if necessary! Accurate and timely feedback is the cornerstone of testing!

Joe

5

Hi!

Thanks for the reply… and sorry (again) for my late response…

Nowadays I’m using Postman to perform must of my test… only in a manual way. Next Steps: look at testing “automation” from Postman - test scripts and runner.

But, there is always a but… The application that I’m testing now, can receive “event triggers” from REST but the response is normally a pure API Response Code. In this process, the application is saving the request in a DB and wait for a Kafka Topic to complete the action…and the output is normally a request to other application.

You said, “functionality within the API (logic, database interaction, subsequent API calls)”, this is all being done with UNIT and Integration Test (using Mocks) developed by the dev team.

The must enrichment experience, and feedback that I can give is sent API request and look at the response in the other side… but I’m not having any ideas to do this. :frowning: Today I’m sending a request to API and then I go to the sandbox of the other application and check the POST that was made (the JSON)

Thanks for all the sharing and response!

Cheers