Перфоманс Лаб

e-commerce
нагрузочное тестирование
функциональное тестирование
8 декабря, 2023

Великие фейлы: 5 громких случаев, когда компании сэкономили на тестировании

Время чтения: 8 мин.
8 декабря, 2023
Автор:
Анастасия Сопикова

Всё еще не верите в силу QA? Тогда мы идем к вам! Даже компании-гиганты — от Apple до Nike — в свое время недооценили тестирование и в результате потеряли миллионы долларов. Собрали пять самых громких и невообразимых кейсов, которые помогут учиться на чужих ошибках.

Nike и коллапс ненужных кроссовок

В 2000 году Nike использовал систему планнинга спроса и предложения от i2 Technologies. Однажды она дала сбой и отправила на фабрики заказ модели Air Garnett — на несколько тысяч пар больше, чем можно продать. Сверхпопулярных на тот момент AirJordans, наоборот, было выпущено на несколько тысяч пар меньше, чем нужно. Кроме того, Nike обвинили разработчиков в том, что система планнинга была невероятно медленной, плохо интегрировалась с другим программным обеспечением и просто кишела дефектами. Однако они также признали, что сотрудники, использовавшие систему, не прошли необходимое обучение. Вице-президент Nike Роланд Вольфрам признался, что выбор пал на i2 потому, что установка показалась намного проще, чем изначально планировавшийся проект Nike Supply Chain (NSC) — подразумевалось изменить всю внутреннюю систему планирования и поставок.

Что в результате? Перепроизводство, минус 100 млн долларов выручки и падение акций компаний аж на 20%. К весне 2001 года Nike переехали на SAP ERP, которая базируется на заказах и счетах, а не на алгоритмах прогнозирования, а к 2004 году все-таки внедрили NSC. Годы спустя CIO компании прокомментировал ситуацию:

«Единственным стратегическим просчетом была закупка ПО, которое работало по принципу гадания на хрустальном шаре. Идея закинуть в программу кучу исторических данных о продажах и ждать, пока алгоритм выдаст некое магическое число, нигде не сработает хорошо, а в данном случае даже не отвечала бизнес-модели Nike».
5 случаев когда компании сэкономили на тестировании

St. Mary’s Mercy Medical Center и ходячие мертвецы

В 2003 году в Мичигане произошел настоящий медицинский коллапс. Системы крупнейшего медицинского центра St. Mary’s Mercy дали сбой, и пометили 8 500 пациентов в базе как умерших. Ошибка затронула всех, кто обращался в госпиталь с октября по декабрь предыдущего года — большинство из них просто сдали кровь или проходили плановые осмотры.

На техническом уровне причина банальна: софт, которым пользовалась больница, обновился, и произошла ошибка маппинга. Вместо кода 01 (выписан из больницы) пациентам был проставлен код 20 (умер). Проблема была не только в том, что система «убила» пациентов в базе данных самого медицинского центра — она еще и оповестила самих пациентов, их родственников, страховые компании и социальные службы. Случай был настолько громким, что облетел все мировые новости, а также привел к нескольким судебным искам.

5 случаев когда компании сэкономили на тестировании

Аэропорт Хитроу и 42 000 потерянных чемоданов

В 2008 году открылся пятый терминал лондонского аэропорта Хитроу. Вместе с ним заработала и новая система выдачи багажа. Об обеспечении качества уже начинали догадываться, поэтому систему протестировали, обработав в ней целых 12 000 багажных единиц в час.

На тесте все работало прекрасно, однако в день открытия терминала система вышла из строя уже около 11 часов утра. Свой багаж получили только пассажиры самого первого рейса из Гонконга — и то, потому менеджеры собственноручно вытаскивали сумки из самолета. В течение следующих нескольких дней примерно 42 000 единиц багажа загрузили не на те самолеты, а 500 рейсов и вовсе пришлось отменить.

Почему на тесте всё работало отлично, а на бою система упала? Аналитики считают, что причина в неадекватных реальности тест-кейсах. Например, при тесте не учли сценарий, в котором багаж удаляется из системы вручную, а не после выдачи — это действие оператора могло «поломать» всю систему.

