I and the rest of our QA department have only tested applications. We’re good at that. Now our company is moving in a new direction and we’ve been asked to get ready to test a brand new backend. Great, except that we don’t know how to do that. Where should I look to start educating myself? Any tips?
The first thought I had was to ask the devs to make us a frontend for testing the backend, but (1) the API isn’t defined well enough for that, and (2) the poor devs are far too busy to help with that.
Apologies for the vague question; things are pretty up in the air. I’m trying to learn what I can before things become clear because when they do it will be go time.
One factor here is the technologies that you are using.
In the .NET world I have used Swagger to act as a way to access the backend via endpoints.
It comes with very little development effort required.
I think the best place to start would be to speak with the team to understand/discuss what ‘backend’ thing they might be building.
Not wanting to teach you to suck eggs (sorry if I am) but theres lots you can do without exploring an actual built thing.
Are there requirements, designs etc you could look at, ask questions about, give feedback on etc.
If you know for example they will eventually have an API, even if its not built do you know what some of the requests/responses might be? Id so, there are lots of tools out there where you could mock the API enabling you to start exploring before an actual thing is built. Postman is a cool free tool for this.
If the API isn’t yet defined well then you can start teaming with the devs and work on definition and documenting of the API. You can prevent a lot of issues at this point - for example, having a clear definition of all error scenarios with expected responses is crucial.
What kind of an API is it, btw? REST?
Other than that, you don’t need a frontend to start exploring the API. Postman is a pretty sweet tool for that. Look up Valentin Despa on Youtube, he has awesome beginner-friendly videos.
I totally agree. It might be ideal to ask the team or set up a meeting to see what backend things are needed(regression, functional, unit, load testing, performance, accessibility).
I would start with Postman. It’s great for exploring APIs and they have a learning center with a lot of decent resources (Introduction | Postman Learning Center ) including some tutorials using public APIs to give you an intro to API testing.
Beyond that, my biggest piece of advice is to treat the documentation and the return messages as a UI and use the techniques you are used to.
Namely things like:
Identify what the end user would be trying to accomplish, what flows are they doing? (Then id what the API supports within those flows)
Do you have enough information in the documentation to complete a flow?
When you trigger an error message, do you have enough information to fix the issue?
What are the negative cases from a user flow point of view?
What are the negative cases from a Input-State for individual API endpoints pov?
