Разработка
JUG Ru Group

Недотестированные продукты: от складного смартфона Samsung до ракеты

Провал Samsung Galaxy Fold вызвал вопросы «как этот продукт прошёл тестирование», но компании-гиганты и до этого упускали важные ошибки.

Сломанный экземпляр Стива Ковача (CNBC) Steve Kovach

После того как у нескольких отправленных на обзор Samsung Galaxy Fold сломались экраны, компания отложила продажи смартфона на неопределённый срок. В результате амбициозное устройство за $1980, которое должно было ассоциироваться у покупателей с будущим, ассоциируется с поломками на второй день. Это показывает важность тщательного тестирования: если бы компания осознала масштаб проблем раньше, потери были бы меньше.

Это не первый случай, когда за недостаточно тщательное тестирование пришлось дорого заплатить, заставляя публику удивляться провалу. Мы разобрали ситуации с Fold и тремя другими продуктами, чтобы понять: почему так происходит?

Samsung Galaxy Fold

Как уже писали на vc.ru, отправленные журналистам Galaxy Fold начали отказывать один за другим. В части случаев сказалось то, что обычная с виду защитная плёнка являлась важной составляющей устройства. Поскольку об этом нигде не сообщалось, журналисты и блогеры дружно пытались отклеить её, выводя смартфон из строя. Однако и в тех случаях, когда плёнку не трогали, тоже возникли проблемы.

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

В связи с этим у многих возник вопрос: «Это устройство вообще не тестировали, что ли?» Казалось бы, если проблемы проявляются так быстро и наглядно, их легко заметить ещё внутри компании, избежав публичного провала.

На самом деле тестирование, разумеется, было. На YouTube-канале Samsung даже опубликовано видео, показывающее, как для многократного складывания-раскладывания Fold используются специальные устройства. По утверждению компании, процесс повторяли больше 200 тысяч раз.

Если в тестирование явно вкладывались ресурсы, почему же тогда оно не спасло? Конечно, со стороны видны не все возможные факторы, но два предположения прямо-таки напрашиваются.

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

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

Второе предположение. Конечно, робот, складывающий смартфон, — это полезно, вопрос «что будет после тысячи раскладываний» в случае с таким устройством очень важен.

Проблема в следующем: робот может сложить Fold хоть миллиард раз, но ему никогда не придёт в голову отклеивать защитную плёнку. И роботы не носят телефон в кармане с крошками печенья. Автоматизация в тестировании очень полезна, но пользовательскую непредсказуемость полностью не автоматизируешь.

Есть популярный твит о том, как тестировщики проверяют маловероятные варианты пользовательского поведения, но при этом упускают по-настоящему важные в реальной жизни:

A QA engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 99999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd.

First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.
Тестировщик заходит в бар. Заказывает бокал пива, 0 бокалов, 999999999 бокалов, ящерицу, -1 бокал, vceicbksjdhd. Затем заходит первый реальный клиент и спрашивает, где туалет. Бар загорается, убивая всех внутри

Вполне возможно, что и с Fold получилась похожая история: тестирование проводили активно, но не проверили те сценарии, на практике оказавшиеся проблемными.

Intel Pentium и Microsoft Excel

От этих продуктов все ожидают, что они будут правильно считать. И если обнаруживается, что в некоторых случаях (пусть даже крайне редких) такой продукт считает неправильно, это привлекает много внимания.

В случае с процессорами Intel это произошло в 1994-м, когда математик Томас Найтли заметил ошибочный результат одного из своих вычислений. Начав искать причину, он обнаружил, что это не единичный случай. Целые числа обрабатывались процессором без проблем, а вот при делении чисел с дробной частью результат мог оказаться неправильным.

Ошибка происходила так редко, что рядовой пользователь вряд ли когда-либо пострадал бы из-за неё, она сказывалась в основном на учёных вроде Найтли. Но более заметной проблемой, чем сам баг, стала реакция Intel.

Во-первых, выяснилось, что компания уже знала об ошибке, но не сообщала о ней. Во-вторых, она заявила, что все желающие заменить процессор на корректно работающий должны сначала обосновать, почему на них эта ошибка скажется. Всё это вызвало шквал негодования. В итоге компания изменила своё решение, пообещав замену любому желающему, и её потери на этом баге, по оценке Найтли, составили сотни миллионов долларов.

