Quality assurance is about more than just checking lines of code

A couple of weeks ago, I received unexpected feedback on a proposal, “Why am I paying for quality assurance? Don’t your guys write good code?”

The client was right of course, and yes, generally speaking, we develop very good code, but that isn’t what QA is about.

I took some time to explain how I view QA and why a company should pay for it. Sure, it was about testers banging away on keyboards, but there was a lot more. The process of envisioning QA involves sitting down with the business analyst, understanding use cases and business requirements, overlaying those on the solution, and developing a series of complex test scripts. This requirement is critical and, in our opinion, ideally is not staffed by developers.

It’s not all about testing the middleware we created; it also involves an overall solution validation. If a consumer fills an order cart, does it all get processed? If they change quantities, does that get reflected? If they cancel the order prior to finalizing the purchase, is any inventory reserved for the order returned to the shelf?

The challenges go further. If a customer enters an illegal character, does the system kick it back or does it ship 100 units for free? This is called negative testing.

Most systems today have many touch points, and some are out of scope for the project. Adding new functionality can expose the order fulfillment system to unexpected risks. More retailers are working with just-in-time inventories. If a person places a large order and cancels, did the old system that generated an automated purchase order for the drop shipment also delete the order? Should the part of the process that is out of scope be redesigned?

I now view quality-assurance discussions with clients differently, and I feel it’s time for a new descriptor for this critical role.