Как с этим жить?
Продуктов без багов не бывает, бывает лишь различная степень толерантности к ним. Последняя зависит от сферы, в которой функционирует ваше ПО. Например, если вы пишете код для бортового компьютера космического корабля, логично предположить, что толерантность к багам будет нулевой. Тем не менее, когда на гитхабе опубликовали исходный код программы для бортового управляющего компьютера «Аполлона-11», пользователи сервиса нашли места, которые можно было поправить. Пусть это были баги уровня опечатки (и расширения для спасения Мэтта Деймона, но их мы в расчет не берем), но они присутствовали.

Наличие незакрытых тикетов в багтрекере – это не свидетельство некомпетентности и не трагедия. Да, здесь автор немного драматизирует, прочитав на stackexchage трэд о том, как стать zero-bug programmer (ответ: не писать код или найти себе плохих тестировщиков).

Более того, если у вас много неисправленных багов, вы знаете о них и приняли осознанное решение не вносить правку – это здорово! Вы знаете ваш продукт и готовы ко всему!


Судьба бага
Этика и профессиональная гордость подсказывают нам, что необходимо фиксить все баги, которые мы можем найти, но реальность оказывается сложнее. Есть два типа багов:
• баги, которые нельзя не поправить;
• все остальные.

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

В эссе основателя Source Gear Эрика Синка My life as a Сode Economist автор предлагает задавать себе по поводу каждого бага четыре вопроса:

1. Степень критичности: когда этот баг повторяется, каков его негативный эффект и насколько он критичен для системы?
2. Частота: как часто он повторяется?
3. Цена: сколько усилий и ресурсов нам потребуется, чтобы поправить этот баг (пока мы правим баги, мы не делаем что-то новое)?
4. Риск: чем мы рискуем, когда правим этот баг (любое изменение кода – это риск)?

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

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

Несколько месяцев назад я сделал другой канал. Тема нового канала шире и, главное, проще для меня – пишу и делаю репосты вообще всего, что меня заинтересовало. Пока канал больше похож на мою личную записную книжку, но вы можете подписаться. Буду рад каждому, но не обещаю радовать регулярностью. Зато досаждать частыми уведомлениями тоже не буду :)

Ссылка вот: https://xn--r1a.website/iwannasaysmth

Так уж вышло, что я решил сосредоточиться на неразвитии и теперь просто скидываю мемы в своём микро-канале:
https://xn--r1a.website/another_meme_channel ❤️

и нет, это не скам. Я реально пытаюсь привлечь больше подпищеков )