Git branching strategy integated with testing/QA process

 

Our development team has been using the GitFlow branching strategy and it has been great !

Recently we recruited a couple testers to improve our software quality. The idea is that every feature should be tested/QA by a tester.

In the past, developers work on features on separate feature branches and merge them back to the develop branch when done. The developer will test his work himself on that feature branch. Now with testers, we start asking this Question

On which branch should the tester test new features ?

Obviously, there are two options:

  • on the individual feature branch
  • on the develop branch

    • Testing On Develop Branch

    Initially, we believed this is the sure way to go because:

  • The feature is tested with all other features merged to the develop branch since it's development started.
  • Any conflicts can be detected earlier than later
  • It makes the tester's job easy, he is only dealing with one branch ( develop ) at all time. He doesn't need to ask the developer about which branch is for which feature ( feature branches are personal branches managed exclusively and freely by relevant developers )

    • The biggest problems with this is:

  • The develop branch is polluted with bugs.

    When the tester finds bugs or conflicts, he reports them back to the developer, who fixes the issue on the develop branch (the feature branch were abandoned once merged ), and there could be more fixes required afterward. Multiple subsequence commits or merges (if a branch is recreated off develop branch again for fixing the bugs) makes rolling back the feature from the develop branch very difficult if possible. There are multiple features merging to and being fixed on the develop branch at different times. This creates a big issue when we want to create a release with just some of the features in the develop branch

    • Testing On Feature Branch

    So we thought again and decided we should test features on the feature branches. Before we test, we merge the changes from the develop branch to the feature branch ( catch up with the develop branch ). This is good:

  • You still test the feature with other features in the mainstream
  • Further development ( eg bug fix, resolving conflict ) will not pollute the develop branch;
  • You can easily decide not to release the feature until it is fully tested and approved;

    • However, there are some drawbacks

  • The tester has to do the merging of the code, and if there's any conflict (very likely), he has to ask the developer for help. Our testers specialize in test and are not capable of coding.
  • a feature could be tested without the existence of another new feature. eg Feature A and B are both under test at the same time, the two features are unaware of each other because neither of them has been merged to the develop branch. These means you will have to test against the develop branch again when both of the features are merged to the develop branch anyway. And you have to remember to test this in the future.
  • If Feature A and B are both tested and approved, but when merged a conflict is identified, both of the developers for both features believe it is not his own fault/job because his feature branch past the test. There is an extra overhead in communication, and sometimes whoever resolving the conflict is frustrated.

    • Above is our story. With limited resource, I would like to avoid testing everything everywhere. We are still looking for a better way to cope with this. I would love to hear how other teams handle this kind of situations.

    The way we do it is the following:

    We test on the feature branches after we merge the latest develop branch code on them. The main reason is that we do not want to "pollute" the develop branch code before a feature is accepted. In case a feature would not be accepted after testing but we would like to release other features already merged on develop that would be hell. Develop is a branch from which a release is made and thus should better be in a releasable state. The long version is that we test in many phases. More analytically:

  • Developer creates a feature branch for every new feature.
  • The feature branch is (automatically) deployed on our TEST environment with every commit for the developer to test.
  • When the developer is done with deployment and the feature is ready to be tested he merges the develop branch on the feature branch and deploys the feature branch that contains all the latest develop changes on TEST.
  • The tester tests on TEST. When he is done he "accepts" the story and merges the feature branch on develop. Since the developer had previously merged the develop branch on feature we normally don't expect too many conflicts. However, if that's the case the developer can help. This is a tricky step, I think the best way to avoid it is to keep features as small/specific as possible. Different features have to be eventually merged, one way or another. Of course the size of the team plays a role on this step's complexity.
  • The develop branch is also (automatically) deployed on TEST. We have a policy that even though the features branch builds can fail the develop branch should never fail.
  • Once we have reached a feature freeze we create a release from develop. This is automatically deployed on STAGING. Extensive end to end tests take place on there before the production deployment. (ok maybe I exaggerate a bit they are not very extensive but I think they should be). Ideally beta testers/colleagues ie real users should test there.

    • What do you think of this approach?

    Before test, we merge the changes from the develop branch to the feature branch

    No. Don't, especially if 'we' is the QA tester. Merging would involve resolving potential conflicts, which is best done by developers (they know their code), and not by QA tester (who should proceed to test as quickly as possible).

    Make the developer do a rebase of his/her feature branch on top of devel , and push that feature branch (which has been validated by the developer as compiling and working on top of the most recent devel branch state).
    That allows for:

  • a very simple integration on the feature branch (trivial fast-forward merge).
  • or, as recommended by Aspasia below in the comments, a pull request (GitHub) or merge request (GitLab): the maintainer does a merge between the feature PR/MR branch and develop , but only if not conflict are detected by GitHub/GitLab.

    • Each time the tester detects bug, he/she will report it to the developer and delete the current feature branch.
    The developer can:

  • fix the bug
  • rebase on top of a recently fetched develop branch (again, to be sure that his/her code works in integration with other validated features)
  • push the feature branch.

    • General idea: make sure the merge/integration part is done by the developer, leaving the testing to the QA.

    The best approach is continuous integration, where the general idea is to merge the feature branches into the developer branch as frequently as possible. This reduces on the overhead of merging pains.

    Rely on automated tests as much as possible, and have builds automatically kick off with unit tests by Jenkins. Have the developers do all the work with merging their changes into the main branch and provide unit tests for all their code.

    The testers/QA can take participate in code reviews, check off on unit tests and write automated integration tests to be added to the regression suite as features are completed.

    For more info check out this link.

    链接地址: http://www.djcxy.com/p/48940.html

    上一篇: Android Studio更新项目：合并与重建vs分支默认

    下一篇: Git分支策略与测试/质量保证过程相结合