We don’t have QA testers and I don’t think this is really necessary (which you seem to suggest).
In my team, we love testing because that makes us sleep better after shipping code to production.
To fight the confirmation bias, we do code reviews (which is OKish,
But not optimal) but much better, we do pair programming whenever possible (in that case, we don’t do code reviews). This really makes you develop differently. Usually, while pairing, you won’t write code that “will hopefully be OK” because of the peer pressure. You will write more and better tests.
I do think pair programming is a help on the journey. I've worked with all forms of QA from mine to a dedicated and very involved department that did Tom's of exploratory testing as well as feature and bug testing. I've seen good dev testers and bad ones as well as awesome and awful QA. Every team's needs are different.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
We don’t have QA testers and I don’t think this is really necessary (which you seem to suggest).
In my team, we love testing because that makes us sleep better after shipping code to production.
To fight the confirmation bias, we do code reviews (which is OKish,
But not optimal) but much better, we do pair programming whenever possible (in that case, we don’t do code reviews). This really makes you develop differently. Usually, while pairing, you won’t write code that “will hopefully be OK” because of the peer pressure. You will write more and better tests.
I do think pair programming is a help on the journey. I've worked with all forms of QA from mine to a dedicated and very involved department that did Tom's of exploratory testing as well as feature and bug testing. I've seen good dev testers and bad ones as well as awesome and awful QA. Every team's needs are different.