QA the Pixo way: best practices for better software

You might think that “Quality Assurance testing” implies we expect to make mistakes in development. And you’d be right!

Building custom tech that adds real value to organizations—automating processes, synthesizing data, and scaling across enterprises—is bound to be complicated. That’s why a robust QA program is essential to our process; it’s a lifeline for navigating the complexities of our work.

At Pixo, we don’t see quality assurance as a “nice-to-have” or an “extra step” to fix broken things. Instead, effective QA should integrate with and speed up the development process, not slow it down. By accelerating feedback loops through repeat testing throughout the development cycle, we can produce quicker iterations and faster, more confident releases.

Here’s a closer look at how we do QA at Pixo, including some insider insights from our own dedicated QA Analyst, Jeremy.

#1: We’re team BDD to the bone.

At Pixo, we consider behavior-driven development (BDD) the gold standard for writing QA tests. This methodology clarifies complexities and centers the human experience by testing against “scenarios.”

“In writing tests with BDD, we focus on what we call the ‘happy paths’—the workflows that you tend to do every day,” Jeremy says.

All too often, what users perceive as a single task “turns out to have twists and turns and wormholes,”—like if-then dependencies, diverging workflows, exceptions, and edge cases—lurking beneath the “simple” surface description. The very process of writing BDD tests can help reveal these blind spots, parsing out all the complexities in plain language.

“You realize, ‘oh, look, I had to actually explain six different scenarios that are all variations on the same one task,’” Jeremy says.

Another important aspect of BDD is timing: testing against scenarios necessitates defining them early enough in the development cycle to save time and resources. 

This is crucial because “engineers are going to approach the problem fundamentally differently if we know there are six different ways this could play out, as opposed to just one.”

#2: We test end-to-end.

Unlike an integration or unit test, an end-to-end test examines every part of the codebase, including the user interface (like a browser) against the real API. Only the environment is different. (At Pixo, we set up unique testing environments that only exist for the project’s development cycle. They are completely siloed, so there’s no possible interference from other projects or internal work.)

#3: We use automated testing tools.

Automated testing is exponentially more efficient than manual testing alone.

“It would be impossible for even a team of 100 people to match the workload the automated testing can accomplish in a matter of hours,” Jeremy says.

At Pixo, we most often use browser drivers like Cypress to test all the functionality needed to complete a task. This is essentially a way to use an internet browser like a bot, following a prescribed series of steps much faster than an actual human could.

After all, nobody has time for manual end-to-end testing.

#4. We have dedicated QA resources.

The very existence of a dedicated QA Analyst role is something of a differentiator for Pixo. We believe it’s important to have someone with some distance from the actual development who can offer an independent perspective.

Jeremy—who indeed comes from a publishing background—says he thinks of the role as the “editor” of the application.

“It’s like having a friend proofread your paper, being that second set of eyes,” Jeremy says. “Our brains tend to autocorrect our own work for us. The same things happen with writing software.”

#5. We test early and often.

Rather than a final check on a mostly-finished product, effective QA is an ongoing, iterative process—much like Agile development itself.

“We think of QA as the bookends around implementation,” Jeremy says. “QA sets the acceptance criteria, then engineers lead the implementation, then QA comes back in and tests it again,” …and again, and again, and again, and again.