Как локализовать плавающий баг
Плавающие баги (они же гейзенбаги) — это ошибки, которые возникают спонтанно во время выполнения одних и тех же действий и при одинаковых условиях. Такое поведение наблюдалось как минимум единожды, однако это поведение мы не можем воспроизвести повторно.
Поиск плавающих багов – это достаточно сложный процесс, который требует много времени и усилий для их локализации.
В этой статье своим видением по локализации плавающих багов с нами поделится Ведущий специалист по тестированию программного обеспечения, Сергей.
Основная задача инженера по тестированию: превратить плавающий баг в обычный, найдя пути его воспроизведения и тем самым облегчить исправление на стороне разработки.
Что для этого нужно сделать?
Первое: задать вопрос «Насколько найденный баг является критичным с точки зрения работы Приложения (нарушает ли основную работу функциональности) и насколько дефект важен для Бизнеса?». Важность обоснована тем, что на поиск причинно-следственной связи понадобиться большое количество времени проектной команды, однако сам баг может быть тривиальным (например, воспроизводится 1 раз из 100 для функциональности, которая не часто используется пользователями; поиск отрывает разработку от передачи новой функциональности в промышленную эксплуатацию).
Второе: собрать и проанализировать информацию по багу. Такую как: где воспроизводится баг, при каких условиях, какие шаги для воспроизведения и т.д.
Здесь информацию можно разделить на 2 типа:
- Техническую информацию о проблеме. Например, можно:
- настроить и проанализировать полученные логи по системе, где воспроизводится баг;
- использовать программы отладки совместно с разработчиками;
- провести анализ результата мониторинга проблемы и т.д.
- Информацию, полученную от Пользователя. Данный подход хорошо применим, если найденный баг был обнаружен Пользователем. Можно запросить дополнительную информацию касательно шагов воспроизведения дефекта, выявленных дополнительных особенностей в поведении системы.
Существуют следующие подходы к локализации плавающего бага:
- Тестирование на грани возможностей. Этот метод заключается в том, чтобы проводить тестирование при крайних условиях, например, при максимальной нагрузке на систему или при использовании нестандартных настроек. Таким образом, вы можете обнаружить ошибки, которые не проявляются при обычном использовании системы. Однако этот метод может быть очень трудоемким и затратным, а также требует специализированных знаний по проведению нагрузочного тестирования и настройки окружения.
- Использование инструментов для автоматического тестирования. Этот подход позволяет использовать специальные инструменты для генерации и запуска тестовых случаев для системы. Тем самым мы можем проверить большее количество сценариев и данных за короткое время, и повысить вероятность обнаружения багов. Например, использование Selenium позволяет автоматизировать тестовые сценарии для веб-приложений, а Appium — для мобильных приложений.
- Применение техник ручного тестирования. Подход заключается в том, чтобы проводить тестирование вручную, используя различные сценарии использования системы. Например, воспроизвести тестовый сценарий в той последовательности, в которой был найден баг, далее сужать сценарий (от общего к частному) для локализации проблемы или наоборот использовать подход от частного общего (вариант зависит от контекста проблемы).
Выбор подхода зависит от конкретной ситуации, обладания специальными знаниями и возможностями их применения, наличия времени на поиск у специалиста. Важно помнить, что всему всегда есть логическое объяснение и у всего есть причинно-следственная связь. Ваша главная задача — ее найти!
Мы благодарим Сергея за уделенное время на интервью и за развернутые ответы.
Пользуясь случаем, поздравляем всех Тестировщиков с прошедшим профессиональным праздником! Желаем вам всего самого лучшего и светлого, чтобы приходили только интересные задачи и всегда были перспективы для дальнейшего развития и самосовершенствования. Спасибо за ваш труд и вклад в общее дело!
