То свистит.

То не свистит.

Но когда свистит — то прям ващще…

Начал искать первопричину этого автогреха. Пару дней отсиживал в засаде (за рулём), то разгоняя машину, то адски тормозя, то петляя по улицам киевского стольного града.

И таки нашёл! 🙂

Понёс механику баг-репорт:

Уважаемые учёные по машинам,

мною, жителем киевских окраин, неоднократно замечено, что когда я еду на работу — с востока на запад — то под капотом не свистит.

А когда я еду домой — с запада на восток — то почти постоянно что-то где-то под капотом свистит.

Карта обоих маршрутов прилагается.

Прошу починить.

Ненуачо? Я ж профессиональный тестировщик, я ж доклады докладываю на конференциях, я ж умею профессионально составлять профессиональные баг-репорты.

Вот, обнаружен баг.

Вот при каких условиях он воспроизводится, скриншот прилагается.

Следственные мероприятия и полевые испытания привели меня к однозначному выводу: свистит только тогда, когда еду домой с работы, направляясь с запада на восток.

Плиз, фикс.

Механик послушал аудиозапись свиста, станцевал перед машиной ламбаду, и подтвердил мои выводы: таки да, свистело только при езде с запада на восток, и вы не сумашедший.

Но дурак.

Бо свистело не потому, что «Oh, East is East, and West is West, and never the twain shall meet» (© Rudyard Kipling, который про Маугли сочинил), а потому, что ослабло натяжение ремня генератора электрического тока, и ремень проскальзывал по направляющим ложбинкам.

Непонятно?

Каждый раз, когда я включал фары, повышалась нагрузка на генератор, и он начинал крутиться быстрее. Ремень из, мгм, полимеров… и когда его натяжение ослабло, он перестаёт плотно прилегать к железяке генератора. А железяка крутится на высокой скорости, и если ремень хоть немного «провисает», то появляется тот самый свист.

«Засвистело, и упало на столе».

А фары я включал только по вечерам, когда возвращался домой.

А домой я еду с запада на восток.

А если не знаешь, как всё устроено ИЗНУТРИ, и ведешь наблюдение только СНАРУЖИ, то как догадаться?!

Никак.

Ремень-то подтянули, делов-то, и вообще, я мог его сам починить.

А самооценку мне кто подтянет?…

Чего я об этом вспомнил: да попался мне на глаза один баг-репорт, и прям один в один… Там было исчерпывающе точное описание того, что тестировщик ВИДЕЛ, и полное игнорирование контекста, в котором случился баг, бо тестировщик о ряде положений даже не догадывался (ненуачо, тестирование же не такое сложное, как программирование, да?!).

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

Таки контекст важнее всего.

Понимание принципов «почему и как оно вообще работает» важнее знания ряда ситуаций, которые могут произойти.

Программистов жалько… Себя — нет.

Под капот надо смотреть

Обложка книги «Тестирование черного ящика»

В начале декабря 2015-го я неосторожно пообещал Никите Макарову (папа автоматизации тестирования в «Одноклассниках») объяснить, почему книга Бориса Бейзера — это про тестирование, но не для тестировщиков, а для программистов, поэтому и читать ее надо не так, как Канера.

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

Итак, да, изрядное кол-во любопытных тестировщицких зубов обломалось о книгу Бориса Бейзера «Тестирование черного ящика», йо-хо-хо!

Мои там тоже остались 🙁

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

Перевод там гнилой, что ли?

Ну…

К нашему всеобщему нажалию, на русском языке Бейзер распространяется только через уже классический перевод издательства «Питер» (2004-й год, переводчик А. Раздобарин), и после ихних тогдашних переводов там смысл того, что просто хотел автор сказать, конечно, просто так получается, что не всегда, разумеется, но если, однако же, вдуматься, то конечно же, скоро станет ясно, о чем смысл вообще и вот, безусловно, скоро всё прояснится и сразу всё станет понятным.

Будете перечитывать?

И да, оригинал «бейзера» читается намного проще и внятнее. Но где ж его взять?

