Shortly after the release of Apple's iOS 6.1, reports appeared about issues with iOS Mail and Microsoft Exchange mail servers. They said iOS devices were generating excessive interactions with the server, resulting in huge log files, and there was talk of reduced battery life on the iOS device. In February, Apple released iOS 6.1.2 to address the issue. It turned out the excess Exchange activity only occurred after the user accepted an exception to a recurring calendar event. It seems that Apple tested the new mail app with an Exchange server and verified that it worked. Someone may have even accepted a calendar exception during QA, though I wouldn’t be surprised if this particular capability wasn’t explicitly tested. If it were, the reduced battery life would probably have been noticed. When it comes to its internal processes, Apple is famously secretive. In this particular situation, though, it isn’t too hard to come up with a likely scenario: Apple didn’t check for problems on the Exchange server itself. And I can see why. Exchange, after all, isn’t one of its products, Apple probably has limited expertise in maintaining Exchange servers, and it may not have had the knowledge to include the Exchange server in its test plan. During beta testing, the issue could have been discovered as well, but again I can see how it might have slipped through. Accepting this kind of calendar exception doesn’t occur often. Apple’s testing was focused on the parts that were updated, including its Mail app. In addition, the testers probably had only user access to the Exchange server. The problem showed up in the server log files that users normally don't see. We’ll probably never know whether Apple in fact checked the server logs as part of its testing. Even if it did, it's rare that someone accepts an invitation to a calendar exception. It’s plausible that verifying the server logs was part of the test plan, but not in this particular context. There are several lessons in all this.

• First, when dealing with complex, interconnected systems, it's important that testing verify both ends of each communication.
• Second, all odd results reported by users should be investigated. A single person may have complained about reduced battery life, for example, and I can see how this was dismissed as an anomaly, but in the end it turned out not to be.
• Finally, there must have been someone at Apple who knew that the code handling  this specific event was changed in the iOS 6.1 release. They should have ensured that accepting an invitation to a recurring calendar exception was part of the test plan.

As developers, we're the ones who know best what's changed in each release. We need to communicate what we’re changing so we can be sure these features can be thoroughly tested.