Quality runs through every part of TruQC’s internal procedures, be it our front-line Customer Support team, our Configuration Specialists, or our “back of the house” Development Team. This article is going to focus on some of the specifics that our Development Team uses to ensure that every software release is of the utmost quality.

THE LIFE OF A FEATURE

The areas below detail the evolution of a feature request at TruQC and the multiple gates for quality.

PLANNING
Anyone can identify an opportunity for improvement, or an issue that needs resolution, and file a ticket with specifics for the request. Detailed requirements are enforced. This might be some notes in the ticket about platform, expected results, and actual results. Or, when necessary for larger items, we produce detailed specification documents, workflows, and–the most helpful tool of all–wireframes, which clearly identify the business goal and proposed path forward. Careful consideration is given to the optimal User Experience (UX). Notably, developers will often be involved in this phase to make sure the suggested solution is technically feasible, efficient, and prudent.

CODE REVIEWS
We have weekly group code reviews where topics of interest are discussed with specific coding challenges and best practices. All code goes through a peer review with a Pull Request (PR) requiring approval before being merged.

FUV
Developers add code to address the ticket on a feature branch in git, test locally, run unit tests, and mark the ticket Finished. We typically average about one or two releases worth of Finished tickets hanging out in our backlog, from which Project Managers and Sales continually pick from for upcoming releases. Of course, some features span several tickets and are grouped accordingly. This list is known as the FUV (Finished, Un-Versioned). Project Managers often test here to confirm functionality.

DEV
Once a ticket is slated for a release, it is merged to the development branch which promotes the work to the Dev environment. Every release has a Release Manager (RM) in each of our disciplines (iOS, Web/Server, QA), which is a rotating developer responsibility. The RM is charged with understanding the scope of the release as a whole for their team to make sure we’re being as smart and focused as possible about what we’re pushing out. The RM is also responsible for testing all tickets in their release for their team on the Dev environment. The RM indicates in the ticket that it has passed their testing. Project Managers do the same on Dev. Automated tests run on every continuous integration build. The full suite of regression tests run nightly to ensure no errors. Churn can happen on Dev, tickets can be rejected (though our rejection rate is extremely low, for real), changes may be requested by PM’s, etc.

INTEGRATE
Once the release has passed Dev and PM testing, it is merged to the master branch and promoted to the Integrate environment. Code freeze is in place for new tickets, but code may be committed if necessary for fixes to existing tickets in the release. This is where QA picks up the reigns. Every ticket is tested by QA, including any relevant manual regression test suites they feel are necessary above and beyond the automated tests. Besides the tests run on every continuous integration build, nightly automated tests continue to run the full suite on all platforms and the results emailed, with follow-up as necessary. We also have automated performance testing that runs nightly on Integrate and we monitor for negative trends. Churn can happen here too if QA spots any areas that need polish.

BETA
Once all tickets have passed QA testing on Integrate, we call a code freeze, tag the release in git, and promote to Beta. In terms of hardware and configuration, the Beta environment matches our Production environment in every way. All tickets and regression tests are run again QA. However, the QA Engineer who tested a certain ticket on Integrate does not test that same ticket on Beta. Instead, that ticket receives yet another fresh set of eyes. If any tickets are rejected, we are hyper-critical about adding or removing code. A severity and impact assessment is performed and a resolution path identified. It isn’t uncommon for a “beta2” release to happen they are minor and controlled equally to the first beta release (unlike Integrate or Dev where commits may happen without coordination).

PRODUCTION
The exact same container that was confirmed on Beta by QA is promoted to Production, ensuring that the exact same code that has been tested repeatedly is in place for customers to use. We have a 24/7/365 Reliability Team that is on-call if issues should arise in Production, though we’re happy to say this duty is largely quiet no doubt due to the process outlined above.

SUMMARY

Features are carefully planned and executed. Every bit of code that makes it to Production has been tested by the developer, the RM, the PM, and twice by QA, as well as unit tests, automated integration tests, and performance tests. Quality is in our name and we live by the high standard that our customers expect of a Quality Control product. Not only is this good for our customers, but it’s good for our developer and Reliability Team morale! And for Sales, it makes it easier to sell a product that works every time.