Однако проблема не в качестве перевода. Почти те же глюки посещают тестировщиков и после чтения Пауля Йоргенсена (тоже очень крут, но у нас незаслуженно непопулярен) или Гленфорда Майерса (у нас на слуху, но кто ж дочитал все те листинги, которые он там понаписывал?).

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

Вкратце:

они учат тестированию программистов,

а не тестировщиков.

Например, книга Бейзера — не совсем книга, это сборник его лекций, которые он читал НЕ для быдло-кодеров, благодаря которым мы имеем чем намазывать на хлеб, респект вам, братцы, продолжайте творить!, но и не для быдло-тестировщиков (а вы, братцы, прекращайте уже дурью маяться).

Бейзер читал лекции для будущих инженеров, которые получали наивысочайшее образование по университетской программе в области компьютерных наук или программной инженерии (Дональд Кнут и вся его серия книг «Искусство программирования» вам примером). А упомянутое высочайшее образование нет смысла покупать ранее, нежели успешно освоены минимум два года среднего специального образования в области компьютерных наук, или же полный курс обучения по направлению «Программное обеспечение» в системе военного образования США.

Домашнее упражнение:

1. Оценить этот минимальный уровень врубания в тему.
2. Посмотреться в зеркало.
3. …

И Бейзер

на протяжении десяти лет провел свыше 200 технических семинаров для тысяч тестировщиков,

и Майерс

…served as a lecturer in computer science at the Polytechnic Institute of New York University, where he taught graduate-level courses in computer science,

и Йоргенсен

…since 1986, he has been teaching graduate courses in software engineering, actually in Grand Valley State University, Michigan

свои книги писали именно для этой уже изрядно подготовленной аудитории, на основе сборников своих лекций.

То есть, не для меня Дон разольется.

Все аналогичные авторы рассматривают тестирование как некую логическую дисциплину, которая направлена на ПРЕДУПРЕЖДЕНИЕ появления багов в ПО. То есть, ДО ТОГО, как пишется код.

Собственно, классическая Analytic school всего нашего тестирования ПО.

Это даже не совсем тестирование программного обеспечения, это тестирование алгоритмов, на основе которых будет написано программное обеспечение. Там даже тест-кейсы не особо нужны 🙂 Бо «предупреждение багов» в академическом смысле делается не посредством наших любимых проверок вроде

1. Открыть браузер,
2. открыть сайт,
3. кликнуть по полю Login,
4. на серьезных щщах ввести в поле ‘Login’ всякую туфту
5. и убедиться в том, что залогиниться невозможно…

Это «предупреждение» всегда делается задолго до того, как программа написана;

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

это делается посредством изучения логики будущего кода с помощью структурных (белый тезис ящик) или поведенческих аналитических методов (черный ящик);

это делается посредством разбиения всех входных данных на классы эквивалентности для каждого модуля по-отдельности, а затем и по-цепочке (получается очень смутная и объемная шняга);

это делается посредством расписывания причинно-следственных диаграмм («Мне трудно объяснить логические модели без привлечения булевой алгебры, а ее нет смысла учить, если вы не владеете диаграммами Карно-Вейча» © Борис Бейзер);

это делается тогда, когда от вероятных ошибок в ПО мир рухнет в Тартарары и еще дальше, буквально в лапы Скараоцки.

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

Про молдавские болота: долго объяснять, справок на всех вас не хватит…

Парни, которые с детства родились Шелдонами Куперами, всё это понимают органично. Всем остальным соваться в тестирование алгоритмов незачем.

И звучит всё это круто…

Однако, Петька,

есть

один

нюанс… ©

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

Увы.

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

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

Кстати… Буквально недавно на собеседовании спросил «Про пестицид эффекта», и получил обстоятельный, классический ответ.

Ну, кагбэ… Одно из главнейших качеств тестировщика — внимательность к деталям, не так ли?

Я и уточняю у бро, мол, «А ничего, что я спросил про ‘пестицид эффекта’, а не про ‘эффект пестицида’?«

