Make Quality a Healthy Habit

When you work in quality assurance (QA) it is not uncommon to hear people say, “Oh, so you, like, find broken things?” And while that oversimplification is partly true, it leaves out the more important, proactive, role of QA.

QA as the Editor

As someone who also used to work as an editor in the publishing world, I tend to think of the two in a similar way. Chances are, your favorite book or novel wasn’t shaped by the author alone. That author collaborated closely with an editor (a trusted peer) to help shape the abstract ideas into something wonderful. That editor pointed out gaps in logic, ways to improve the story structure, or opportunities to do something innovative. The editor does more than just fix punctuation and catch typos. Yet, editing and QA are often thought of as that “extra” step at the tail end of a production process that finds mistakes before a product reaches the customer.

Sometimes QA is just a stamp of approval or an “inspected by #3” sticker that you find in a pack of new socks. And while that’s okay for socks, it doesn’t work for software. In software development, quality assurance belongs at the beginning, middle, and end of the development cycle. This is the first installment in a series that examines how better QA processes can make faster, more confident releases possible.

Test Ideas Before Testing Implementation

Somewhere in history, there was almost certainly a hasty construction crew who built four walls and zeros doors. While this sounds ridiculous, equally embarrassing mistakes can easily happen in software development. Especially when people “save QA for the end” of development. Important, seemingly obvious, things are forgotten, like making a login feature without making a logout feature. 

Spotting flaws in the plans means avoiding mistakes before they happen. This is critical because the least expensive time to solve problems is before any implementation begins.

The purpose of QA during the early phase of development is simple: don’t allow critical thought to be deferred until later. Get fully into the weeds of a problem before anyone starts developing the solution. Skipping QA doesn’t negate the complexity, instead it defers it until after a solution has been implemented. If QA doesn’t know what is getting tested before it gets built, then the developers are building a solution without clearly grounded plans. This is how solutions get built to solve the wrong problems, how resources get wasted, and how teams get stuck in endless feedback loops only to still end up with a product that makes no one happy.

Healthy Testing Practices

Frontloading critical thought and testing early and often are not shiny new ideas. These are tried and true practices. They are also the backbone of agile development, test-driven-development (TDD), and behavior-driven development (BDD). Healthy testing practices often get the same reputation as vegetables. Both are clearly important for good health, but are often avoided. When a project does “eat its vegetables,” it shows. It’s evident in the project’s performance, stability, and speed of development.

Where We Go From Here

Coming up in this series, I’ll be exploring a variety of effective QA practices along with practical insights related to test automation. All of these topics will highlight the ways that effective quality assurance doesn’t slow down development, it drives it.