Автор: Джеймс Уэдли (James Wadley)
Оригинал статьи
Перевод: Ольга Алифанова

Ловкость рук и никакого обмана: что такое Гейзенбаг?

Сталкивались ли вы с дефектом, который, казалось бы, отрицает логику и увиливает от всех попыток его воспроизвести?

Если ваш ответ «Да», то уверяю, вы не одиноки.

Такие дефекты часто всплывают при вроде бы случайном наборе условий – то есть у нас нет надежного способа выявить необходимые для воспроизведения шаги. Зачастую единственная информация, которой мы располагаем – это невнятное описание вроде «Я столкнулся с этим, следуя определенному процессу, но с тех пор проблем не было».

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

Чем внимательнее смотришь, тем хуже становится: эффект наблюдателя

Термин «Гейзенбаг» - это шуточный парафраз имени Вернера Гейзенберга, широко известного физика, который первым открыл эффект наблюдателя в квантовой механике.

«Эффект наблюдателя (не путать с принципом неопределенности) гласит, что наблюдение за ситуацией или феноменом непременно меняет их. Эффекты наблюдателя особенно распространены в физике: наблюдение и неопределенность – фундаментальный аспект современной квантовой механики. Эффекты наблюдателя хорошо известны и в других областях – например, социологии, психологии, лингвистике и компьютерных науках». The Observer Effect: IEEE статья, K. Baclawski et al.

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

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

Пример Гейзенбага: история об отказе синхронизации

Как появляются дефекты синхронизации

Представьте, что вам нужно протестировать приложение с многопоточностью – методом запуска, который позволяет создавать несколько цепочек внутри процесса. Каждая цепочка выполняетс самостоятельно, но делит ресурсы с другими цепочками. Создание такого приложения требует тщательного программирования, дабы избежать потенциальных проблем вроде состояния гонки и взаимоблокировки. Multithreading: Techopedia, статья Маргарет Руз

В коде приложения разработчики создают функцию, которая модифицирует общую переменную счетчика. В идеале разработчики пользуются синхронизацией, чтобы убедиться, что каждая цепочка достигает определенной точки в операциях по отношению к другим цепочкам, прежде чем продолжиться. Однако при отсутствии синхронизации обе цепочки смогут одновременно изменять общий счетчик. Документация IBM: Техники синхронизации цепочек.

Проще говоря, ситуация такая:

У нас есть переменная-счетчик, начинающаяся со значения 0. Первая цепочка обновляет ее до 1, и в то же самое время вторая цепочка обновляет ее до 2.

Какое значение считается верным?

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

Эффект наблюдателя в действии

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

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

Парируем аргумент «на моей машине все работает»

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

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

Что делать команде разработки?

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

У Ministry of Testing есть фантастическая статья Рауля Парваля «Приручаем невоспроизводимые баги: ищем возможности в хаосе» - там есть отличные идеи, как исследовать такие дефекты.

Но я хочу обсудить ситуацию, когда дефект остается невоспроизводимым.

Командное понимание контекста дефекта

“Контекст: ситуация, в которой что-то происходит, помогающая вам понять происходящее.“ - Oxford Learners Dictionaries

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

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

Оценка потенциального влияния

• Оцените потенциальную серьезность дефекта. Если он может привести к потере данных, уязвимостям безопасности или значительным помехам для пользователя, он может заслуживать дальнейшего изучения, даже если воспроизвести его трудно.
• Подумайте о частоте вероятного появления дефекта. Редкий, но разрушительный дефект все еще может заслуживать изучения, а редкий минорный – нет.

Оценка окупаемости продолжения изучения

• Оцените, сколько времени и сил уходит на попытки воспроизвести дефект. Если усилия непропорциональны потенциальным последствиям – возможно, продолжать смысла нет.
• Подумайте, какие задачи или улучшения вы упустите или отложите, если команда сконцентрируется на воспроизведении одного-единственного дефекта. Иногда гораздо разумнее сконцентрироваться на известных, воспроизводимых проблемах или новых фичах.

