Experience of an engineer who inadvertently locked 10,000 mobile phones in reality with a test script



The quality of the code for testing the created software is often neglected because it has nothing to do with the operation of the software. Engineer Chantonu Tiwali wrote on his blog that the code for such tests caused terrible troubles.

The Day My Script Killed 10,000 Phones in South America

https://new.pythonforengineers.com/blog/the-day-i/

Tiwari was developing an app for mobile phone companies that remotely locks stolen or delinquent smartphones. Since it was installed as part of Android, the user could not uninstall it without permission, and had the authority to control low-level functions such as phone functions and Wi-Fi functions.

The company that Mr. Tiwari worked for not only develops the application itself, but also develops a web application for the operator to operate, and it is said that both applications worked well within the development company. However, a South Korean mobile phone company has requested that the operation tools developed by the company be tested. Although Mr. Tiwari was intimidated by the result of the tool, he was in charge of testing the tool without going against business orders.

Meanwhile, the company Tiwari worked for was acquired by an investment company, and the deadlines for all projects were advanced. Mr. Tiwari's team will test three completely different products at the same time, and due to time constraints, only 'success cases' will be verified.



At one point, the operator decided to test the ability to lock multiple smartphones together by uploading a CSV file. Tiwari wrote the code to generate a random phone number in Python. I logged in to the portal site to try the lock function, and then logged in to another portal site to check the results. Mr. Tiwari said that he scripted this procedure so that he could test tens of thousands of cases over several hours.

Since there was no time until the deadline, the script was not checked, and it seems that the script was running 10 seconds after Mr. Tiwari wrote the script. The script ran well, and when I was about to enter the weekend after checking with the manager, Tiwali received an email saying 'thousands of smartphones are locked in South America.'

The number randomly generated by Mr. Tiwari was actually used in South America, so a large-scale smartphone lock occurred. If all the CSV files used for the test remained, I could handle it by writing a script for unlocking, but Mr. Tiwari overwrote the CSV file with the newly generated number for each test, It seems that he left only the last episode.



Fortunately, I found that I could download 100 locked phone numbers from the site of a Korean mobile phone company, so I created a download script and an unlock script. With the help of a colleague, Tiwari wrote that he was able to handle everything in about an hour.

From this matter, Mr. Tiwari said, 'Test scripts need to pay the same attention as normal code' 'Don't do important tests when the deadline is approaching' 'Mobile phone companies also have smartphones outside their jurisdiction He learned the lesson that he can lock.

Furthermore, as recurrence prevention measures, 'testing is performed step by step from each component to the final system', 'testing not only success patterns but also failure patterns', 'no convenient assumptions are made', and 'development environment is a production environment'. We will prepare it separately and test it there. '

In addition, since the company that Mr. Tiwari worked for at that time has set a strict deadline for the project after that, Mr. Tiwari will completely forget these lessons and recurrence prevention measures even after the accident and confirm the success pattern. He continued to 'pretend to be a test'.

in Software, Posted by log1d_ts