I've been a QA Automation Engineer for 15 years. This is the best thread ever on HN! I've read every single comment.
I've found the best approach is for QAs to be embedded right into the product team - where the product team manager is the same person for both Dev and QA. QA and Dev all review each others code. QA reviews the Dev unit tests, and Devs review the QA integration tests (API and UI). QA may not be able to provide in-depth reviews on dev code, but at least they can double check that unit test coverage is adequate.
As for UI automation, one point of friction that often happens is that QAs want unique IDs on each UI element. If the devs fail to provide those unique IDs, then QAs are often forced to do some convoluted workaround. However, there is a better option where QAs simply add the unique IDs themselves and request a code review from the dev. This works well because the change to developer code is benign and QA is not slowed down.
Thank you for your comment (useful and interesting information).
So it looks like your suggestion is to have 2 types of engineers in the team, where at least one of them is focused on QA + encourage bi-directional code reviews.
Could you tell a bit about the involvement of PMs in the QA process from your experience? What's working and what isn't?
The PM is busy doing their own job (writing new stories, managing old stories, talking to clients, etc). They typically only do a superficial amount of testing on new features (and usually only on their pet-features). The vast majority of testing comes from QA and Dev.
Having QAs that technical would be amazing. Most of the time I find that anything more complex than basic JSON editing is the limit of their technical abilities.
Another QA/Automation engineer here - keep looking, we definitely exist! I was a dev but prefer QA, and still enjoy doing code reviews for the devs as well. Also helps to identify missing unit tests and consider what tests I'll be building if I've missed some too.
I've found the best approach is for QAs to be embedded right into the product team - where the product team manager is the same person for both Dev and QA. QA and Dev all review each others code. QA reviews the Dev unit tests, and Devs review the QA integration tests (API and UI). QA may not be able to provide in-depth reviews on dev code, but at least they can double check that unit test coverage is adequate.
As for UI automation, one point of friction that often happens is that QAs want unique IDs on each UI element. If the devs fail to provide those unique IDs, then QAs are often forced to do some convoluted workaround. However, there is a better option where QAs simply add the unique IDs themselves and request a code review from the dev. This works well because the change to developer code is benign and QA is not slowed down.