Apple really needs some help with security testing as part of its release cycle for new software. In particular, iOS 7 flaws continue to show up that should have been caught prior to release. The latest issue is that anyone can bypass the iPhone’s lockscreen to hijack photos, email, or Twitter. Also, there’s a bounty for hackers to crack the fingerprint “Touch ID”. Some security analysts claim that this will be a near impossible feat, but my money is on the hackers.
So, why do we hear of so many instances where a company, often a large one, has released a new product or service that has gone through their QA team only to have the public and their customers find some serious security issues and bugs? Well, it’s partly the “see the forest for the trees issue” that’s at the heart of the problem. You and your team are often too close to your products to formulate enough of a unique perspective. You see, no matter how sophisticated of a team you have, the processes you have in place, the tools you use, the test cases you use, you are still limited and myopic to a certain degree by those same sets of tools, processes, people. Whatever your QA process is it will still be dictated by the definition of that very process. If that process has a flaw in it then chances are good you’ll release software that your customers will find issues with.
So, what can you do to increase your odds of finding issues in-house before your software leaves the lab? Secondary QA testing, by a professional software quality assurance company will help. This means to bring into your release process a separate QA team that employs different processes than what you use and to use a team that isn’t as familiar with your product or service as you are and are not already “tainted” with how it should work, look, and feel. Our company, QuadrixIT, is often used by other software development firms to employ a fresh look and fresh test perspective to supplement their in-house test teams and processes. More times than not we’re able to report back to our clients new bugs – both in functionality, feel, and security that they completely missed.
Some companies further try to reduce bugs by implementing a beta test cycle where they have some of their customers test their software after their QA team has completed testing or near the tail-end of the development cycle. While this should certainly be standard protocol, beta testing does not replace the expertise of having a secondary QA team employ their own test processes, tools, and methodologies. If you can utilize a secondary QA team that uses completely different test methodologies (albeit some form of accepted QA processes) than what your team uses, you’ll be that much more assured that those fresh eyes will find issues that your team may not have caught.
Apple and other companies can try to keep the QA team and the development team separate enough from each other to emulate this “freshness”, but in practice that doesn’t work well in the corporate world. Corporate process often dictates that the model is usually one of a shared expertise so that resources can be cross-utilized between teams to meet project timelines and release/development cycles. This close-team integration might be positive for product design and sharing of tools, etc. but it is a sure way to corrupt that fresh perspective when testing. Apple certainly could have benefited by having a secondary QA team review iOS 7, potentially finding these flaws prior to release.