This greatly depends, but if you only start testing in the release branch its way to late. I think QA should be integrated into the development teams and not as an after thought.
I have worked on two teams who used a similar branching flow as the git-flow from Vincent. I will tell you where we do what kind of testing.
Feature branch (before merged into the develop branch)
- Add Unit, Integration and Acceptance/GUI-tests
- Time boxed manual exploratory testing session
Develop / Sprint branch (Feature gets merged here when it meets our Definition of Done)
- Usability testing
- Product owners:
- Plays with the new feature on an automated deployed version
- Shows potential users the new feature on in online demonstration
Release branch (Develop gets merged here once every (1-3) sprint(s))
- User acceptance tests (Deploy to client acceptance environment)
- Manual regression tests (if any)
My current team releases every 3-4 sprints (of 3 weeks long), we also do the following extra testing in a release sprint:
- Performance testing
- Security testing
Master (Release gets merged here, when all bugs have been fixed ;-)
- Manual testing of changes
After a merge to another branch or release we always:
- Re-run all the automated tests, in order to find any integration issues as soon as possible.
- Deploy to a staging environment
If possible you want to-do as much automated testing and use a continuous delivery model and release new features as soon as possible. By which you minimize the ammount of manual testing done.