Какие баги никогда не будут поправлены, и как с этим жить

Все продукты получаются неидеальными. Да-да! С багами! Некоторые из них никогда не будут поправлены. Произнесите это слово по слогам, чтобы почувствовать всю обреченность и окончательность этого вердикта: ни-ког-да!

Тип 1. Баги, связанные с устаревшими устройствами и программами

Если вы делаете продукт в 2018 году, нет смысла добавлять специальную верстку для Internet Explorer 6 или подстраиваться под iPhone 4. Конечно, это почти абсурдные примеры, но человек в здравом уме вряд ли будет поддерживать старое устройство или древнюю версию браузера, так как их аудитория уменьшается с каждым днем и однажды просто исчезнет.

Здесь стоит сделать оговорку: все же не стоит отсекать идею пофиксить подобный баг сразу. Все нужно соотносить с полезностью для пользователей и вашими затратами. Например, если вы потратите на фикс 10 минут, а «спасибо» вам при этом скажут десятки тысяч человек, нужно браться за работу. А вот тратить 20 часов для одного пользователя бесплатной версии, который отписался под одним из ваших постов на Хабре годичной давности, – это непродуктивное решение.

Тип 2. Баги в сторонних компонентах

У программиста может не быть компетенций для исправления ошибки, если в его решении используется сторонний компонент. Зачастую это классическая проблема «черного ящика»: три дырки на входе и три дырки на выходе, код закрыт, лицензия проприетарная. Но даже открытый исходный код не гарантирует того, что проблему в принципе можно решить. Например, разработчики ПО на основе OpenOffice не правят баги в OpenOffice, потому что знают, что просто не смогут потом его собрать.

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

Тип 2 и 3/4 . Баги, связанные с технологией

Представим ситуацию: создавая веб-приложение, вы имеете дело с ограничениями, которые накладывает браузер (например, с неспособностью распознать текущую раскладку клавиатуры).

Вот реальная ситуация: в текстовом процессоре Microsoft Word язык проверки орфографии меняется в зависимости от того, в какой раскладке вы набираете текст, в то время как в онлайн-редакторе вам придется задать язык проверки орфографии вручную. Таким образом, пытаясь вести себя как пользователь Microsoft Word (что в общем-то логично), пользователь онлайн-редактора испытает неудобства, а вы не можете ему помочь, так как находитесь в естественных границах технологии.

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

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

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

В эту же категорию попадают латентные баги, которые юзер никогда не увидит, потому что выцепить их можно только в коде.

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

Тип 4. Баги, которые сложно повторить

Как правило, это ошибка, которая повторяется при условии, что ваши GPS-координаты сообщают, что вы в Зимбабве. И вы стоите лицом на восток. По колено в воде. В новолуние. И ровно в полночь вам приходит push-уведомление.

Тип 5. Баги, которые приносят деньги

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

Тип 6. Баги, которые ни на что не влияют

Обычно это что-то незначительное: например, пустая div’ка в html-коде. Это несомненный баг, но поскольку он сидит себе и не высовывается, то и править его никто не будет.

Тип 7. Баги, за которые никто не отвечает

Если в предыдущих пунктах речь шла о багах, которые невозможно или даже не нужно править, то здесь мы поговорим о типе багов, являющихся симптомом опасной болезни. Это баги, появившиеся в процессе создания той части продукта, «на которую всем плевать» (потому что никто толком за нее не отвечает).

Абстрактный сценарий такой: несколько отделов создают общую фичу. Сначала дизайнеры нарисовали кнопку и забыли. Потом программист из отдела 1 в силу своей загруженности подготовил компонент, забыв пробросить туда кое-какие методы. Программист из отдела 2 взял готовый компонент и вставил его в продукт без исправлений. Работает? Скорее всего, работает, но при этом может, например, выглядеть уродливо. Ну а поскольку для всех героев это была всего лишь побочная задача среди сотен других, то все так и остается.

Баги, за которые никто не отвечает, могут быть довольно критичными. При этом их никто не будет фиксить до тех пор, пока пользователи молчат. И это тревожный звоночек… а может, даже целый колокол! Звонит он не только и столько по заброшенной части продукта – он звонит по организационным процессам в компании.

Как с этим жить?

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

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

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

Судьба бага

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

    • баги, которые нельзя не поправить;
    • все остальные.

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

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

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

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

Об авторе

Журналист, редактор, автор текстов об IT. Окончила НГЛУ им. Добролюбова в 2012-м году. Сотрудничала с такими изданиями, как РБК и Lifenews. О последнем говорит, что через это нужно было пройти и теперь уже ничего не страшно. С 2014 года сконцентрировалась на IT-тематике. Любимые темы - тестирование и офисное ПО. Своими главными достоинствами считает способность погрузиться и детально изучить любую тему, а затем просто и понятно рассказать обо всем читателю.

Поиск
Облако меток
8 марта (1)api (5)Game of testers (1)ISTQB FL (1)kpi (1)kpi в тестировании (1)postman (1)Quality lab. Meetup (2)regress тестирование (1)rest api (2)scrum (1)scrumban (1)smoke тестирование (1)soap api (1)sqa days (1)TDD (2)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)День защитника Отечества (1)День рождения ЛК (1)День смеха (1)Мероприятия (2)Опрос (1)ПОИНТ (3)Приёмочное тестирование (1)РИТ (1)Эльбрус (1)Юмор (2)автоматизация тестирования (7)аудит (2)аудит тестирования (2)аутсорс (5)баги (4)банковские приложения (1)бесплатный вебинар (1)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)галеры_qualitylab (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (3)ежемесячный отчет (14)интернет-магазин (1)исследовательское тестирование (2)коммуникации (4)конфликты (2)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (21)лайф-хаки (4)локализация (1)медицинское ПО (1)международные проекты (1)метрики (3)модель ситуационного лидерства (1)мотивация (3)новый год (2)обеспечение качества (13)обучение (8)оптимизация тестирования (13)оффлайн тренинги (1)поздравление (1)поздравления (6)пользовательские истории (1)пример (2)проблемы (3)проектные риски (1)проекты (4)процесс тестирования (25)развитие команды (6)разработчики (1)распределенная команда (3)решения (4)ритейл-приложения (1)сертификация ISTQB FL (1)собеседование (1)специализация (2)с чего начать (2)тест-анализ (2)тестирование (49)тестирование безопасности (3)тестирование для бизнеса (2)тестирование мобильных приложений (2)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удобство использования (2)управление проектами (4)управление рисками (1)успехи (6)целевая аудитория (3)юзабилити (3)
Получите совет