Archive - Git RSS Feed

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:

QA PROCESS

  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

HOTFIXES

  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

REFERENCES:

 

Scrum Team Git Workflow

Update my local master
git pull origin master

Create a branch for the story and check it out
git checkout -b storyName

(work, work, commit, commit)

Switch to the master branch
git checkout master

Pull again to fetch and merge any changes
git pull origin master

Merge master into my branch
git checkout storyName
git merge master

Check everything one last time and fix any conflicts

Merge branch into master
git checkout master
git merge storyName

Push the changes upstream
git push origin master

Delete the branch from remote
git push origin --delete storyName

Delete the branch locally using -D instead of -d because it forces a delete
git branch -D storyName

Webhooks, Formstack & Fellowship One