You can start by fixing 90% of the non-UI bugs by using (a static type flavour) TypeScript and linters.
In the last few years many UI frameworks appeared like cypress that could replace some manual QA work.
Usually the devs are not great at QA, especially if they test their own work. It's the opposite to the development paradigm they are used to, so I would fix it by hiring a few QA testers.
Admittedly devs do have tunnel vision and miss some scenarios that should be tested, especially when they are inexperienced, but you can and should catch those with code reviews and teach developers to get better at testing.
I suggest devs to play games and meanwhile look for bugs (and why not report them in game forums and help other devs). Games are eventually software and this would widen the tunnel vision from a very different persepctive in a not-boring way.
hiring dedicated QAs changes processes in the team to “I handed it over to qa” “qa should take a look” “qa found a bug” this draws a kind of boundary between developer and her code attributes, such as security, stability etc. Users found a bug on production - “oh its not MY fault, qa should have checked it!” Presence of a “quality” person lifts off responsibility of assuring quality by yourself. On the other hand, developer is the person who knows the best where to look for bug in the code, so why not invest into better culture and skill of “putting on qa hat”?
My best experience was in a team with no desicated QAs - fastest shipping to production, short loop, CI pipelines and almost CD - we still had a button to push, but it was more like a ritual or a leftover from previuos proceses )
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.
You can start by fixing 90% of the non-UI bugs by using (a static type flavour) TypeScript and linters.
In the last few years many UI frameworks appeared like cypress that could replace some manual QA work.
Usually the devs are not great at QA, especially if they test their own work. It's the opposite to the development paradigm they are used to, so I would fix it by hiring a few QA testers.
Admittedly devs do have tunnel vision and miss some scenarios that should be tested, especially when they are inexperienced, but you can and should catch those with code reviews and teach developers to get better at testing.
I suggest devs to play games and meanwhile look for bugs (and why not report them in game forums and help other devs). Games are eventually software and this would widen the tunnel vision from a very different persepctive in a not-boring way.
hiring dedicated QAs changes processes in the team to “I handed it over to qa” “qa should take a look” “qa found a bug” this draws a kind of boundary between developer and her code attributes, such as security, stability etc. Users found a bug on production - “oh its not MY fault, qa should have checked it!” Presence of a “quality” person lifts off responsibility of assuring quality by yourself. On the other hand, developer is the person who knows the best where to look for bug in the code, so why not invest into better culture and skill of “putting on qa hat”?
My best experience was in a team with no desicated QAs - fastest shipping to production, short loop, CI pipelines and almost CD - we still had a button to push, but it was more like a ritual or a leftover from previuos proceses )