Сбор всей доступной информации

• Убедитесь, что детали дефекта задокументированы и сообщены команде. Это включает ожидаемое и фактическое поведение, место, где вы заметили проблему, информацию об окружении (версию ПО, ОС, оборудование, настройки), частоту появления, и любую другую релевантную информацию.
• Проверьте, что у вас достаточно логов, сообщений об ошибках или данных телеметрии. Если информации почти нет, будет сложно двигаться дальше. Как уже упоминалось, статистика и прочая информация для таких дефектов не всегда доступны, поэтому команда не должна полагаться исключительно на логи.
• Иногда конечный пользователь может дать ценную информацию или рассказать о паттернах, помогающих воспроизвести проблему. Если пользователи систематически сообщают о ней, стоит копнуть глубже.
• Попросите совета у людей внутри и вовне вашей организации. Возможно, вы не единственные, кто столкнулся с этой проблемой. Поищите ее в Интернете, поговорите с другими командами в компании, поищите баг-репорты в сети (к примеру, задачи GitHub). Возможно, вы найдете хорошую документацию проблемы и информацию о том, как ее воспроизвести, в репозиториях сторонних пакетов и ПО с открытым исходным кодом.

Мониторинг системы и снижение потенциального вреда дефекта

• Можно ли внедрить обходной путь или меры предосторожности, снижающие потенциальный вред дефекта? К примеру, если вы используете сторонний пакет в коде, а дефект живет в этом пакете, можно ли внедрить совершенно другой пакет, решающий вопрос? Это устраняет нужду в изучении бага.
• Настройте мониторинг на захват более детальной информации – на случай, если дефект снова всплывет. Это, возможно, даст улики для детального расследования.
• Подумайте о создании автоматизированных скриптов, реагирующих на специфические слова или объекты, и настройте их периодический прогон днем и ночью. Возможно, это поможет разобраться, что именно приводит к появлению проблемы. Эту информацию можно затем сопоставить с другими сервисами и действиями, срабатывающими в фоне – например, бэкапом или обновлениями антивируса.

Совмещение приоритетов команды и заказчика

• Подумайте, не испортит ли дефект жизнь пользователю или заказчику, если позднее выплывет на проде. Если дефект высокоприоритетен для пользователей или бизнеса – это оправдывает дальнейшие усилия.
• Убедитесь, что команда полностью в курсе дела, и сотрудничайте с ней, принимая решение, продолжать ли охоту. Иногда свежий взгляд – это очень важно.

Заключение: стоит ли пытаться ущучить Гейзенбаг?

Процесс принятия решения, стоит ли тратить время на исследование Гейзенбага, должен быть коллективным и задействовать всех заинтересованных лиц, включая разработчиков, QA-инженеров, менеджеров продукта, и даже, если это допустимо, конечных пользователей. В этом случае будут рассмотрены разнообразные точки зрения, и результат будет лучше информирован и правильнее сбалансирован. Более того, образ мыслей, при котором каждый дефект, даже сложный в воспроизведении – это возможность усилить командный навык дебага, улучшит качество вашего ПО на длинной дистанции.

В конечном итоге выбор, продолжать расследование или прекратить, должен опираться на сбалансированную позицию по вопросам риска, опыта пользователя и эффективности ресурсов. Работа с такими дефектами – это не только про исправление горящей проблемы. Это еще и про развитие сотрудничества, улучшающего разработку, что в результате даст вам более устойчивое, надежное ПО.

Дополнительная информация

• YouTube: Quantum Observer Effect: Can 'Looking' at Something CHANGE Reality?
• YouTube: Quantum Physics: Observer Effect w/ Neil deGrasse Tyson
• Как выявить плавающие баги при помощи периодической автоматизации, Пол Гриззаффи
• Ten Reasons The Whole Team Owns Defects, Kate Paulk