Засмущалси бро, покраснел слегка /от ненависти ко мне/, а мне чо, я ж тестировщик, я привычный.

С другой стороны — ну, позитивный джун… Ну, будет писать позитивные баг-репорты…

Ожидать от выпускника такой системы обучения умения вольготно и легко тестировать замысловатые сценарии так же логично, как ожидать от выпускника консерватории способности в любое время суток «сбацать Мурку» в стиле техно-джаз. Но так же нелепо. Выпускник консерватории Мурку просто так не «сбацает». Его же восемь лет учили играть строго по нотам в окружении таких же пингвинов, как он сам, да обязательно под руководством дери, понимаешь, жора. А чтобы «бацать Мурку», надо уметь импровизировать, а импровизация — отдельная музыкальная наука, большинству «консерваторов» в принципе не требуемая.

Как не требуется водителю троллейбуса умение гонять по городу в час пик и проезжать повороты на скорости не меньше 60 км/ч.

Усредненный выпускник подобной системы образования, для которой работают Бейзер, Майерс и Йоргенсен, страдает всеми теми качествами, которые отличают владельцев высшего образования от простых парней «от сохи». Подобный студент умеет правильно оттарабанить определения терминов и умеет выполнять именно те алгоритмические расчеты, которым его обучили, не более. Феномен известный, Ричард Фейнман об этом уже смачно распространялся:

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

…я посетил лекцию в Инженерном институте. Проходила она так: «Два тела… считаются эквивалентными… если равные вращательные моменты… производят… равное ускорение. Два тела считаются эквивалентными, если равные вращательные моменты производят равное ускорение». Студенты сидели и записывали под диктовку, а когда профессор повторял предложение, они проверяли, все ли правильно записано. Потом они писали следующее предложение и еще одно, и еще одно. Только я один знал, что профессор говорил о телах с одинаковыми моментами инерции, а уяснить это было трудно.

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

После лекции я спросил одного студента:

— А какой будет экзамен?

— Очень простой. Я могу Вам прямо сейчас назвать один из вопросов, — он заглянул в тетрадь и сказал: «В каком случае два тела считаются эквивалентными?». А ответ: «Два тела считаются эквивалентными, если равные вращательные моменты производят равные ускорения».

Так что, как видите, они могли сдавать экзамены, и «учить» все это, и не знать абсолютно ничего, кроме того, что они вызубрили.

Императивы учебной программы ISTQB весьма близки к этому способу мышления, но скомпоновано всё чуууууточку проще, поэтому и подходит для многих, а не только для выпускников курса «Программное обеспечение» в системе военного образования США 🙂 Но результативность…

У меня сейчас на учебной сковородке прожаривается очередной обладатель сертификата ISTQB, который с нуля учится тому, что такое тест-кейсы и как их надо придумывать. Ну не поубивав бы?!

И опять же репрезентативное для большинства осертификаченных: «У нас на проекте все это применять не приходится«. Ещё бы… Для занятия тест-дизайном знания и умения нужны, а не сертификаты.

Почему все так неоднозначно и криво?

Ну… потому, что ТАК МОЖНО.

Если бы выпуск ПО с багами был невозможен, если бы ПО действительно нужно было ВСЕГДА тестировать так тщательно, как то подразумевает академическая выучка, то и пресловутый «быстрый вход в профессию» был бы априори невозможен, и скорость разработки была бы невелика, и качество ПО было бы очень, очень высоким.

Но миру не нужно, чтобы всё ПО было высокого качества. Миру нужно, чтобы ПО просто работало.

Поэтому можно выпускать некачественный софт — и он работает.

Просто иногда его надо постоянно обновлять. Блеать!

И поэтому МОЖНО знать, как надо тестировать, но нифига не уметь тестировать.

И также поэтому МОЖНО тестировать, не особо понимая, что именно перед тобой открыто: «браузер» или «фаерфокс»; и откуда открывается интернет-магазин, с «сайта» или с «сервера»; и технику разбиения чего-либо на классы эквивалентности объясняют/воспринимают на примере дурацких карандашей, и тем не менее, компьютеры работают, сайты открываются, цивилизация продолжается. То есть, не всё так страшно.

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

