Great question. I don't think there is an 'official' correct answer to this. It depends on how fast you can test.
The essential problem is that each merge, compilation or even deployment, can potentially create a bug. The further 'up' the chain you test, the sooner you know about bugs, but also the more times you have to re-test.
In order to be assured that you have tested the software the customers are using you really have to test the live deployment before the customers traffic (assuming a web app) is routed to those servers via a blue/green deployment pattern.
But obviously this is a bit late in the day to be the first time you checked the code at all!
If you test a release branch in a qa env then you can take the risk and reduce the live testing to smoke tests only. and apply bug fixes to the release branch. But you cant assess whether a feature is complete before creating a release
If you test development then you get mini bug-fix-feature branches. Features are still merged before they are assessed, plus features for the next release can collide with testing the current release.
If you test Feature branches you need a million environments and have to orchestrate the order of merges and test sign offs. plus a lot of retesting.
From my experience I would recommend:
quick test of feature branch on dev machine. just ensure its feature complete and the testers/devs agree on what the requirements mean.
Day to day testing/automated testing on dev branch deployed to qa servers. Lets you test all the features together and say when you are ready to release.
If all the features are in but testing isnt finished. eg the sprint is complete. make a release branch and deploy to a second qa environment. This allows for bug fixing/testing on release 1 to continue at the same time as features for release 2.
(scrum devotees will say you should put only bug fixes into sprint 2 but lets be practical)
Smoke tests on live green/blue deployment before switch over. These are super important as you will pick up config/environmental errors that no-one really looks for while developing.