“Three Sets of Eyes: ” A Quality Philosophy That Works

Our QA Team is an essential part of the development process at Tonic Design Co. Take some time to learn about our approach to QA from our fearless Quality Director Jay Newlin.

When I walked into DmgCtrl’s office (DmgCtrl was one of Tonic Design Co.’s predecessor companies) in April 2013, I was indoctrinated into the core philosophy that we knew was at the heart of all our successful projects. That philosophy — which still guides and underpins Tonic’s Quality Philosophy today — can be simply stated as the concept “Three Sets of Eyes.”

One Developer codes his or her unit of work. A second Developer conducts Code Review on that branch. Like a dialogue, Code Review is a cooperative back-and-forth between the two Developers until both are satisfied that the written code is clean and properly meets the requirements set out in the Development Ticket. A member of the QA Team receives the ticket and the branch to test. It is his or her responsibility to perform all tests required to ensure that the unit of work meets the Acceptance Criteria and that it doesn't cause a fault or failure in other parts of the app, website, or system. We repeat as many cycles of these three steps as are necessary to ensure that the branch functions properly and will be acceptable to the end-user.

I can hear your thoughts: “That’s it? Hardly a “secret sauce” that lends itself to high-quality branches, projects, and company. Really? That’s it?”

Many companies embrace a “Quality Philosophy” that turns into six posters that hang on walls around the office. Others believe strongly in Quality as a concept, but they still segregate their Quality Team from Development (and often from everyone else in the organization). Many others hope that they’ll produce good-enough software that will get better “when we can finally get the bug backlog down to zero.”

For Tonic this simple concept really is “secret sauce” because we imbue every line of code, every commit, and every branch with it. We embrace the quality of our work as something that all members of the team contribute to — from the newest Development Apprentice all the way up to the Founders of the company. We train and remind ourselves to think about quality so that it’s simply part of the company’s DNA.

Another part of the “secret” is that we trust both the philosophy and each other. When I write a line of code (or a test step or a line in a blog post or almost anything in this office), I know that it will be seen by at least one other person. I don’t want them to “reject” it back to me with seventeen different comments, so I spend the time to make sure that it’s my level-headed best effort. When they start their review, they’re going to examine my work for adherence to clean code principles, for brevity, for best approach, and they’re also going to run at least one simple test (“Does this branch at least do what the ticket says that it should do?”). They trust that I have done my best, and they offer any comments in an attempt to make my work even better.

When we approach “Unit of Work” and “Code Review” with this level of scrutiny, we find that few bugs make it into the codebase. In an odd way, QA becomes more like a game: The Developer and Reviewer “dare” the QA Engineer to find a bug, and the QA Engineer accepts the challenge in the same spirit, testing it from every angle possible, hoping to “taunt” slightly if and when they do find a bug. We’re very proud of the fact that very few bugs make it out our front door because of this process.

We apply a similar approach for the other types of work that we produce (UI/UX designs, publications, blog posts, marketing materials, etc.) because it has a proven track record. Even though I’m one of the company’s main proofreaders and editors, I know that this article will have been reviewed by at least two others. Every word, phrase, sentence, and paragraph will be the best that it can possibly be because other people will have contributed their time and talent in reviewing, improving, and/or re-shaping it.

All this points to another secret that underpins our approach to quality, summed up by Tonic Value #4: “We approach problems as a team.” QA (and Code Reviewers and Proofreaders and Editors) don’t sit in some place that separates and isolates them from everyone else. Instead, the QA Engineer sits in the same quad as the rest of the Development Team on every project. At least one Senior QA Engineer actually switches desks throughout the day, to ensure that she’s right in the middle of the team that she’s working with. No one in the company can solve any problem or do their highest-quality work without input, feedback, and assistance from others.

So there you have it: Tonic’s Secret to High Quality: Three Sets of Eyes, aka Teamwork and Trust.