We believe robust Quality Assurance (QA) is an integral part of creating truly innovating digital products and ensuring their market success. The following post is part 1 of our series on QA the L4 way.
I’ve always been in love with the popular story of the first “bug”: When Grace Hopper and her team were working on an early computer, they found and removed a moth from a potentially compromising location within their (giant) machine. I don’t know that they ever expected a moth to potentially ruin their day, but a lot of work went into their hardware, and they couldn’t afford to cut corners. It would not do to leave it be. Now, of course, bugs are more than just wayward moths, but they can still have a potentially far reaching, outsized impact on software releases, and, potentially, your business.
Time and Budget Saver
When dealing with software development and release, there will always be bugs. Eggs must be broken to make an omelet, and no code will ever be perfect as first written. That’s why good development should always include thorough quality assurance (QA) process as a bulwark against lost time, resources, and money.
Strong QA Engineers working in concert with a responsive development team can shield your final app from quite a bit of risk. The ability to identify these issues in-house, and to communicate them with the development team immediately allows you to make smarter development choices before product release. Once an app is out in the wild, the economic impact of a single bug can be quite profound. Studies show that bugs cost four to five times less to fix in development than after product release. Bugs in software as a whole are estimated to cost the entire economy billions, annually!
Process Over Perfection
No team will catch all bugs before production, but minimizing risk should be the end goal of any good QA team. The best way to do that is through an ironclad process. Methodical testing, vigilance, and a keen eye for detail are of course integral to this practice. Perhaps most important however, is the ability to accurately report what it is you find whilst executing that process. We as QA professionals must be able to see what’s not right, and then write a recipe of sorts, one that will allow any of the cooks in the development kitchen to fix the entree before it is served.
Kitchen metaphors aside, the proper reporting of issues as they arise can serve many purposes. Of course, well written issues allow Dev teams to efficiently track down the same issues, and more easily find their root causes. But they also serve as in-process documentation on the health of the application, over time. This should not be taken lightly; there’s no need to reinvent the wheel, and waste time and money when adding robust regression tests to a good test suite: Many of the reported issues should serve as a foundation for those very same tests. Reporting issues with detail and context, and a clear set of reproduction steps the first time can make everyone’s life easier, and of course, save money.
Comprehensively testing any product throughout its development should always serve to minimize risk, and result in a more robust, quality outcome. The foundation of any good QA testing should always be a well-written bug. No matter how we report them, we should always report bugs in a way that allows them to become a resource to others. We want them to be documents that can be accessed, understood, retested, and reproduced. We want to know desired and actual outcomes. We want to give developers a leg up on getting to the bottom of what’s ailing the app, and have a record of health over time. We can light the way for those who work to maintain or plan the future of software we help we create.