> Though, to be honest, it is QA who is testing it, not us developers.

Developers absolutely should be testing for the issues they know about. QA is there to look for unknown issues.

Any company that depends on QA for testing and doesn’t make devs to it is miserable to work for (both as a dev and a QA).

Not where I work. QA are the ones who first look at all reported issues. They see if they can replicate the reported issue. If they can’t they contact the reporter and try to figure out why they can’t replicate it. Once they can replicate it they write up the ticket with replication steps and add it to the backlog to be assigned out in a sprint. They attend all meetings and explain the issues. Once the developer thinks they have fixed the issue they send it back to QA to verify it is fixed. Then QA reaches out to the person that reported the issue to tell the about the resolution.

That’s not testing, that’s triage. If you don’t bother writing unit tests yourself as a developer when you fix the tickets, then that’s the problem I’m referring to.

Have you ever sent the issue back to QA as fixed, and then they do their reproducer and it’s not fixed? That’s roughly the scenario we’re asking you to have empathy toward.

For QA to test tell if it's fixed, they must have a test case. If there is a test case here, the devs wouldn't have to guess?

The bug reproduction steps (along with expected vs actual behaviour) are in the opening comment of the bug report, so they really should not have had to guess.

See my response to kortilla above.

QA is not your test suite. Test your own code, submit working code, let QA try to break it.

Dont just push code and expect others to point out your flaws. Take some responsibility.

See my response to kortilla above.