Reducing dependencies between stories & which branch (GIT) should QA's test on?

Question

Background

We have a team of 8 devs and 1 QA (tester) and we're struggling with dependencies between tickets and causing a lot of merge headaches and/or people waiting around for the next bit of work to pick up.

Our current GIT flow model (branches):

Release 
 |  > Epic (Feature Branch) 
 |     |  > Ticket : This is where the dev does their work and QA test on
 |     |     |       then we move to the epic branch once passed. 

Our company creates api's using web api (.Net, C#) we also have an Anuglar site and old admin site in MVC using mostly jquery.

Issues

On a lot of recent project's we had to create api's for insert, update, delete, and get. We usually code the "insert" ticket first and make the other tickets dependent on that one, because of things like the coding the controller, Db tables and class's which the other api's will need/use.

But then, the "update" will need to check to see if what is being updated exists in the DB. So it is dependent on the "get" so that we end up with 3 layers of branching.

...
 |   > Insert
 |      |  > Update 
 |      |     |   >   Get. 

This can get a lot worse when there are more epics involved. This causes a lot of merging issues, or confusion for QA's and dev's on which branches they need.

How do people cut down on this? Pair programming? Create empty stub methods?

A big issue we have is the lack of QA resource as we're struggling to hire people. A lot of tickets just stack up in the QA pile causing to keep fixing conflicts in the ticket branches.

I was thinking of create an new git flow:

Release 
 |   > Epic (Feature Branch) 
 |      |    > Epic (Dev)
 |      |       |   > Ticket

So with this new Epic (Dev) branch, once the ticket has been coded, we merge in straight into this branch and then the QA's test of that branch and once passed we move it into the Epic (Feature Branch).

Expected Benefits:

• QA don't have to keep switching branches
• Can test full flows instead of just the individual tickets.

Can this, as I hope, result in less conflicts? Does anyone think this is better then our current setup? Does anyone have any better suggestions?

Note: At the moment we can't have a qa test environment (this is out of my control)

Answer 1

The rule for quick and easy merges is: Get your changes into the master branch as quickly as possible.

Things that don't help

• having tons of long-lived branches
• branching branches off feature branches
• requiring extensive QA work before a change may be merged

Things that do help

• having devs regularly talk to each other so that they avoid making conflicting changes
• decomposing work into small items that can be completed within at most a few days
• having a team collaborate on as few concurrent tasks as possible
• merging small changes as soon as they won't break existing functionality
• feature toggles to disable incomplete features
• protecting merges into the master branch primarily through automated tests, not manual QA
• involving QA early in the work on a feature
• focusing manual QA work before a feature toggle is removed or switched to “on” by default

Why branching off another branch is problematic

To keep a long-lived feature branch up to date, you will usually want to merge master into that feature branch. Most of the time, this will be done by rebasing the feature. But subfeature branches will now be out of sync with their base feature and would have to be merged as well. This can amplify the merging effort, especially since rebasing the feature will make a simple merge in the subfeature impossible. But if we don't merge frequently, we get a difficult merge at the end when the feature and subfeature are merged into master.

On Continuous Integration

Many of my above recommendations are a part of Continuous Integration: merging stuff early, testing stuff automatically, not making merges into a big deal. That does mean that bad code can make it into the master branch. But it also means that problems can be detected and fixed early, before they require unreasonable effort. This does work best in collaborative teams that work together, not merely alongside each other.

CI does benefit from an automated test suite that runs independently on some server. Even a basic integration test suite can be quite valuable. If QA can record important tests via Selenium, that gives a lot of test coverage for comparably little effort. I know it can be difficult to set up a test environment. As a stopgap measure, it can be easier to get started by running CI on a developer's machine (e.g. I used to run a Jenkins instance on my PC until we could get a separate server set up).

What this means for QA

It is great that you have a dedicated QA person on board. But if they have to sign off on every merge, they can easily become a bottleneck for your development process. (Consider tracking the flow of work items through your process, e.g. with a Kanban board). In particular, it can be problematic if a feature must be fully tested before it can be used by other developers, since that increases merge conflicts. That can also be wasted effort since the feature should already work.

As suggested above, it might make more sense to have them do acceptance testing when a feature is ready to be activated by default (even if its code might have been merged earlier). It can also make sense to involve QA earlier, especially when analyzing requirements. It can also be helpful if devs can ask QA for ad-hoc advice without going through a formal QA cycle, especially if devs have a question about UX issues.

Outlook: lots of helpful stuff ahead

You have identified a problem with your process (the branching model) and are trying to improve it. That is great! Continuous improvement or Kaizen is a core part of many successful development models or process frameworks. There is a lot of helpful material out there that can help you along the way. In particular, the agile-ish space has explored some very useful things (such as continuous integration). Two thoughts which might be helpful in the medium term:

• Kanban is very good at visualizing the flow of work items through your process and detecting bottlenecks that slow everything down. Kanban is probably not the best choice for you as a process, but reading more about it might be very helpful (in particular, the advice to limit WIP items at each stage of your process).

• BDD contains some fascinating insights about the relationship between requirements, work items, and tests. In particular, BDD answers the question how you can get started with writing tests: express requirements as examples, let the tests run the examples, and implement one example scenario at a time. In turn, tests allow you to do CI, which allows QA to focus on more valuable activities than signing off on every change, which gets rid of an impediment in your process. While jumping straight to BDD might be too much, starting to express requirements as examples might help you to have smallish work items that can be merged easily.

Answer 2

First take what Amon said.

Next, if you think your “insert” branch is fine, you want it tested before merging obviously, but you want to continue work without waiting:

You can branch “update” from the “insert” branch that you know it needs. As soon as “insert” is merged into its parent branch, you merge the parent branch into your “update” branch, and it’s the same as if you had branched from the parent branch directly. Just keep careful notes of what you are doing and don’t let it go too far.

If “insert” needed changes before merging into parent, you get these changes when merging parent into “update”.