Performing Quality Assurance on a Small Development Team

At work, we have a release coming out in about a week. After months of planning, development, and manual testing, we've upgraded an application with about 300 web components from Ember's App Kit framework to Ember CLI.

While the UI is supposed to look the same between these two apps, the architecture has changed drastically in some areas, since we took the time to refactor code quality mistakes in the previous build and composed data visualization modules and their bound events in a way that makes many components reusable.

Now that we're in the home stretch, we're doing continuous rounds of manual QA at the beginning of each day, finding bugs, filing them in Asana, and fixing them quickly, and I thought I'd share that process. How do we do QA?

1.

If you're using git, like we are, for version control, it makes sense to work on your own branch, since branching is a fundamental Good Case Practice^TM.

2.

This is common sense, but sometimes the joy of thinking you've solved a problem is more fun than verifying that it's actually been solved.

3.

    > git add .
    > git commit -am "This is a commit message that specifies the things in the code that were changed with respect to the feature(s) under development."
    > git push origin my_branch_name
    

After someone pushes to the repository, the other developers on the team receive an e-mail. Here, code reviews are completed, comments regarding changes are posted on the commit, and at the end of that process, the developer who originally pushed the code issues a pull request to the master branch. Steps 2 and 3 are repeated as often as necessary before the pull request is issued.

4.

While this process has its flaws - we do manual QA instead of running automated tests, and code reviews are encouraged but not inherently mandated - using version control with an easy-to-internalize process on a small, agile team is key to our success.