Но попробуйте выпускать обычный, некачественный софт для военщины…

Или для супер-компьютеров, которые моделируют развитие метеоусловий на масштабе континентов…

Или более приземленное: https://www.google.com.ua/advanced_search протестируйте, используя только классы эквивалентности карандашиков и вписывание лютой туфты в поля ввода…

Или, раз уж речь зашла, подумайте, как иначе, если не «по-академически основательно», можно спроектировать и протестировать инфраструктуру, на которой когда-то зижделись «Одноклассники» (она однажды ПОЛНОСТЬЮ «сыпанулась» из-за одного бага, который в принципе присутствует у всех и никому не мешает уже сто лет в обед):

…нужно было оживить около 5 000 машин. Перезагрузить их удалённо и загрузить по сети было нельзя, поскольку многие просто не были для этого сконфигурированы. Это было следствием выбранного когда-то подхода к созданию инфраструктуры. Ведь Одноклассники не развёртывали на пустом месте единовременно несколько тысяч серверов — парк постепенно разрастался в течение нескольких лет. Поэтому пришлось вручную перезагружать тысячи серверов и разрешать в BIOS управление по сети для автоматизации восстановления.

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

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

Читать Бейзера можно/надо будет когда-нибудь потом, когда/если тестировщик дорастёт до понимания сути тест-дизайна. Все те вещи, о которых говорит великий старик, можно изложить и более простым языком, более простыми образами, и когда начинаешь их понимать — о, Бейзер очень крут для постижения тест-дизайна!

Поэтому «и сейчас, и везде» будут начинающие тестировщики читать Бейзера да Йоргенсена, и удивляться тому, что за хрень там понаписале, бо непонятно.

А взрослые тестировщики будут внимательно читать Бейзера да Йоргенсена, и удивляться тому, что кто-то считает эти прекрасные книги хренью, ведь там всё так логично, так глубоко, так объемно, своевременно, и «почему же я про все это не узнал еще пять лет назад!«.

Просто взрослый тестировщик отличается от начинающего тестировщика хотя бы тем, что уже умеет хоть как-то программировать, и уже ПОНИМАЕТ, как и почему работают программы, и как и почему их надо тестировать.

\ToDo{Прекратить руководствоваться логичным, но до невозможного дурацким соображением о том, что «Но ведь если тестировщик научится программировать, то он станет программистом!!!«. Не станет. Знание английского языка не делает вас англичанином, но помогает более тонко и всеобъемлюще понимать мир и других людей}.

Next step: «Они учат тестировщиков программировать«

Здравый смысл важнее лицензий.

Магазин должен подстраиваться под ожидания покупателя, а не покупатель под условия магазина.

Протестируем не совсем очевидное — условия доставки товаров в гигантских магазинах. На примере магазина rozetka.com.ua.

Обожаю этот магазин как пример того, как НЕ ДОЛЖНО БЫТЪ, но бывает.

Лизни «Розетку», бро!

Внимательно читаем условия доставки «Розетки»:

Доставка в пределах Киева бесплатная при заказе на сумму от 1500 грн.

Стоимость доставки заказов до 1500 грн составляет 35 грн.

Что-то там ещё… бабла-бы-бла-бла…

Раскладываем пасьянс «Идеи»:

• сделать заказ на сумму 1501> грн. Доставка = бесплатная.
• сделать заказ на сумму 1500 грн. Доставка = платная, 35 грн. Походу. Ведь есть условие «от».
• сделать заказ на сумму <1499 грн. Доставка = платная, 35 грн.
• что-то ещё?

Понеслось!

1) Накидать в корзину шняжек на сумму >1500.

Хм, все хорошо, но почему «Итого 1840«?

Пересчитаем: 535+332+182+721=1770, а не 1840…

Баг?

2) Получить емайл-подтверждение заказа.

Wtf? о_О

Условие «over 1500» соблюдено…

