Что пишут в блогах

Подписаться

Конференции

Heisenbug 2022 Spring
Большая техническая конференция по тестированию
Online — с 30 мая по 1 июня. Offline-день — 21 июня

TestDriven Conf

Профессиональная конференция по автоматизации в тестировании и рядом
27 и 28 июня, Москва, Radisson Slavyanskaya.

Что пишут в блогах (EN)

Разделы портала

Онлайн-тренинги

Как разобраться с плавающими багами
18.04.2022 00:00

Автор: Никола Линдгрен (Nicola Lindgren)
Оригинал статьи
Перевод: Ольга Алифанова

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

Ниже – ряд идей, как быть с плавающими багами.

Соберите информацию о баге

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

●        Когда баг произошел? (точное время)

●        На каком устройстве?

●        На какой операционной системе?

●        Воспроизводился ли он позднее?

●        Какое сообщение об ошибке появилось? (точная формулировка)

●        Скриншоты

●        Что конкретно было сделано перед появлением бага.

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

Посмотрите в логи

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

Логи также могут дать нам больше информации о том, что произошло, в чем была проблема.

Ограничьте исследование по времени

Легко утратить чувство времени и продолжать изучение, но ни к чему не прийти. Я склонен ограничивать исследование во времени, если я не получаю никакой дополнительной информации.

Я даю продакт-оунеру или лиду знать, что я буду разбираться с этим в течение Х минут, но припаркую задачу после того, как зафиксирую, что я пробовал и что происходило.

Что приводит меня к следующему совету…

Записывайте, что вы пробовали. Будьте точны.

То, что вам не удалось воспроизвести проблему, не значит, что ваши усилия пропали зря.

Я люблю быть точным и дословно записываю, что я пробовал (когда, на каком устройстве, и т. д.) и что происходило, а затем добавляю эти комментарии к описанию бага в баг-трекере.

Это может помочь вам (или коллегам) позднее, когда вам понадобится глубже исследовать вопрос, если с первого раза разобраться с багом не удалось.

Поработайте в паре

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

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

Обсудить в форуме