А 13 лет спустя произошла история, никак не связанная с предыдущей, но отчасти похожая на неё. Пользователи Excel 2007 с удивлением заметили необычную ошибку, которой не было в предыдущих версиях Excel. Программа корректно считала всё, кроме тех операций с дробными числами, в которых правильный ответ был крайне близок к 65 535 или 65 536: тогда вместо этого пользователь мог внезапно получить 100 000 или 100 001.

Причём проблема была даже не в самом вычислении, а в том, как его результат выводился на экран. Скажем, если домножить его на два, результатом оказывалось уже не ошибочное 200 тысяч, а вполне корректное 131 070. И если на основании ячеек с ошибочным ответом строили график, он тоже оказывался верным. В общем, «внутри» всё явно обрабатывалось правильно, а на экран выдавалось с ошибкой.

Как и в случае с Intel, баг затрагивал очень немногих людей. А поскольку обновить программу гораздо проще и дешевле, чем отозвать устройства, с Excel не возникло большого скандала, ошибку просто исправили в апдейте.

Но эта ситуация интересна тем, что при чтении предыдущего абзаца у многих тестировщиков наверняка загорелись глаза: «Я знаю, в какую сторону надо копать в поисках причины». Их внимание привлекло число 65 536.

Это число получается, если возвести 2 в 16 степень. Поэтому, если под какое-либо значение в компьютерной памяти отведено 16 бит, у этого значения есть 65 536 возможных вариантов. В результате встретить это число в компьютерных системах можно часто — и в связи с багами тоже.

Например, если в 16-битной переменной хранится число и эту переменную попробуют увеличить так, что результат выйдет за рамки 65 536 возможных значений, произойдёт переполнение: дойдя до максимального значения, отсчёт снова пойдёт с минимального. Если это ошибка попала в код случайно и программист ожидал корректного результата, неудивительно, что возникнет ошибка.

Поскольку нам недоступен код Excel, невозможно с полной уверенностью сказать, как выглядела ошибка в этом случае, но вероятность связи с особенностями числа 65 536 высока. А как получилось, что баг не заметили при тестировании?

Программист и блогер Джоэл Спольски, в 1990-х сам работавший над Excel, предположил следующее. Корректность вычислений тестируют преимущественно автоматическими средствами, которые получают результат вычисления напрямую от кода, а не смотрят на монитор. И поскольку сам результат был корректным, а ошибка возникала уже на этапе отображения, при таком тестировании она осталась незамеченной. Так мы снова видим, что при всей пользе автоматики с ней можно упустить какие-то факторы.

Ariane 5

Ariane 5 в 2018 году arianespace.com

В 1996 году, во время пробного запуска, ракета Ariane 5 взорвалась через полминуты после старта. А в космических запусках ошибка может обходиться в такие суммы, что по сравнению с ними смартфон за $2000 сразу перестаёт выглядеть дорогим.

Что именно произошло? Как выяснилось, проблема была такой: 16-битной переменной присваивалось слишком большое для неё значение. То есть сыграла роль та самая типичная ошибка, о которой мы написали выше в истории про Excel.

И напрашивается примерно тот же вопрос, что и в случае с Samsung: «Там не тестируют, что ли?» Если возможные потери настолько высоки, как такая распространённая ошибка могла добраться до реального запуска?

Тут мы тоже не видим процесс изнутри и не можем сделать полных выводов, но пару моментов можем отметить.

Один в следующем. Конечно, в таких системах все компоненты по возможности проверяют заранее. Но после их тестирования необходимо проверить взаимодействие системы в целом, и на этом этапе могут вылезти неожиданные проблемы, никак не проявлявшиеся до этого. Среди тестировщиков популярна картинка о том, что даже на тонущем «Титанике» отдельные компоненты по-прежнему рапортовали бы об успешном прохождении тестов:

Поэтому, сколько ни проверяй софт для ракеты, что-то узнаешь только тогда, когда попробуешь её запустить. Это неотъемлемая часть процесса тестирования. А поскольку в случае с Ariane 5 запуск был пробным, собственно, это и было тестированием. Просто оно получилось очень дорогим.

Второй значимый момент в следующем. Как оказалось, вообще-то программисты, добавившие в код эту переменную, задумывались о её ограничениях. Просто этот код они изначально писали для другой ракеты — Ariane 4, а в её случае значение этой переменной никогда не превысило бы максимального значения и волноваться было не о чем.

