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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В случае с процессорами 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, предположил следующее. Корректность вычислений тестируют преимущественно автоматическими средствами, которые получают результат вычисления напрямую от кода, а не смотрят на монитор. И поскольку сам результат был корректным, а ошибка возникала уже на этапе отображения, при таком тестировании она осталась незамеченной. Так мы снова видим, что при всей пользе автоматики с ней можно упустить какие-то факторы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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