Quality at Sovrn

May 5, 2021 - by Nick Dunklee

Quality as a Concept

When you think about quality, what comes to mind? A quantity of tests? Something that says pass or fail? How does one actually measure quality?

Here at Sovrn we are trying to leverage second-order thinking to turn the concept of quality on its head.

Traditionally, quality processes tend to be lumped towards the end of a project. Tests may be developed in parallel while dev is taking place, but the final gatekeeper is, “did it pass?” Quality initiatives may even be finalized well after a product goes into production.

That is a long time to wait for a green light.

Test-Driven Development Pitfalls

Test-driven development has become more mainstream in recent years, and is a thoughtful approach to developing, ensuring that every step of the way tests are being written, and the act of making that test pass shows your code works.

What if your particular idea of what is required to make that test pass differs from what product’s specifications require? You successfully wrote code to pass a test, and in the end, it is incorrect.

Communication is Key

The best strength a team can leverage to enable quality throughout a development process is communication. If everyone is on the same page, not only does it mean the team as a whole has a better view of the project, but also, you are stopping bugs from appearing before they are ever written.

From the inception stage to deployment, there should be quality waypoints. The first draft of the test plan can be developed in concert with the product at inception time. This is a powerful time to bring up test questions. Often one will find architectural sticking points, or pieces that may take more implementation time than originally thought right at the beginning.

Project check-in meetings can also be beneficial. If your project is being developed in phases, set a check-in meeting near the end of each phase. Sit down with the team and review the test plan and tickets. Ensure the work in this phase is meeting the expectations of product, and that blockers have not appeared between this phase and next.

At the end of the project, a final run-through of the test plan is equally as useful. Break down the pass/fail stages of the test plan to team members, and try to hand them out to different engineers than the original author. They will come out with a better understanding of other pieces of the project, as well as a set of fresh eyes revealing issues that may have been missed.

Communicate Early, Communicate Often

As these techniques become muscle memory, the entire development process becomes second-nature. Your team will develop quicker, and better projects. Architectural changes during the process will cease to exist, you will not see large increase in your tech debt. Viewing the entire team, the entire project, the entire customer experience as a whole inter-working organic experience allows rapid and safe growth while mitigating risk.

Quality is not here to play the blame game, but rather to make developers’ lives easier. Fewer bugs, fewer on-call incidents, fewer outages. Happier developers. Happier customers.