Find out the story behind FaceTime’s bug and improve on Apple’s bug reporting

As you may know, today the alarms have been triggered by a failure in FaceTime group calls that allowed (before off-hook) the caller who could see and hear the device they were calling without their consent. A privacy error caused by an app crash that caused Apple to react by disabling the service and reporting that it is preparing an emergency patch shortly.

Of course, as Apple is, people have begun to flood social media and completely offended comments. In fact right now it’s trending topic on Twitter. It is normal for us to think that a company like Apple that defends privacy by layer and sword, should not have flaws in its software directly related to that issue. And from the very first moment my opinion is clear: I agree that it is an important error and that it should have been detected and corrected long before it even released the functionality to the public.

But as in everything, there are always nuances and now I’m going to go to the other side of the barrier, I’m going to dress up as a developer and I’m going to try to explain (without justification) from the other side.

-10 days ago, a 14-year-old apple device buff discovered the bug, his father tried to communicate it privately via official lyre to Apple and they couldn’t. They didn’t listen. Only when the press has taken it out has Apple reacted

And besides, we’re going to tell a story behind this mistake that to me, personally, does seem to me a much more important bug of Apple and that they should fix: the how a 14-year-old boy was the one who discovered this error 10 days ago and it has been impossible for him to contact Apple and what and take him seriously until the media has made the mistake public.

Software failures

When a program finishes its development phase, it goes into testing. These are automatic and manual. And when we talk about a company as big as Apple with so many developments, testing is usually more automatic than manual.

Automatic tests, also known as unit tests, are part of a development architecture called TDD or Test driven-development. Translated something like «development driven by testing». In essence, it is the ability to create a program that can test the functionality of other programs. In apple’s case, there are two types: unit tests that verify app functionality, and interface tests that verify that the app is correct and well-defined.

In the first case, unit tests, imagine that I have a function that when called should return a specific result that I know is correct at the functional level. Taking it to the simplest: I have a function that takes two numbers and returns the sum of its squares.

-The way to test apps automatically represents more of a method of preventing from changes than a productive way to detect unwanted behaviors-

Well, as I know that this function has to always be given such and such a result, the first thing I do is to check that the function can fail. First because I create it empty and create a test that verifies that it fails (because the functionality is not done). Then I implement the code and relaunch the test to verify that it now works. These are the network steps (the test fails because the function is not done) and green (the test works because now the function is done).

I can complete the test by taking several correct results and add the test to recalculate my previous calculations and verify that it continues to work because it returns what it has to return. If there are any new changes, we enter the refactor phase where we go back to «spoil» the function and verify that the test fails (again network) and then redeploys the changes and so on cyclically.

As development is contingent on creating the tests at once, that’s why it’s «test driven». These unit tests are launched during development and when versions are generated they are also usually run to verify that nothing has changed. Because if someone on the team touches my function and stops returning what they have to return (work as it should) will skip the error that that test hasn’t passed.

-Unit tests are one of the most used methods to verify that an app that already works, does not stop working as it should. But as a method of preventing cases that are defied «from the normal» are not efficient-

For interfaces, we can record usage sequences and check statuses. For example: if I click on a row of a table you should take me to a screen called «Detail» and when you press back on «Detail», you should return to the main screen called «People». That use case is recorded and the program that runs the tests can reproduce that functionality by handling the app automatically and verify that the flow and the screens it navigates are correct. In case someone changed the flow, the test would fail.

These are the very short-lived ways in which apps are tested automatically today, and as you can see they have more of a window prevention function against spoiling things that already work than in locating inappropriate behaviors of the app. The only way to find incorrect use cases that cause failures like group FaceTime is to do manual testing. Let an app tester try to «burst» the app by forcing misuse to post and playing with your imagination to see how you can look for a gap where to find a bug.

As you can understand, it is extremely difficult to find such a flaw because even the most sapylike tester does not have to think that making such a or such a combination can lead to a failure. A past bull, you’d say, it’s easy to think, «it’s a very silly flaw and they could have tried it.» But none of us came up with it (or anyone else in the world that we know of) until 10 days ago that a 14-year-old found this error and tried to report it to Apple. And that’s where the second part of our story begins.

When a young man finds a fault, but no one listens to him

A software bug can be fixed if it is discovered and replicated. All companies, such as Apple, have been making mistakes in their programs and systems since they created the first line of code. It is inherent to development and as we already know, it is impossible to solve it. Not for nothing, we talked recently how Apple had fixed no less than 31 major security flaws in the latest iOS 12.1.3 release.

It is therefore clear that as it is today the structure of the programs it is absolutely impossible to create a software without errors by many tests and preventions that we try to apply. There are so many layers and possible cases, which I insist, is impossible. See how all companies are continually patching their systems, applications, and so on. We live in an endless beta state, from a certain point of view.

-In this story of the FaceTime bug there is a lesson that Apple must learn, almost more important than the error: improve the channels to report the faults and that you do not have to reach the press to have the alarms to go off in Cupertino-

Mistakes, which is hard to manage

Serve the end of the article to set two things out, as a developer with more than 30 years of experience: detecting all software errors is impossible. And as obvious or silly as this FaceTime error may seem, the reality, is that no one (as far as we know) has thought to prove the exact use case that leads to that failure until 10 days since FaceTime group calls were launched with iOS 10.1. Not even Apple, obviously. I don’t justify the company: I put into perspective a reality of software that happens to all companies, including Apple.

On the other hand, and honestly, I appreciate Apple’s ability to react when they have finally realized the mistake. But I think it is more serious that the communication channels have failed to report this error and that it has had to be the press that has raised the alarms for the machinery in Cupertino to react and get to work.

I find it exemplary what they have done in reacting, but they had the opportunity to do so sooner without such a fuss and have been shown to have an important lesson to learn about communicating errors privately to Apple.