QA Process Based On Gitflow

I have been avidly researching the QA process of other scrum teams and I found there to be a general lack of information regarding specific process steps.  This is likely because scrum teams vary widely in the tools they use and the processes they employ to deliver their commitments.  I have been tasked with establishing solid QA process and procedure for our scrum team.  Our team operates on a 2 week sprint cycle and we also release working software every 2 weeks.  I am a strong believer that the responsibility for quality lies on the whole team, not just on the person designated in the testing role.  Having said that, there are definitely predictable patterns and practices that QA can engage in to serve the team and the organization well.  Some of the tools we use are Jira, Git, Bamboo, Jenkins, RobotFramework and TestRail.  Here’s an outline of the QA process we utilize with these tools, based on the Gitflow branching and merging strategy:


  1. Developer creates a Feature branch from the Develop branch
    1. Jira status: Dev in Progress
    2. Jira ticket number used as the branch name
    3. Coding begins
  2. Developer completes story and requests a code review
    1. Developer merges Develop branch into Feature branch (in case of changes on Develop branch)
    2. Developer creates pull request to merge Feature branch into Develop branch
    3. Jira status: Code Review
    4. Peer reviews code using Github review tools
    5. Changes are made if necessary, step 2 starts over
    6. When all changes are complete, code review is approved
    7. Jira Status: Ready for QA
  3. QA deploys Feature branch to QA Environment
    1. Jira Status: QA in Progress
    2. Test plan is document in TestRail and test cases are linked to Jira ticket
    3. Automated test cases are written (this can begin earlier in the process based on the acceptance criteria)
    4. Tests are executed – functional, manual, automated
    5. Automated results are pushed from RobotFramework to TestRail and to Jira via API’s
    6. If issues are uncovered, a Jira ticket is created per issue.
    7. Issues are addressed on the feature branch and step 2 and 3 begins again.
  4. QA merges Feature branch into Develop Branch
    1. When all issues are addressed and QA approves changes, feature branch is merged into develop branch (Use –no-ff flag to create a new commit object and group together commits by feature)
    2. If there are merge conflicts, QA works with Dev to resolve
    3. Jira status: QA Complete
  5. Repeat all of the above until EOD second Wednesday of Sprint
    1. Full automation suite is executed numerous times during this process
  6. QA creates a release branch on all repos to be released
    1. Naming convention: release-##.##
    2. Develop branch is merged into release branch
  7. QA Deploys Release branch to Staging for all applications in the release
    1. Merges into Develop end (feature freeze)
    2. Regression/automation and thorough testing as a whole occurs
    3. Jira status: On Staging
  8. Product owner reviews sprint items on Staging and approves release
    1. Product team marks stories “Product Approved” in Jira for those that are approved
    2. Items not approved need to be removed from the develop branch and carried over to the next sprint
    3. Product team communicates release to internal team members
  9. Release branch is merged into Master on all repos
    1. QA opens pull requests to merge release branch into master
    2. QA works with Dev on any merge conflicts
  10. Master is built and deployed to QA
    1. Smoke tests run against QA
    2. QA verifies that everything is set for release
  11. Release Candidate is built
    1. Repos are tagged with release version
    2. Release Candidate is deployed to QA, and Staging
  12. IT deploys Release Candidate to Production according to agreed upon schedule
    1. Jira status: Done
    2. Release complete
  13. QA and/or Dev merge Master into Develop
    1. Master and Develop should be even
    2. Changes to Automation framework that need to wait until after the Production release are pushed to master


  1. Developer creates hot fix branch from Master
    1. Jira status: Dev in Progress
    2. Naming convention: hotfix-*
  2. QA deploys the hotfix branch to QA env
    1. Jira status: QA in progress
    2. Fix tested and approved
  3. QA merges hotfix branch to Master and Develop
    1. Jira status: QA complete
    2. Release is tagged on Master
    3. Naming convention: release-##.##
  4. QA deploys Master to Staging
    1. Automation executed
    2. Change request created for deployment to Production
  5. IT deploy fix to Production
    1. Hotfix release complete



3 Responses to “QA Process Based On Gitflow”

  1. Steve Potter April 2, 2016 at 4:49 pm #

    This is super, thanks for sharing. I’ve also been researching this topic and haven’t found anything that lays out the process so precisely as this. Thanks again!

  2. Long September 26, 2018 at 1:12 am #

    Thanks for great post.

    Still, there is one point left to define is what if we have multiple QA engineers working on multiple features at the same time. Isn’t it would need several QA environment setup for each feature?

  3. Roee April 12, 2020 at 1:26 pm #

    Could you please elaborate on bullet-point 8:
    – if product owner doesn’t approve the item, it means you remove it from develop (how? revert commit?), then merge develop into the release branch and repeat tests?
    – reason why product owner will choose not to approve an item when its in Staging?
    – to mark an item as Product Approved, you use simple tag or something else?

Leave a Reply:

Gravatar Image