Most of us have heard the term quality assurance or QA, but many don’t know precisely what it means—or just how critical it can be to businesses of all kinds. QA plays a vital role in software development, and its importance has gained prominence over time as development models have evolved to focus on increasingly rigorous testing, starting earlier in the process.
Take, for instance, the Scrum framework, which emphasizes an iterative approach to building product, in which testing is conducted as each feature is implemented. Similarly, in Extreme programming, development work is divided into small steps with simplicity and testing prioritized throughout.
Whatever the approach, one theme has emerged: QA testing must happen early, often and at every phase of the development process.
What exactly is QA?
Because QA has many facets, it’s difficult to define it as merely one thing. The term often refers to both the act of QA testing itself, as well as the team responsible for doing that work. Generally, QA is the process of testing a product to ensure that it meets company standards and is bug-free and ready for release. While the specific QA activities conducted will vary by product, the process usually includes the following steps:Testing of the product (manual or automated)
- Ensuring that features are developed correctly
- Preventing new issues from being introduced
- Confirming proper product documentation
Typically, when it comes to determining if a product is ready for production, the QA team will be consulted on its opinion. Since these experts are the ones most familiar with the state of the product, it’s critical that companies listen to their recommendations. Many businesses who haven’t heeded the advice of QA—or worse, have operated without a formal QA process in place—have quite literally paid the price. More on that in a moment.
Pennywise, pound foolish?
Occasionally, companies mistakenly view QA as an unnecessary expense that can be eliminated or minimized. But in reality, it can ultimately save money, time and even embarrassment. Compared to the potential cost of releasing an issue-riddled product before it’s ready, the wages and benefits of QA staff start to look like a drop in the bucket.
Take, for example, Knight Capital, who suffered a loss of $440 million due to what the company called a “glitch” in its high-frequency trading (HFT) software. Reports suggest that an update to the HFT system had been rushed into production the night before the incident, without undergoing proper, rigorous QA testing. It took only 30 minutes for the company to lose three times its annual earnings and incur untold long-term damage to its reputation.
Inadequate QA also reportedly played a role in the recent high-profile debacle of delayed results at the Iowa State Democratic caucuses. An app, commissioned by the Iowa Democratic Party to tabulate and report caucus results, fell prey to a “coding issue” that caused incomplete data reporting, forcing the party to rely on manual backups. According to the New York Times, the developer had rushed the app into production without sufficiently testing it on a statewide scale. The result? Confusion, frustration and widespread mistrust of caucus results during a critical political contest—all under the scrutiny of an avidly watching nation.
Practice makes perfect
To avoid becoming the next cautionary tale, be sure to establish QA best practices and approaches early on in any project. Below are six key concepts to keep in mind as you do.
- Build a QA checklist: While it’s tempting to dive headfirst into a project, creating a thoughtful QA plan ahead of time will enable a more uniform testing approach and significantly reduce the potential for error. That’s not to say that your checklist must be set in stone; in fact, you’ll achieve better results if you adapt as project needs emerge along the way. Bottom line: be flexible, but deliberate.
- Test every feature like it’s a critical feature. Just because an implementation took little time to develop doesn’t mean its testing will—or should—be straightforward. Treat each feature as if it’s a critical one that will make or break the application. Because you never know if it just might.
- Establish specific testing steps. Each user story should have a dedicated list of QA steps, chosen specifically to test that particular feature. If you didn’t create the implementation yourself, don’t be afraid to ask its developer questions as you build your list. After all, he or she will have the best insight into the expected behavior of each feature and can help you find those pesky edge cases.
- Regression test. We can’t stress enough the importance of regression testing. New features may test correctly on their own, but when introduced to the entire application, they can uncover dormant bugs. For this reason, it’s crucial that your QA plan includes regular tests of the product as a whole.
- Test regularly and repeatedly. Just because one test round is successful doesn’t mean you’re in the clear. After all, the Hindenburg safely completed six test flights before its formal public debut, and we all know how that ended. So take a lesson from history, and test each feature more than once.
- Don’t rush it. If Knight Capital and the Iowa caucuses taught us anything, it’s that one should never race to get features or products out the door. Testing should be systematic, rigorous and exhaustive. And if you feel that an application or feature isn’t ready for deployment, don’t be afraid to speak up. Chances are, your company will thank you later.
Learn more about Zennify’s Web Services team and how we can help your business establish QA best practices today.
