Better and Faster QA in GitHub

Mistakes happen. Startups are built on them; if you’re making mistakes it means you’re moving forward. Great teams turn mistakes into opportunities, adapt on the fly, and put systems in place to prevent them from happening in the future. Dysfunctional teams point fingers, lay blame, and risk becoming stagnant by creating an environment where their members are disincentivized to do new things.

A little less than six months ago, a few things came together at once for us:

  1. We added a few developers to our team
  2. We began releasing more aggressively
  3. Customers started using our platform for more complex tasks

These things were all extremely positive, but came at a cost. Two of our weekly releases went out with bugs. They were extremely minor, but totally preventable.

When we dug into the issues that had popped up, we found that our QA processes weren’t cutting it. We’d build for a release and then have our product stakeholders and key users check out the results. Some now-obvious problems with that model:

  • Key users became busier and busier, giving them less time to QA.
  • The updates we were putting in place were increasingly advanced and needed formal attention.
  • Sometimes the QA steps were poorly designed or incomplete; engineers weren’t thinking like users and vice versa.

We could have put a more tedious and increasingly formal process in place, with more levels and sign offs, but it would have just slowed us down. Not something we could afford. So instead we looked for ways that we could “do better, faster.” With a few quick and extremely simple changes to our processes, we found a way to get through QA faster with more reliable results.

Using GitHub Labels for QA

Issues-Label-CreateTo understand what we changed, you need to know that we do as much project management as possible in GitHub. High level, the workflow goes like this:

  1. Bugs, new features, and projects are defined in “Issues”
  2. “Issues” are organized into groups around a goal, called “Milestones”
  3. Code is written, unit tested, and team reviewed
  4. “Issues” are closed out and pushed from local to a group dev environment for testing
  5. When a “Milestone” is complete, the tested code is pushed to production and validated

The breakdown was occurring between Step 4 and Step 5, and that’s where we made the fix. GitHub has a feature called “Labels” that allows you to tag issues a certain way. In addition to standard labels like “enhancement,” “bug,” “idea,” etc., we created three new labels: “Available for QA,” “QA Pass,” and “QA Fail.” As soon as code is moved to the dev environment, the “Available for QA” label is applied and that process kicks off.

The team documents the steps taken to QA the update and then applies the appropriate tag. When reviewing a Milestone for a push to production, it’s now very easy to see the QA status of each issue, for the whole team to review (and potentially improve upon) the steps taken in QA, as well as review any issues. All of our code, status, and feedback is even more consolidated than before.

Since implementing these basic labels and putting more of our QA process into GitHub, we’re getting through QA faster, we’re launching faster, and we’re more effectively delivering for our clients.

Categories
Technology