Тестирование кажется сложной задачей, когда сталкиваешься с «трудными» багами. Некоторым из таких багов даны названия, отражающие их природу, названия эти специфические и редко применяемые, и услышать их можно разве что на конференциях (кстати самая авторитетная конференция по тестированию в России носит название «Гейзенбаг»). Рассмотрим несколько типов таких «хитрых» багов, и причины их возникновения.
Гейзенбаг
Приходилось ли сталкиваться с багами, которые исчезают или меняют свое поведение, как только вы пытаетесь их локализировать и внимательнее изучить? Представьте, что вы тестируете программу и натыкаетесь на ошибку, которая крэшит приложение каждый раз, когда вы пытаетесь ее воспроизвести. Однако, когда вы запускаете отладку, ошибка таинственным образом исчезает, и приложение работает безупречно.
Такие ошибки называют гейзенбагами, так как такое поведение системы в чем-то напоминает принцип неопределенности физика Вернера Гейзенберга. Подобно тому как само по себе наблюдение физика-экспериментатора за элементарными частицами может изменять их состояние, изучение тестировщиком гейзенбага может приводить к его временному исчезновению.
Иногда гейзенбаги встречаются даже в релизных версиях продуктов, а тем более в предрелизных. Чаще всего они вызваны спешкой или другими подобными человеческими факторами.
Чтобы справиться с гейзенбагами, следует тщательнее собирать и по возможности внимательнее проверять всю релевантную информацию (логи). Это позволит зафиксировать и предотвратить подобный баг до того, как он проявится. Также помогает воспроизведение бага в другой тестовой среде или системе.
Пример гейзенбага: Пользователь пожаловался в техподдержку: баланс его счета иногда отображается некорректно. Но при многократных попытках воспроизвести этот баг — баланс постоянно отображает правильное значение!
Борбаг
Баги, которые можно условно назвать «призраками, прячущимися в углах», предпочитают «прятаться в темных закоулках» программы.
В отличие от гейзенбагов, они сохраняют свое некорректное поведение постоянно — но только при определенных условиях, или при определенных входных данных.
Названные в честь модели атома физика Нильса Бора, в которой особое внимание уделялось предсказуемости, такие борбаги можно обнаружить лишь в редко вызываемых участках кода. Хотя их легче воспроизвести, чем гейзенбаги, их все равно сложно обнаруживать и устранять.
Например, вы тестируете сложный алгоритм, и, при четко определенных условиях, программа постоянно падает. Однако при запуске программы с другими данными или условиями она ведет себя совершенно нормально. Это классический сценарий борбага. Итак, такие дефекты подобны неуловимым призракам, любящим темноту, предпочитающим прятаться в самых «малопосещаемых» компилятором (или пользователем) участках кода.
Для борьбы с борбагами нужно проводить тщательное тестирование с различными типами входных данных, уделяя внимание редким (граничным) сценариям-кейсам, нестандартным пользовательским путям, и негативному тестированию.
Ответственно проведенное юнит-тестирование и исследовательское тестирование позволяет достаточно легко обнаруживать подобные «скрытные» баги.
Пример борбага: Функция в приложении выдает ошибку только при очень медленном сетевом подключении.
Мандельбаг
Эта специфическая разновидность багов названа в честь французского ученого Бенуа Мандельброта — основоположника фрактальной геометрии, отрасли науки, которая занимается вот такими удивительными вещами:
Подобные баги характеризуются чрезвычайно сложным (с точки зрения обычного тестировщика), или непредсказуемым поведением, чаще всего вызванным глубокими архитектурными дефектами системы.
Попытка устранить мандельбаг неопытным тестировщиком похожа на «бой с тенью». Даже изолировать и воспроизвести такие баги — сама по себе сложная задача; этим они походят на гейзенбаги.
Предположим, работаете в составе QA-команды, тестируете крупную систему, и столкнулись с ошибкой, которая вызывает непонятное, даже загадочное, или попросту хаотичное поведение программы. Иногда поведение системы настолько необъяснимо с точки зрения обычных тест-процессов, что устранить дефект бывает сложно даже опытному тестировщику.
При работе с мандельбагами необходимо сосредоточиться на тщательном изучении архитектуры и дизайна системы, и без помощи других команд вряд ли получится что-то сделать. Как можно более полно документируйте поведение до и во время такой ошибки, и, совместно с более опытными членами QA-команды, анализируйте причины.
Примеры мандельбагов: В некоторых популярнейших, реально легендарных видеоиграх персонажи застревают в стенах и столбах, оседланные кони стоят в воздухе, машины взлетают в небеса на ровной дороге, тело водителя растягивается на сотню метров. И судя по тому, что некоторые критические баги так и не сумели устранить даже спустя несколько лет после релиза известной «игры десятилетия», это самые настоящие мандельбаги.
Шрединбаг
Название также из мира науки, довольно широко известного в ИТ-сообществе парадокса Шредингера, то есть мысленного эксперимента Эрвина Шрёдингера. Шрединбаги — это ошибки, которые остаются «лабильными» до тех пор, пока код не будет «вскрыт» и внимательно изучен. Подобно коту Шредингера, как бы существующему в живом и мертвом состоянии одновременно, эти баги как бы произвольно «колеблются» между корректным и некорректным состоянием, пока тестировщик не приступит к проверке кода.
Названные также из-за эффекта наблюдателя (понятия более широкого, чем собственно Кот Шредингера), шрединбаги ставят тестировщика перед необходимостью, во первых, приложить существенные усилия к их поиску; обнаружить их существование путем каких-то изменений в системе, что и приводит к их проявлению — то есть «поиск бага триггерит баг».
Или, представьте, что обнаружили в программе ошибку, которая проявляется только когда пользователь выполняет очень специфическую последовательность действий. Однако, когда вы изучаете код, идя по стандартному пути пользователя (user flow), которым идет 99% пользователей, ошибка как будто бы исчезает, и программа работает совершенно нормально.
При обнаружении шрединбага следует тщательно документировать действия, которые вызывают их проявление, и особенности среды выполнения.
Проверяйте версии кода для выявления изменений, которые могли случайно «тригернуть» дефект.
Посоветуйтесь с коллегами, которые, возможно, уже сталкивались с подобным.
Пример шрединбага: Функция выдает некорректные результаты только в присутствии в системе конкретного пользователя с определенной конфигурацией и правами.
Лунный баг
Или «баг, зависящий от фазы луны» провоцируется на первый взгляд тривиальным, неопасным параметром времени (дата/время), из-за которого может возникать ошибка.
Такие, в принципе уже достаточно редкие ошибки проявляются строго в определенное время, вызывая сбои в участках кода, зависящих от временнЫх параметров.
Несмотря на редкость проявления, временнЫе баги опасны своей непредсказуемостью.
Представим критикал-ошибку, возникающую только в один день в году (и в какой — неизвестно), или в определенное время суток, например ночью, или в определенный час и минуту. Такие ошибки часто зависят от «глубоко спрятанных» в коде параметров, что затрудняет их обнаружение и воспроизведение.
Для борьбы с «лунными багами» нужно тщательно тестировать функции, зависящие от времени, проверяя различные комбинации даты и времени, разумеется, по возможности автоматизируя этот трудоемкий процесс.
Мониторьте логи, пытаясь найти какие-то закономерности, связанные с временем и датами, а также моделируйте различные временнЫе сценарии в инструментах которые позволяют это делать.
Пример лунного бага: в приложении магазина код скидки работает нормально в течение всего месяца, а в последний день каждого месяца — почему-то 0.
Статистический баг
Статистические баги не обнаруживаются при однократном прогоне, но проявляются при многократном выполнении кода, который предназначен для получения случайных (псевдослучайных) результатов.
Поскольку их входные данные непредсказуемы by design, выявление и отслеживание таких ошибок в отдельных прогонах иногда практически невозможно.
Рассмотрим программу, которая генерирует случайные числа для научного или бизнес-моделирования, и время от времени выходные данные не совпадают с ожидаемыми. Эти незначительные отклонения (которые часто имеют свойство накапливаться!), свидетельствуют о наличии статистического бага. Такие баги обычно скрываются в агрегированных данных, или в огромных массивах данных, или в сложных DS/ML-алгоритмах, что затрудняет их поиск в отдельных тестах.
Для выявления статистических багов следует сосредоточиться на стресс-тестировании и моделировании с большим количеством тщательно подобранных и разнообразных входных данных.
Также используйте специализированные инструменты статистического анализа для выявления закономерностей и отклонений в результатах.
Пример статистического бага: программа для бизнес-моделирования выдает на выходе данные с небольшими отклонениями, что приводит к некорректным результатам при проведении крупномасштабного анализа на больших данных.
Гинденбаг
Такой тип багов характеризуется не сложностью обнаружения, не «хитростью», как предыдущие баги, а реально катастрофическими последствиями, особенно если речь идет о критически важной инфраструктуре, или убытках на миллиарды долларов.
Баг Хиггса
Специфический тип бага, существование которого предсказано, или предвидится, или он даже был обнаружен, по единичным сообщениям пользователей, но на практике ни тестировщику, ни разработчику обнаружить его не удается — и все работает идеально. Или же баг существует сугубо «теоретически», он как бы должен быть, поскольку на логическом уровне в программном коде есть ошибка, но по каким-либо причинам он не может проявиться, поэтому ни разу не наблюдался.
