Many of you already know the buzz going on with iOS 8 and some critical issues which occurred with Apple’s first iOS 8.0.1 software update on Wednesday, September 24th. A major bug with the HealthKit feature was discovered prior to the iOS 8.0 release, which resulted in Apple pulling all HealthKit enabled apps from the App Store ahead of the public release, leaving 3rd-party devs uncertain as to the fate of their Apps.
The major issue that was reported is unknown, but Apple promised a quick fix for the major bug. One week after the iOS 8.0 release, iOS 8.0.1 was released to the public to fix the HealthKit issue and allow related apps back into the App Store. One hour and 15 minutes after the release, iOS 8.0.1 was taken down after critical issues were discovered with iPhone 6 and 6 Plus owners. This resulted in users losing cellular service and malfunctions with the Touch ID feature.
“How could a fix for the HealthKit feature that tracks your calories burned, sleep duration, nutrition and other features, be the cause for users being unable to make or receive phone calls?”
iOS 8.0.2 was released the very next day and contained fixes for the critical issues that came with iOS 8.0.1, as well as the HealthKit issue and other minor bug fixes. So you may be asking yourself, “How could a fix for the HealthKit feature that tracks your calories burned, sleep duration, nutrition and other features, be the cause for users being unable to make or receive phone calls?” Well, the answer is, there’s no real way of knowing for sure how it happened. Just that, it happened.
Whenever new code is implemented for a fix, there’s always a possibility of that fix causing new bugs to occur, which can be in a related area of the software or in a seemingly unrelated area from the original issue. That is why after re-testing the fix that was implemented, it is always best practice to perform regression testing around the affected area, to ensure no other issues were caused by the change.
In this particular case where the issue is related to a major firmware/software update which will affect millions of consumers. The best practice in this case would be to not only re-test the fix and perform regression testing around the affected area of functionality, but to also fully test all major functionality of the iPhone 6 and 6 Plus (as well as all other devices that support the firmware/software update) before releasing the update to the public. Making/receiving phone calls, sending/receiving emails, sending/receiving text/video messages, taking photos/videos, keyboard functionality, the notification center/alerts, wifi, syncing with iTunes, the locked screen, Siri and all other major functionality the iPhones are capable of performing.
There are a couple things we can take away from this situation. First is that more testing will always be better than less testing. If the budget allows for it, perform as much testing as you possibly can if a major update is ready (code complete) before releasing to the general public as well as continuing testing post deployment.
Also be sure to perform a full test sweep of all functionality a device/website/application is capable of performing to ensure nothing was affected by the update and after deployment. Never rush through quality assurance (QA) and always take your time when performing your test sweep, ensuring all critical and major issues have been discovered. The general public will thank you for taking the time to thoroughly test your software so that they don’t have to.