Дефект (или баг, bug) появляется тогда, когда ожидаемое поведение не совпадает с фактическим. Обычно у дефекта может быть множество причин появления, что позволяет сформулировать гипотезу появления дефекта
Термин “баг” возник из слова bug (с англ. жук, букашка) и популяризировался после случая 1947 года, когда в реле вычислительной машины Harvard Mark II обнаружили мотылька, вызвавшего сбой
Здесь важно понимать различие между фактическим поведением (тем, что произошло) и ожидаемым поведением (тем, что должно произойти)
У ожидаемого поведения может быть множество источников (например, требования, бизнес-правила или критерии проверки). Как правило, используют тестовый оракул, но если у ожидаемого поведения есть несколько источников, которые противоречивы, то требования уточняются с заказчиком. Далее фиксируются сценарий и условия воспроизведения
После этого оценивается влияние этого дефекта на пользователей. Для дефекта выделяют:
Как правило, серьезность и приоритет напрямую не связаны, например, опечатка в названии компании на главной странице имеет низкую серьезность, но высокий приоритет
Риск оценивают по серьезности и вероятности проявления дефекта, а приоритет, определяющий порядок исправления дефектов в списке, оценивают по риску и другим бизнес-факторам
Далее заполняется отчет, который описывает дефект:
Идентификатор в базе данных
Заголовок
В заголовке отчета лучше сочетать место проявления дефекта (конкретный функционал), условие и наблюдаемое отклонение. Пример заголовка “Не работает оплата” плохой, а “Оформление заказа: повторное нажатие “Оплатить” после таймаута создаёт второй заказ” - хороший
Условия, в которых проявился дефект
Условия представляют собой среду (например, устройство, браузер, ОС, сборка приложения и так далее) и состояние системы до первого шага, например, авторизация пользователя
Шаги воспроизведения
Шаги воспроизведения должны быть простыми действиями, которые приводят к дефекту. В отчете важно минимизировать шаги воспроизведения и оставить ровно те, которые позволяют воспроизвести его
Ожидаемый результат и фактическое поведение
Ожидаемое и фактическое поведение должны быть описаны конкретно и проверяемо
Свидетельства проявления дефекта (например, фото, видео, логи и другое)
Серьезность и приоритет
Статус дефекта, обычно выделяют: открытый (Open), в процессе исправления (In progress), исправленный (Fixed), подтвержденный (Verified) закрытый (Closed) и другие
Чаще всего такой отчет будет читать кто-то другой (даже если прошло несколько лет), поэтому отчет должен быть однозначным и понятным
Нередко дефекты воспроизводятся не каждый раз из-за невыявленных условий - тогда измеряют воспроизводимость - частоту проявления дефектов в одинаковых условиях (обычно записывают число из общего числа проверок, например, 3 из 10)
На воспроизводимость могут повлиять данные и состояние системы, текущее время (например, при повышенной нагрузке в пиковые часы дефект может проявляться чаще), состояние сети, конкурентные события, кэш и окружение
На основе фактов из отчета формируют гипотезу таким образом, чтобы сузить множество потенциальных причин появления дефектов. Поэтому гипотеза должна быть фальсифицируема, то есть можно придумать проверку, которая гипотезу опровергнет. Например, гипотеза “дефект проявляется только при включённом кэше” проверяется отключением кэша. В результате происходит локализация дефекта до конкретного программного слоя/компонента (например, клиент, сервер, база данных, сеть или интеграция)
Для веб-приложений в частности применяются инструменты разработчика, встроенные в браузер. В Firefox и браузерах на основе Chromium инструменты разработчика открываются по кнопке F12 и включают:
Для анализа REST API отлично подходят утилита curl или приложение Postman
Важно помнить, что HTTP-код может неточно указывать полученный результат (например, при HTTP-коде 200 тело ответа может содержать информацию о какой-либо ошибке). Помимо этого нужно учитывать сетевую конфигурацию: состояние DNS, TLS-сертификатов, наличие VPN
Для тестирования мобильных Android-приложений используется среда разработки Android Studio и инструмент журналирования Logcat. Для iOS-приложений используется среда разработки Xcode
Для диагностики настольных приложений используется “Диспетчер задач” (Task Manager) в Windows или соответствующий аналог в Linux (например, System Monitor в среде KDE или консольные утилиты top/btop). Для продвинутой диагностики используются соответствующие среды разработки, например, Visual Studio предоставляет широкий инструментарий для отладки и профилирования приложений на C++ и платформе .NET
Далее после исправления дефекта проводят повторную проверку, чтобы подтвердить его отсутствие
В итоге диагностический цикл получается таким: