9 September 2013

Хит-парад факапов: top-5 наших любимых багов в честь Дня тестировщика

Maxifier Development corporate blogIT systems testing
Иллюстрация В Интернете уже есть немало подборок очень интересных багов – самых забавных и тех, что принесли максимальный урон (например, здесь).

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

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

Здесь я осознанно не привожу случаи, когда проблема на стороне пользователя или связана с недопониманием продавца, такие ситуации, конечно, заслуживают отдельного исследования, а сегодня – только наши собственные ошибки и ляпы.

Чтобы сохранять некоторую интригу, каждый случай будет состоять из двух частей – как это выглядело изначально, и что мы выяснили в итоге.
Итак —


5. Дежавю с непредсказуемым эффектом


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

Ситуация была бы понятна, если бы мы, например, только что поставили мажорный релиз. Или если бы упал только один клиент. Или, на худой конец, все клиенты в одном и том же дата-центре. Но никаких изменений мы на клиентских серверах давно не делали, и между всеми случаями не было ничего общего, пока…

Что на самом деле:
… пока, как обычно и бывает, мы не разобрались в логах. Поскольку приложение наше очень ресурсоемкое, то большинство расчетов осуществляется по ночам – с тем, чтобы к утру пользователи уже получили свежие рекомендации по улучшению сети. Плюс исходные данные за предыдущий день бывают готовы не раньше 1-2 часов ночи.

И вот синхронизация и расчеты, как обычно, дождались часа Х, готовности данных, и запустились на обновление. А потом, ровно в 3 часа ночи, по всей Европе сервера переключились на час назад, на зимнее время.

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

4. Здесь был Вася!


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

Что на самом деле:
Сначала мы впадаем в полное недоумение, ибо рекламироваться совершенно не собирались. А потом кто-то догадался заглянуть на сайт клиента. И увидел там, на главной странице, логотип Максифайера. Чего в принципе быть не должно никогда.

Разгадка оказалась банальной и обидной. Тестовая рекламная кампания, которая требовалась нам для отладки алгоритмов, по ошибке оказалась запущена не на нашем собственном тестовом сайте, а на всей рекламной сети клиента. Правда, если быть абсолютно точным, случилось это из-за недокументированной особенности рекламного сервера при определенном виде таргетинга, которую мы как раз и нечаянно вскрыли в процессе тестирования. В результате этой милой ошибки мы показали свой логотип в течение дня по всей Европе порядка 5 млн раз.

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

3. Верить в наше время нельзя никому. Мне — можно!


Как это выглядело:
У нас демо-показ для стратегического клиента. Стандартное демо ему не подходит, как обычно, продажники хотят продемонстрировать всё самое новое, то, что еще вчера существовало только в головах, а сегодня, еще неуверенно, в коде.

Мы, в мыле и пене, устанавливаем версию. До показа полчаса. Приходит письмо от одного из наших продавцов: «Слушайте, я знаю, что наша система очень-очень интеллектуальная и анализирует все зависимости сети так, как человек никогда не сможет. И то, что она предсказывает точнее – я тоже понимаю. Но вот передо мной на экране список рекомендаций с прогнозом. И для всех рекомендаций прогноз отрицательный. Я, конечно, понимаю, что наша система что-то такое важное знает и поэтому предлагает их к применению. Но вы не могли бы и мне подсказать, что отвечать заказчику, если спросит?»

Что на самом деле:
Ну а что можно успеть за полчаса, если ты неожиданно понимаешь, что в систему прогноза вкрался баг, и теперь она выдает некорректные значения (читай – полную туфту). А ведь там не только значения, там ведь и графики прогноза рисуются. Баг непонятно где, за такой срок ничего не пофиксить. А увеличить шанс продажи продукта новому клиенту ой как хочется.

