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:

 

Bug Report Example

Reporting bugs found during the software development lifecycle in a clear and concise way is critical to fast, in-cycle resolution.  The scrum team I work on uses the Jira bug tracking tool which integrates very well with our test case software, TestRail.  It is extremely helpful to developers when QA Engineers provide consistent and relevant information to assist the developer in locating and addressing the specific issue.  Here are some sample details we require QA to provide in every bug report:

Bug Name: 500 Server Error When Adding a Comment > 2000 Characters
Bug #: (Automatically added by Jira or other Bug tracking tool)
Type: Bug
Status: To Do
Priority:  High/Medium/Low
Affects Version/s: Version Number
Component/s: Software components
Environment: QA
Sprint: Sprint ##.##
Assigned to: Developer Name
Reported By: Your Name
Reported On: Date
Reason: Defect
Status: New/Open/Active (Depends on the Tool you are using)
Environment: Dev/QA/Staging/Production

Description:
Application crash on clicking the Add Comment button when a comment has more than 2000 characters.

Steps To Reproduce:

  • Log in to Application
  • Navigate to Attendance Page
  • Enter attendance
  • Select Date
  • Enter text > 2000 characters
  • Click Save Comment

Expected Result:
Should receive error stating cannot exceed 2000 characters

Actual Result:
Receive a 500 Internal Server error

Stack Trace:
If you have access to database logs or similar, include as much of the exception details as possible.  This may involve filtering through a lot of records to locate the exact stack trace for the exception.  This can save developers a significant amount of time which is win win for the whole team.

 

New Role As Quality Engineer

 

 

 

 

 

 

 

 

 

 

 

In March, 2016 as my family was moving from Dallas, TX to Kalamazoo, MI, I discovered that Fellowship One was being acquired by a company called Ministry Brands. Here’s the press release. This meant a lot of changes at work! My role within Active Network was API Software Engineer and it was a hybrid of developing REST-API’s, testing the existing API’s prior to every release cycle and supporting the Developer Community. My favorite part of the job was actually the testing function. To do this efficiently, I created an exhaustive REST-API testing framework which iteratively called upon every endpoint we exposed and checked HTTP response codes, response messages, and response data. I used PHPUnit to accomplish this and we opened up the code to be used as an example of API consumption, found here.

Shortly after the acquisition, a position opened up on our development team for a Software Quality Engineer and I eagerly applied. I was given the role without hesitation and now lead the software Quality efforts for Fellowship One Premier. I work with an amazing team of developers and every day we work to make our product better.  I am passionate about testing whether it be on the API level or the user interface level and love the challenge of finding bugs!

Family holiday in England

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

Single Sign On Demo and Code

Http Dev Client Demo

Installing PHP Extension Mcrypt on Mac OS 10.7

Today I needed to install the Mcrypt PHP Extension on my Mac running OS 10.7 and PHP 5.4.10.  I had to piece together directions from a number of sites and so I’m outlining them here in case anyone else finds this useful:

1. Make a new directory called “mcrypt”

2. Download mcrypt from here

3. Download the php binary file for the php version you are running

4. Move both of these unzipped downloads to the “mcrypt” folder you created

5. Open Terminal, type:

 cd libmcrypt-2.5.8 
 ./configure 
  make 
  sudo make install 

6.  Libmcrypt is now configured but now it’s necessary to make the mcrypt extension

7. In Terminal:

 cd ../php-5.4.10/ext/mcrypt  
 /usr/bin/phpize 

8. You should see:


Configuring for:

PHP Api Version: 20100412
Zend Module Api No: 20100525
Zend Extension Api No: 220100525 

9. Type:

 ./configure 
 make  
 sudo make install  

10. You should see:


Installing shared extensions:     /usr/lib/php/extensions/no-debug-non-zts-20100525/ 

11. Open you php.ini file and add the following line:

 extension=mcrypt.so 


That’s it!

 

Webhooks, Formstack & Fellowship One

Web Dev = Creative Work

 

Page 1 of 3123»