I agree, the best testing process I've experienced still had people whose role was QA, but that was because they were considered experts and would lead the direction of QA and do final acceptance testing before a release.
The process we used was the three amigos process, where the ticket dev, BA and a QA would have a 20-30 minute sit down and draw up a mind map of test cases linked to the acceptance criteria.
Once the mind map was created, anyone technical could pick up the actual writing of the tests/exploratory testing, whether that's the original dev, a QA, or any other dev. Because devs were all testing each other's tickets instead of just hoofing them over the fence to QA I found that I got a much better understanding of the different areas of the projects.
Only downside was it required a lot of meetings to really flesh out the tickets and make the acceptance criteria as detailed as possible.
The process we used was the three amigos process, where the ticket dev, BA and a QA would have a 20-30 minute sit down and draw up a mind map of test cases linked to the acceptance criteria.
Once the mind map was created, anyone technical could pick up the actual writing of the tests/exploratory testing, whether that's the original dev, a QA, or any other dev. Because devs were all testing each other's tickets instead of just hoofing them over the fence to QA I found that I got a much better understanding of the different areas of the projects.
Only downside was it required a lot of meetings to really flesh out the tickets and make the acceptance criteria as detailed as possible.