There are all kinds of checks and balances that can be put into place, and much planning and preparation that comes with the territory of ensuring high-quality software. But sometimes – despite our best efforts – errors happen. Deploy a bug with billing and throw off your accounts receivables. Introduce a misstep with routing and shut the system down for hours. Small bugs languish while the focus is on the next shiny thing, then you launch that new feature and introduce a security risk that compromises customer trust in your product (and you).
So, what protections can we put in place to keep ourselves and our customers safe? And who is ultimately responsible for the quality of what’s deployed? A lot of this depends on who you ask, how the organization is structured, or the current operating methodologies. Let’s look at a few models:
Traditional, QA Tester
A traditional approach to quality assurance (QA) involves two teams: development and QA. Once a developer’s work is code complete, the work is given to a QA tester (or quality engineer) who provides another set of eyes. The work usually includes a general explanation of the changes, what to test, and where to test it. Typically, when work lands in QA’s workstream, it’s often the first time the tester has heard of the changes. QA is responsible for the bulk of testing, including writing test scripts and ensuring the system matches the intended changes.
In this model, the quality engineer is the single point of failure. Additionally, the customer support team is not very familiar with the changes and only sees them once they read the new support article that got published with the release. The team that’s responsible for fielding questions coming in from the users is largely flying blind.
Embedded, QA Tester
The embedded approach to QA means that a quality engineer is part of the workgroup, e.g., a team or squad. The group usually also includes a product person, a designer, and several developers. In this model, QA has a seat at the table to gain an understanding and help raise pertinent questions before the work is even started. The team collaborates within their unit to complete the work, but the team member who plays the tester role is still largely responsible for catching any issues.
This model is a more collaborative approach. The QA tester is still the single point of failure, but they’ll feel more empowered to raise issues since they’re involved from the beginning. Additionally, they’ll likely catch the issue sooner for quicker resolution. Although the customer support team is not involved in the process, they’re educated (about big things, at least) before changes go out.
Embedded, Shared QA Testing
This approach entails a different mindset and organizational structure as there is no QA tester. The work group includes a product person and several developers who collaborate to prepare for and complete the work. Developers are responsible for building quality into their work while product managers provide feedback (early and often!) that involves an array of usability and integrated testing. Once the workgroup has given its stamp of approval — tests built, product feedback addressed, PR approved — the customer support team tests the changes.
Within this model, everyone is responsible for quality including product, engineering, and support. This means there isn’t one person who is the single point of quality failure… anyone is fully empowered to stop the process if/when they see an issue. Furthermore, involving the customer support team as a checkpoint before changes are released ensures they’re prepared to effectively support the users. Not only do they understand the changes, but they also played a role in getting those changes out the door.
Realtracs Product Quality
Realtracs follows the embedded, shared QA testing approach in order to deliver the best possible software to our customers. Through the transparency of work and knowledge sharing that this method embraces, the high-quality output becomes everyone’s goal. This doesn’t mean we have bug-free software, but it does mean a) when someone sees an issue they raise it, b) bug fixes are frequently prioritized over new features, and c) collaborative problem-solving is abundant. And with all of that comes a great deal of empowerment for everyone involved.
