Как совершить должностное преступление

Автор: | 03.10.2011

Сижу в офисной кухне, ем еду.

“Жрум-хрум, жрум-хрум”…

Мимо в юго-западном направлении проходит молодой надежда киевского тестирования.

~ Привет, — говорит.

~ Спасибо! отвечаю.

~ А, приятного аппетита.

~ Привет! отзываюсь.

~ Гы! Умеешь ты запутывать! 🙂

~ А то! )))

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

Дескать, баг есть, но его исправлять — это много времени нужно, а релиз на носу-с.

И мы его, милай, зарезолвим в лучшем виде, но после релиза.

А пока — не сообщай.

В общем, запутался он.

Что делать?

Если о баге не сообщить — вероятно, релиз выйдет спокойно и все будет хорошо.

~ Но при этом совершается должностное преступление, ты не сообщаешь информацию, для добывания которой тебя и пригласили в проект! — науськиваю я…

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

И будут правы, согласно канонам действующей лагерно-пацанской морали общества.

Если не сообщить, но слабо рассчитывать на то, что баг будет исправлен…

~ А не факт, что будет исправлен, — подливаю я кипящего масла в душевную морозилку. — Его же не будут учитывать в плане работ…

Вооооот!

А если этот баг потом будет задевать другой функционал?

А если этот баг найдет закащщик? Баг был найден четко по тест-кейсу…

А если вдруг ВНЕЗАПНО что-то случится?

Надо сообщать о баге. Но программист… Боится он, что ли?

Ну…

Все равно ведь про баг узнают…

Вердикт: сообщить о баге закащщику должен сам программист (с поддержкой в виде тестировщика на фоне декораций).

Если сообщить с уточнением: “Фикс займет столько-то дней, и если его фиксить, то мы рискуем не успеть сдать объект к 22 апреля* …“, то весьма вероятно, что релиз могут выпустить с багом, но учитывая риски, и фикс таки случится.

* В позднее советское время строители сдавали в эксплуатацию всякие объекты социалистической стройки не по мере готовности, а к определенным датам календаря; после чего много лет фиксили недостатки уже “по-бумаге” сданных объектов.

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

Обед закончился.

По итогам:

  1. баг учтен;
  2. сделали небольшой релиз с учетом проблем;
  3. фиксы всей области, в которой был найден баг, были запланированы на следующий релиз, бо баг там был не один, как водится;
  4. выпустили, стали фиксить.

Щастье 🙂

Как совершить должностное преступление: 9 комментариев

  1. new

    Мені розказували історію, коли на проекті були 2 багтрекери – один “білий” для замовника, а один “для себе”. Тільки ті баги, які були поревювані менеджером і одобрені постались в “білий багтрекер”… Прямо як подвійна бухгалтерія 🙂
    Мотив менеджменту був один – показати що в нас “все гуд” :)))

  2. will

    А можно выпустить релиз и приложить к нему known_bugs.txt , например =), предложив воркэраунд до появления исправляющего патча.. 🙂 Иногда, заказчики соглашаются на такое, ведь у них тоже сроки, мосты и фельетоны ))

  3. Алексей Лупан

    Иногда это нормально.
    Если над проектом работает толпа народа, то неизбежны всякие дубли или просто порожняки. Тогда разумно всем кагалом пользовать внутренним багтрекером; затем специальная тётя просматривает все сообщенные баги и принимает решение о том, которые будут переведены в трекер клиента.
    А вот если “показать, что у нас все гуд” – тогда это безусловное петросянство.

  4. Алексей Лупан

    А вот за такое следует ломать ноги и руки, если система выходит в общественное пользование 🙂
    Если система закрытого типа, то бывает допустимо.

  5. Рина

    я бы не придумала лучшего решения данной проблемы)
    хуже – могу)
    лучше – увы, будут пострадавшие.)

  6. will

    Алексей, вы скоры на расправу)..Ноги.. Руки.. переломать… Практика ведения known_bugs довольно распространена. Самое главное, чтобы в этом списке не было критичных ошибок. Но я, кажется, упоминал про воркэраунд =)
    Есть много разных способов организации релизной политики. Некоторые из них просто не допускают правок всего подряд, с некоторого момента.. Все зависит и от вендора ПО и от заказчика, а точнее от того “кто кому нужнее”. Работал я как-то в одном отечественном “гиганте” производства биллинговых систем для операторов сотовой связи (название упоминать не буду =)..ну так у них политика была ну очень жесткой.. Правда и за баги , найденные уже на “замороженных” стадиях могли довольно сильно потрепать всю вертикаль власти в компании..Да и процесс был организован настолько тщательно, что такие явления были большой редкостью, а пресловутый known_bugs был тощим..

  7. Алексей Лупан

    Я тут скор потому, что два раза натыкался на “Это же минорный баг!”, тогда как я совсем не считал баг минорным и долго думал матерился.
    В остальном – все правильно, ситуации разные.

  8. Уведомление: Рубрика «Полезное чтиво». Выпуск 5 « XP Injection

Добавить комментарий

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