Do you believe in QA who only tests the application as a user i.e just blackbox testing of clicking here and there.?
The QAs in my company doesn't have a clue on how the shit works and most of them don't even understand a line of code.
I feel that it's really important to test the application from the web api level as well to test out all the complex business logics which may not be feasible from the UI.

If they are testing as a user then they can identify issues early that will impact specific users, permission levels and determine the GUI or frontend is behaving correctly.

Automated testing will not spot this without an abundance of time being put in place to work through the many scenarios and continuous changes being made needed to keep this up to date.

Also, no they shouldn't be blindly clicking.

@C0D4. Ours is a mobile application wherein most of the logic is implemented in the server side.
In most cases the client is a dumb presenter of the data. Our business logics are in server side.

@BlueSky for that then blindly tapping a screen may be all they need to do if it's cross platform / device.

@C0D4 But who make sure that all of business logics are covered and shit doesn't break( which do most of the time) when someone decides to update one microservice amongst the hundreds.
My point is that nobody writes integration tests from the web api layer.

@BlueSky if business logic is backend / api, then unit tests and integration tests should be added.

Web API's will always have an expected input and output for different scenarios, you could build out your tests using BDD so that business cases are covered as part of it.

You won't need a QA for that unless they are automation testers as well.

If their tests are covering all the flows, then yes, it's enough. A user is not going to just bypass gui and make up new flows that could fail.

Security is a different story. I wouldn't trust qa to test security anyway

@netikras They only covers the simple straightforward flows.

Depends on QA is working with you, usually, the QA's that worked with me they test all the possible scenario, they spend whole morning testing and in the afternoon they create a report to delivery in the end of the day and depends of level of the bug enter in the queue to be fixed next week or start the fix in the next day.

Ehmmm... Automation ?
The manual testers should be performing very specific tests, the main bulk should be automated and run in the CI/CD.

@funkypie Do we seperate manual QA in this age?. Can't we get well qualified testers who can code as well as test.

@BlueSky You can, they're just much more expensive than people who just click around. Also, would you do me a favor and just call these people you work with testers and not QA? It's slightly insulting towards any of us who put time and effort into actually mastering our craft.

@Godisalie That is exactly my point. Since those clickers are the majority many considers QA as just a bunch of random clickers.

@BlueSky You should just pressure your company to hire some QA engineers or software engineers in test. QA as a role has sadly been tainted nowadays and comes down to who at best have a very basic idea of technology. I personally blame the ISTQB but that's an entirely different battle. Also voice your concerns, loudly. Before I started at my current company a broken live build once or twice a week has been the norm so the higher ups got kind of numb regarding this problem.

Might seem like an asshole move to constantly nag about a department but it might be necessary just to make people aware that there even is a problem. Ceterum censeo is sometimes the only way to create that awareness.

If all of that fails, plan the task for your team. Explain that you have no trust into your builds and that you need API tests as a safety net. Let your bosses make the decision if they want to waste valuable dev time for something your QA should already be doing.

@Godisalie Yes. We started doing that already. We currently have a bunch of SDET. But there are legacy so called 'testers' in the company who is involved in feature development.

Usually, testing is done as bottom-up strategy. For the product to be robust, much more tests than just user tests are required, but it will also cost much more money.

For example, what happens when connections are lost, some service restarts, the server is being updated while some user is doing something, are fault codes properly implemented AND handled on both ends, do both sides handle timeouts correctly, what happens when after timeout, the data do suddenly arrive, these kinds of things.