Потерянные чемоданы — самая известная, но далеко не единственная ошибка, обнаруженная в день открытия. Система безопасности не считывала ID-карточки персонала, двери, которые предполагалось держать открытыми, заблокировались, 17 из 18 лифтов застревали, эскалаторы встали, а электронные табло прилета погасли. Самое смешное и печальное в этой истории в том, что строительство пятого терминала готовилось 20 лет и стоило 4,3 миллиарда фунтов стерлингов.

Не рискуйте деньгами и репутацией

Обратитесь к инженерам «Перфоманс Лаб».
Следим за качеством больше 15 лет, 100+ успешных кейсов в портфолио.

Knight Capital Group и распродажа дорогих акций

Как потерять 440 миллионов долларов за полчаса? Очень просто — сэкономить на тестировании программы для трейдинга.

В 2012 году Knight Capital Group инвестировала в новый торговый алгоритм, который должен был помочь им добиться успеха на фондовых рынках. 1 августа алгоритм дал сбой: он закупил дорого и продал дешево 150 различных акций. Эти сделки обошлись компании в 440 миллионов долларов, а общий убыток в четыре раза превысил чистый доход предыдущего, 2011 года. Knight Capital Group так и не оправилась от потерь и в конечном итоге была куплена Goldman Sachs менее чем через год.

Помимо проблем с QA, в компании были плохо настроены процессы. Утром в день сбоя внутренняя система компании сгенерировала 97 алертов ошибки «Power Peg отключен». Эти внутренние сообщения были отправлены персоналу Knight, однако электронная почта не была предназначена для высокоприоритетных оповещений, и сотрудники обычно не просматривали ее в режиме реального времени. Увы, так  была упущена возможность выявить и устранить проблему до открытия торгов.

Apple и карты без навигации

Поклонники Apple верят, что у этой-то компании с процессами тестирования всё в порядке. Однако как минимум одну большую ошибку компания совершила — в 2012 году, когда в очередной раз обновила iOS. Тогда привычное пользователям приложение Google Maps сменилась на Apple Maps. Это было не чем иным, как частью корпоративной политики, направленной на завоевание большей доли рынка. 

Apple хотела выпустить новейшее и лучшее картографическое приложение как можно раньше, и это привело к непростительным дефектам в навигации, известным как #ios6apocalypse. В Apple Maps были ложные данные о местоположении, искаженная графика, дублированные острова, сплющенные ориентиры, исчезнувшие здания и стертые города. Интернет наводнили скриншоты: музей провалился в реку, английский город Статфорд-апон-Эйвон пропал, а вместо Лондона в Великобритании навигатор отправлял пользователя в местечко Лондон в Канаде.

По оценкам The Guardian, в результате ошибки Apple потеряла 30 миллионов долларов от рыночной стоимости. Аналитики гадали: неужели совет директоров не был в курсе, насколько дефектным получилось приложение Apple Maps? Или знал — и все равно решил выпустить его на рынок? А как тогда получилось безупречное демо, которое компания показывала на презентации? Вопросов было настолько много, что многие предрекали Тиму Куку скорую отставку. Отставки не случилось, но компании пришлось выпустить официальное письмо с извинениями, а также потратить еще пару лет на доработку сырой версии приложения.

5 случаев когда компании сэкономили на тестировании

Бонус: банк «Ак Барс» и 30 тысяч ошибочных переводов

Российские компании не очень любят делиться историями провалов — такое бывает только на закрытых конференциях или в анонимных обсуждениях среди разработчиков. Тем не менее, кое-какие кейсы просачиваются в инфополе, особенно если ошибку приходится исправлять в суде.

В феврале этого года пользователь из Казани обнаружил выгодный баг в мобильном приложении банка «Ак Барс». Совершенно случайно он перевел деньги с букмекерского счета на свою заблокированную карту — банк операцию отклонил, и деньги вернулись на букмекерский счет, но вместе с тем пришли и на другую, не заблокированную карту. Предприимчивый клиент совершил такую операцию еще 30 тысяч (!) раз, и «заработал» 68 миллионов рублей. Сотрудники банка обнаружили подозрительную активность только через десять дней, когда он уже успел снять наличные, купить машину и скрыться за границей. Что ни говори, для бизнеса история крайне поучительная: про важность быстрой реакции, тщательное тестирование мобильного банкинга и особое внимание к дефектам процессинга.

Нагрузочное тестирование — залог стабильного роста

Чтобы не терять миллионы из-за багов, обратитесь к инженерам «Перфоманс Лаб»
cta testirovanie za 1 den