В результате мы меняем не алгоритм, а выходные данные. Рандом от небольшого плюсового значения – и вот уже все наши рекомендации генерят вполне разумные числа. Плюс несколько статических графиков, нарисованных от руки за 5 минут, – и вот уже есть визуализация хода рекламных кампаний. Далее короткий инструктаж продажника – и демо проходит на ура.

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

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

2. Моя твоя не понимайт


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

Что на самом деле:
Если быть абсолютно честным, в данном случае это не баг, а факап планирования и коммуникации. Изначально система разрабатывалась из России, но на западный рынок. И все названия и сообщения так или иначе писались на «рунглише». Конечно, уровень грамотности был достаточным, но, наверное, не идеальным. Тем не менее, клиенты привыкли, не жаловались и нормально работали с системой уже несколько лет.

А потом, в рамках улучшения продукта, мы наняли технического писателя в Нью-Йорке. И она с энтузиазмом взялась за дело. Но пока переводилась документация – все было неплохо. А потом кому-то из продавцов стала непонятна та или иная фраза из интерфейса, и пришло ЦУ – переделать все названия и пояснения так, чтобы было абсолютно корректно с точки зрения native-speaker'a.

И все названия из кратких стали избыточно-понятными. Вот только есть два нюанса – во-первых, понимала технический писатель их смысл на основе уже имеющейся документации, не всегда полной и точной (ну и плюс понять и объяснить разницу между несколькими сотнями типов улучшений, которые мы предлагаем клиенту для повышения эффективности, штука сама по себе нетривиальная. А уж объяснить это понятно…). А во-вторых, весь список соответствий между старым и новым технический писатель держал при себе.

И выдал результат в самую последнюю секунду, когда, как обычно в аврале, собирался очередной мажорный релиз. И список соответствий между старым и новым был у единственного программиста, отвечавшего за локализацию. А потом у единственного тестера – отвечавшего за проверку.

В результате клиентам пошла система, которая была сильно непривычна не только им, но и нам. И любой вопрос ставил поддержку (тоже находящуюся в России) в ступор – т.к. она просто не понимала, что же имеется в виду. И программисты ничем не могли помочь – и они видели систему в первый раз.

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

1. Как ёлочка чуть не испортила Рождество


Как это выглядело:
— Игорь, ты не поверишь, но наша ёлка порушила всю систему.
— Не понял? Ты уверен, что это сообщение вообще для меня?
— Напоминаю. Мы, в честь Рождества, решили клиентам сделать сюрприз. И поменяли иконку нашей программы на изображение ёлочки. Больше ничего в версии не менялось. Но теперь ни у одного из клиентов система не работает.
— Как??? Как вообще такое возможно?

Что на самом деле:
Как оказалось, легко, если «правильно» спроектировать систему. У нас для вычисления есть как версия с визуализацией для пользователя, так и «невидимые» версии, предназначенные исключительно для обсчета в кластерном режиме – прогнозирование и генерация рекомендаций. т.е. служебный запуск, не требующий графического интерфейса.

И вот, подменив плагин, мы его подложили ко всем версиям. В результате каждая версия инициируется в момент запуска и пытается отобразить ту самую елочку – ищет заголовок окна, title bar и прочее. А ОС и отвечает, извини, мол, не закреплено за тобой графического дисплея. И плагин выбрасывает необратимый exception, который мы не догадались перехватывать, – т.к. изначально подобной ситуации просто не предусматривалось.

Выводы, опять же, достойны Капитана Очевидности – не надо ставить версию, не протестировав, насколько бы незначительны не казались изменения. Надо ловить исключения и обрабатывать их, как бы маловероятны они не были. Ну и, разумеется, не надо делать всё в последний момент.

Я надеюсь, что все эти байки подняли вам настроение или дали пищу для размышлений. Если у вас есть любопытные или поучительные истории из собственного опыта – поделитесь, пожалуйста, в комментариях – интересно же.
Tags: баг тестирование оптимизация рекламы медийная реклама maxifier
Hubs: Maxifier Development corporate blog IT systems testing
+87
57.7k 69
Comments 39
Ads