Позже тот же код было решено переиспользовать в Ariane 5. Вот только характеристики новой ракеты существенно отличались, поэтому и значения оказались другими.

Это учит нас важности регрессионного тестирования: если сегодня код тщательно протестирован и отлично работает, это не значит, что завтра, при изменившихся внешних обстоятельствах, он продолжит работать так же. Требуется не только проверять, но и перепроверять.

Windows 10

Казалось бы, вот уж где должны тестировать тщательнее некуда: когда от работы системы зависит весь мир, о её стабильности явно задумываются.

Но в октябре прошлого года, после очередного обновления Windows, возникла ситуация, когда ОС в некоторых случаях удаляла пользовательские файлы. Сразу после известия об ошибке в Microsoft приостановили распространение новой версии, проблема затронула немногих.

Но масштаб произошедшего всё равно поражает. Одно дело, когда операционная система просто не выполняет какую-то задачу, и совсем другое — когда она производит разрушительные (и в части случаев необратимые) действия. В чём была проблема и как такое вообще могло добраться до рынка?

У Microsoft есть специальная запись, объясняющая ситуацию (вкратце: если стандартные директории вроде «Мои документы» вместо своего обычного размещения перенаправлялись куда-то, то исходная папка удалялась, хотя в ней могли оставаться пользовательские файлы). Но похоже, эта ошибка — лишь симптом другой, более общей проблемы.

Журналист Питер Брайт, годами наблюдающий за развитием Microsoft и освещающий его на сайте Ars Technica, считает, что в компании есть громадная проблема с процессом разработки и тестирования. Ранее новая версия Windows готовилась годами, позволяя спокойно всё доделать и оттестировать (из этих нескольких лет написание нового кода занимало всего лишь несколько недель).

Затем весь мир ускорился, у других пользовательских ОС обновления стали ежегодными, и в Microsoft с выходом Windows 10 тоже перешли от подхода «одна большая версия в несколько лет» к частым инкрементальным обновлениям.

Вот только внутренние процессы при этом не перестроили соответствующим образом, компания не стала «аджайлной». А короткому релизному циклу такое попросту не подходит — неизбежно возникают проблемы.

В начале апреля Брайт написал, что сейчас Microsoft делает очень многое для того, чтобы с майским обновлением не повторилось октябрьское фиаско и всё было как следует оттестировано.

А буквально на днях появилась новость, что из-за нового бага майское обновление отказывается устанавливаться на компьютер, если к нему подключен флэш-накопитель. Ну, это лучше, чем удаление пользовательских файлов. Но в вопросах тестирования, похоже, Microsoft по-прежнему есть к чему стремиться.

Справедливости ради, у Apple всё тоже далеко от идеала: в 2017 году об уязвимости в macOS писали с подзаголовками вроде «поразительно ужасный баг».

В начале текста были заявлены «Fold и ещё три продукта», но, поскольку в одном пункте объединены Pentium и Excel, фактически описаны четыре. Если вы при чтении сами заметили эту нестыковку и уже готовились написать комментарий об ошибке, вы, похоже, настоящий тестировщик. В таком случае вам может быть интересно, что скоро мы проводим в Петербурге конференцию по тестированию Heisenbug.

0
6 комментариев
Написать комментарий...
Альберт Штерн

Такие складные телефоны наверняка должны умереть как планшеты

Ответить
Развернуть ветку
Pavel Zamyatin

Напомните, когда планшеты успели умереть?

Ответить
Развернуть ветку
Дмитрий Каулькин

На самом деле жаль, что планшеты развиваются медленнее чем смартфоны. Совсем не умрут конечно, но ассортимент не радует.

Ответить
Развернуть ветку
Alla Vergun

Think Boing 737 max should be included into this list too

Ответить
Развернуть ветку
JUG Ru Group
Автор

Мы думали об этом варианте, но там ещё идёт расследование, поэтому пока что не вся информация доступна.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Вадим Клюев

почему? у моего друга вообще была слабость к таким мини-компам - и клавиатура крупная - как раз под его пальцы, и удобно работать, и характеристики выше, чем у смартов-одногодок, еле убедили его уйти с нокии n97 на современный смарт и то бурчит, чтоне усовершенствовали эту модель в свое время

Ответить
Развернуть ветку
Читать все 6 комментариев
null