Почему доставка указана платной? Почему доставка указана платной? Аж два раза…

Кстати, стало понятно происхождение лишних 70-ти грн — это пресловутые «35+35». Но..?

Вообще-то, да, читать условия доставки полностью, а не как обычно, надо уметь. Но кто ж учился в школе читать полностью…

Перечитаем условия доставки полностью:

Доставка в пределах Киева бесплатная при заказе на сумму от 1500 грн. Стоимость доставки заказов до 1500 грн составляет 35 грн.

Товары из раздела «Активный отдых и туризм», «Дом, сад» и «Детский мир» доставляются бесплатно при сумме заказа от 500 грн.

Товары из раздела «Бытовая техника и интерьер» по Киеву доставляются бесплатно при сумме заказа от 800 грн, стоимость доставки заказов до 800 грн составляет 35 грн. Доставка товаров из данного раздела по Киеву и Украине осуществляется отдельно от доставки товаров из других разделов сайта.

Доставка уцененных товаров не осуществляется. Уцененные товары Вы можете приобрести в нашем выставочном зале.

Хм…

При первом прочтении не проясняется никакой связи между багом и условиями доставки.

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

Согласно заявленным условиям, следует четко различать товары из разных разделов большого магазина.

Никто же в процессе тестирования не заметил, что в корзину положены товары из двух РАЗНЫХ категорий: компо-железячки и кухонный принадлежняк 😉

Получается, что согласно алгоритмам доставки «Розетки», заказ №2380815 с четырьмя товарами на борту в действительности является ДВУМЯ отдельными заказами.

Не утерпел, и поговорил непосредственно с представителем магазина. Таки да… Логистика в большом магазине всегда является отдельной песней на блатных аккордах, и её тоже надо тестировать.

Та же функциональность, даже в профиль…

🙂

В процессе участия я запоролся на слове «воркшоп». Оно ведь как переводится? Пяможитейская логика подсказывает, что речь идет о месте, где продается работа. Дык тогда каждый киевский офис — суть воркшоп…

Оказалось, что воркшоп — это цех (мастерская), в которой можно нахвататься каких-то рабочих навыков.

В общем, не суть важно.

Важное выяснилось только что: стандартный механизм добавления картинок в WordPress под FF7.01 в Ubuntu не видит в каталогах файлы, у которых расширение написано заглавными буквами.

• «файл.JPG» — не видит.
• «файл.jpg» — видит.

Андрей Дзыня в стотысячный раз основывает фреймворк для автоматизации

Важно то, что я давно не видел в офисе SysIQ столько ноутбуков с Ubuntu.

Это впечатлило.

У нас же весь офис под властью винды.

Я даже притащил в зал свой ноут, чтобы не выделяться 🙂 бо у меня ж там тоже Ubuntu, которую я никак не хочу обновлять.

Хотя иногда бессознательная тяга к обновлению системы приходит ко мне во снах и разрушает синапсы, которые отвечают за воспроизведение молдавской музыки. Ну, бывает…

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

Вот что получил:

У меня 10.10, но в справке указано 11.04.

Отлично! И обновляться не надо.

Попадание под прицел фотокорреспондента

Тем временем Михаил Поляруш объяснял воркшоповцам обстоятельства факапа стартапа, в который владельцы сразу пригласили автоматизаторов без ручных тестировщиков.

На слайде виден текст: «Заказчик хочет вы… интерациональный уровень«.

Михаил Поляруш объясняет, что "Заказчик хочет вы..."

]]> https://testitquickly.com/2011/10/16/vindem-lucrul/feed/ 8 2603 https://testitquickly.com/2009/08/17/robotii-imi-fura-o-bucata-din-memorie/ https://testitquickly.com/2009/08/17/robotii-imi-fura-o-bucata-din-memorie/#comments Mon, 17 Aug 2009 13:28:40 +0000 http://testitquickly.com/?p=1103 Читать далее: Баг в роботах на космодроме »]]> Это пришло ко мне из ниоткуда. То есть, из памяти.

