I have searched and found a few questions talking about testing in relation to feature branching. My question is a little different.
We are a scrum* team of 4 to 5 developers with a dedicated on-team QC. We do active development on a family of applications with large amounts of legacy code. The application family includes a web portal and also a server side applications running jobs, etc.
Over the last couple of years we've been slowly improving the product with new features and improved architecture and practices. Things such as code that was never written with unit testing in mind or in practice, moving webforms to mvc/webapi, winforms to wpf and such.
During that time the QC has developed an automated testing suite for the website so, when we end a sprint cycle and preparing for a release to a separate QA group for black box testing, we didn't have to take a couple of days with a spreadsheet to test each supported browser for defects before our drop to QA. The automated tests are run on each change to the trunk branch and passes/failures are displayed on monitor for our team to see, TFS emails are sent to the team upon a failure too.
We use feature branching with the QC testing and correcting/developing new automated tests in the feature branch on their local machine, similar to the developers who write the code and test their own work. Then the feature gets merged up to our trunk once our QC accepts the new feature.
Since adopting feature branching and keeping the trunk as releasable code, we have seen a dramatic reduction in bugs returned to us from QA or from production.
Now our direct manager wants to change our process in order to be consistent with other development teams. (which have higher rates of QA failures and production issues I have to say)
The manager wants the on-team QC to no longer test and correct on their local machine but rather, once the developer completes their work and it is code reviewed by a peer, it will be merged to the trunk where the QC will test in the integration environment, correct their automated tests, or develop new automated tests for new features.
Since this was mentioned by the manager I have been trying to research around to see how development teams outside our company approach testing. My thoughts on the subject has been that the QC should test and develop in feature branches then let the automated tests and unit tests ensure no regressions occur when feature branches are merged into the trunk branch.
*I use the term 'scrum' with some hesitation due to changes in the company slowly and quietly backing away from scrum and agile practices but that's a discussion for another day and thread.