3

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.

Improve this question
3
  • 1
    Related: softwareengineering.stackexchange.com/questions/290026/…
    – Doc Brown
    Dec 20, 2017 at 6:43
  • Your problem isn't how to change what QA is doing, it's how to convince the powers that be to get you a different manager.
    – Bryan Oakley
    Dec 20, 2017 at 13:22
  • @BryanOakley Agreed. I'm trying to compile research to back up my argument that our current workflow is producing results and that other teams should look at what we're doing rather than applying their process on us for the sake of consistency across teams.
    – Brian
    Dec 20, 2017 at 14:24

1 Answer 1

Reset to default
2

Doing manual testing and fixing automated tests in the trunk has a big downside, possibly you have a broken main branch or lots of broken tests. Now you cannot use this as a base for a new feature branches. I think the main branch should always be 100% green. Depending on how fast you can fix or revert this merge it could block other features/teams for a while.

As Tester, I really like writing all the tests in the feature branch. Our teams use feature branches, in which we also develop and update all the tests (e.g. unit, integration and functional end-to-end). This makes the feature complete and testing not an afterthought.

We run exploratory testing on a staging branch. We pull trunk/master and the feature we want to test into this branch. Deploy it to a staging environment, run all automated tests and execute a timeboxed exploratory testing session. If this is successful we merge the feature branch into the main branch and rerun all the automated tests again before it gets deployed.

Don't fall in the trap of mini-waterfalls. Swarm features and tests in parallel of writing code.

If you have lower defect leakage rates than other teams, I think your processes bright-spots should be duplicated into other teams instead of the other way around.

Improve this answer
2
  • That's very good insight. I felt like we were on the right track pragmatically but its nice to get feedback from others reaffirming it. Currently we do not have deploy processes for feature branches. We deploy from our trunk branch via MS Release Management to a CI environment, which when passed gets promoted to a PO environment. When we've reached our goal feature set for a release, it is then promoted from PO to our external QA team for black box testing.
    – Brian
    Dec 20, 2017 at 14:41
  • 1
    Agreed. Nothing goes into master until it is believed production ready. All feature branch tests are written and pass in your branch. Before a feature merge to master, the master branch latest gets pulled into your branch and you verify that ALL tests still pass -- your new tests and all pre-existing. Then you can merge to master. We have 1 API and ~ 10 different teams contributing. Takes coordination among the teams, but has proven itself. Last I saw, upwards of 4,500 tests -- which almost always pass in master (occasional hiccups are unavoidable, but the process has worked for 5 years).
    – railsdog
    Dec 21, 2017 at 5:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.