Кстати, о бифштексах.

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

Мне пришлось на полчаса оторваться от письма и выслушать сетования моего соседа, кибернетиста Щербакова. Ты, вероятно, знаешь, что к северу от ракетодрома идет строительство грандиозного подземного комбината по переработке урана и трансуранитов. Люди работают в шесть смен. Роботы — круглые сутки; замечательные машины, последнее слово практической кибернетики. Но, как говорят японцы, обезьяна тоже падает с дерева.

Сейчас ко мне пришел Щербаков, злой, как черт, и сообщил, что банда этих механических идиотов (его собственные слова) сегодня ночью растащила один из крупных складов руды, приняв его, очевидно, за необычайно богатое месторождение. Программы у роботов были разные, поэтому к утру часть склада оказалась в пакгаузах ракетодрома, часть — у входа в геологическое управление, а часть вообще неизвестно где. Поиски продолжаются.

Я как мог утешил Щербакова (чуть не умер от напряжения, стараясь сохранить серьезный вид) — и вернулся к письму.

[…]

Прощай, краснолицый! Надеюсь, не пройдет и двух лет, как ты напишешь мне.

Большой привет супруге и сынишке. Да поцелуй-ка, брат, супруге ручку.

Твой В. Юрковский

Венера, Порт Голконда

7.02.19.. г.

Источник.

Роботы вообще делали именно то, что должны были делать — верх фантастики.

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

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

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

Вот только финал переводом оказался слегка подпорченным. Оказалось непереводимой игра слов «Ту-ут, ту-ут, ту-ут», — пели далекие маяки.

Ну, что поделать…

Быков, красный, потный и взволнованный, висел в воздухе вниз головой.

Официальщина:

«Не могу воспроизвести» означает только то, что работник, ответственный за починку дефекта, не смог его воспроизвести на билде, указанном в описании дефекта.

Почему не смог?

1. Из-за разницы в конфигурации компьютеровВ веб-отрасли это бывает реже, чем в десктопных приложениях. Но бывает. Но редко.
2. В описании бага отсутствуют какие-то шаги или нюансыА вот это очень серьезно, и идет прямым минусом в карму тестировщику. После ревью баг будет переоткрыт, что неприятно ни им, ни нам, ни этим, которые за всеми нами приглядывают.
3. Дефект уже починен в более новом билде, а девелопер как раз и проверяет это дело на этот самом «обновленном»Это самое противное и требующее рассмотрения.

Третья причина является проблемой из-за того, что входит в противоречие с официальным толкованием статуса «Не могу воспроизвести»:

Дефект проверяется на билде, указанном в описании дефекта.

Дефект, зарегистрированный в версии 1.9, отложен и принят к

рассмотрению в версии 1.12. Высока вероятность того, что в 1.12 он уже будет как-то починен? Если рассматривать ситуацию абстрактно, то вероятность весьма, весьма, гм, вероятна.

А если так, то является ли преступлением против системы треканья багов проверить исторический баг на новом билде, и заявить, что «не могу воспроизвести»?

Не является.

Но проверять дефект на обновленном билде, как правило — на текущем — это потенциальная брешь и проблема. Предположим, не воспроизводится. А ну как он, зараза, снова всплывет? Мы точно знаем, почему этот гадёныш не воспроизводится?

Единственно верное решение:

Поставить билд 1.9, воспроизвести, понять, отчего это произошло, и убедиться в том, что в билде 1.12 эта проблема несомненно решена. Убеждаться — в коде.

И если дефект при проверке уже считается недействительным, нужно ставить ему статус «Fixed» с указанием билда, в котором баг считается починенным.

Что в действительности — возня со старым билдом может потребовать неоправданно много времени. «Единственно верное решение» может быть использовано только в том случае, если баг приоретизирован как «серьезный».

Вышеизложенное написано в поисках уточнения: баг, который не воспроизводится на обновленном билде — он все-таки «Fixed», или «Can’t reproduce»?

Продолжаем делать баги под видом функций, нужных конечным пользователям.