Сижу в офисной кухне, ем еду.
«Жрум-хрум, жрум-хрум»…
Мимо в юго-западном направлении проходит молодой надежда киевского тестирования.
~ Привет, — говорит.
~ Спасибо! — отвечаю.
~ А, приятного аппетита.
~ Привет! — отзываюсь.
~ Гы! Умеешь ты запутывать! — 🙂
~ А то! — )))
Но если можно запутывать, то можно и распутывать. Выясняется, что с утра наш надежда киевского тестирования безнадежно застрял в сложной нравственной производственной проблеме: нашелся баг, но программист просит не сообщать о баге закащщику…
Дескать, баг есть, но его исправлять — это много времени нужно, а релиз на носу-с.
И мы его, милай, зарезолвим в лучшем виде, но после релиза.
А пока — не сообщай.
В общем, запутался он.
Что делать?
Если о баге не сообщить — вероятно, релиз выйдет спокойно и все будет хорошо.
~ Но при этом совершается должностное преступление, ты не сообщаешь информацию, для добывания которой тебя и пригласили в проект! — науськиваю я…
Если сообщить — вероятно, релиз релиз выйдет спокойно, но программисту придется неспокойно провести ряд вечеров или ночей в решении бага. И тады кирдык надежде киевского тестирования, бо будут гнобить.
И будут правы, согласно канонам действующей лагерно-пацанской морали общества.
Если не сообщить, но слабо рассчитывать на то, что баг будет исправлен…
~ А не факт, что будет исправлен, — подливаю я кипящего масла в душевную морозилку. — Его же не будут учитывать в плане работ…
Вооооот!
А если этот баг потом будет задевать другой функционал?
А если этот баг найдет закащщик? Баг был найден четко по тест-кейсу…
А если вдруг ВНЕЗАПНО что-то случится?
Надо сообщать о баге. Но программист… Боится он, что ли?
Ну…
Все равно ведь про баг узнают…
Вердикт: сообщить о баге закащщику должен сам программист (с поддержкой в виде тестировщика на фоне декораций).
Если сообщить с уточнением: «Фикс займет столько-то дней, и если его фиксить, то мы рискуем не успеть сдать объект к 22 апреля* …«, то весьма вероятно, что релиз могут выпустить с багом, но учитывая риски, и фикс таки случится.
* В позднее советское время строители сдавали в эксплуатацию всякие объекты социалистической стройки не по мере готовности, а к определенным датам календаря; после чего много лет фиксили недостатки уже «по-бумаге» сданных объектов.
Например, в течение еще двух лет достраивали «действующий» мост или крышу поликлиники, изредка читая про себя тематические фельетоны в журнале «Крокодил», и за это никого никуда не увольняли…
Обед закончился.
По итогам:
- баг учтен;
- сделали небольшой релиз с учетом проблем;
- фиксы всей области, в которой был найден баг, были запланированы на следующий релиз, бо баг там был не один, как водится;
- выпустили, стали фиксить.
Щастье 🙂
Справедливо =)
Мені розказували історію, коли на проекті були 2 багтрекери — один «білий» для замовника, а один «для себе». Тільки ті баги, які були поревювані менеджером і одобрені постались в «білий багтрекер»… Прямо як подвійна бухгалтерія 🙂
Мотив менеджменту був один — показати що в нас «все гуд» :)))
А можно выпустить релиз и приложить к нему known_bugs.txt , например =), предложив воркэраунд до появления исправляющего патча.. 🙂 Иногда, заказчики соглашаются на такое, ведь у них тоже сроки, мосты и фельетоны ))
Иногда это нормально.
Если над проектом работает толпа народа, то неизбежны всякие дубли или просто порожняки. Тогда разумно всем кагалом пользовать внутренним багтрекером; затем специальная тётя просматривает все сообщенные баги и принимает решение о том, которые будут переведены в трекер клиента.
А вот если «показать, что у нас все гуд» — тогда это безусловное петросянство.
А вот за такое следует ломать ноги и руки, если система выходит в общественное пользование 🙂
Если система закрытого типа, то бывает допустимо.
я бы не придумала лучшего решения данной проблемы)
хуже — могу)
лучше — увы, будут пострадавшие.)
Алексей, вы скоры на расправу)..Ноги.. Руки.. переломать… Практика ведения known_bugs довольно распространена. Самое главное, чтобы в этом списке не было критичных ошибок. Но я, кажется, упоминал про воркэраунд =)
Есть много разных способов организации релизной политики. Некоторые из них просто не допускают правок всего подряд, с некоторого момента.. Все зависит и от вендора ПО и от заказчика, а точнее от того «кто кому нужнее». Работал я как-то в одном отечественном «гиганте» производства биллинговых систем для операторов сотовой связи (название упоминать не буду =)..ну так у них политика была ну очень жесткой.. Правда и за баги , найденные уже на «замороженных» стадиях могли довольно сильно потрепать всю вертикаль власти в компании..Да и процесс был организован настолько тщательно, что такие явления были большой редкостью, а пресловутый known_bugs был тощим..
Я тут скор потому, что два раза натыкался на «Это же минорный баг!», тогда как я совсем не считал баг минорным и долго
думалматерился.В остальном — все правильно, ситуации разные.
Уведомление: Рубрика «Полезное чтиво». Выпуск 5 « XP Injection