Анатомия бага: от обнаружения до исправления

Работа с багами — это ключевая компетенция любого QA-специалиста. Понимание того, что такое баг, как он живёт, как правильно его задокументировать и отследить — фундамент профессионального тестирования. В этом подробном руководстве мы разберём все аспекты работы с дефектами программного обеспечения.

Что такое баг: определение и типология

Определение бага

Баг (Bug, Defect, Issue) — это отклонение фактического результата работы программы от ожидаемого результата, описанного в требованиях, спецификациях или логике здравого смысла.

Формальное определение по ISTQB: Дефект — это несовершенство или недостаток в рабочем продукте, при котором он не соответствует своим требованиям или спецификациям.

Типы багов

1. Функциональные баги — нарушение функциональности приложения:

Функция не работает вообще
Функция работает неправильно
Функция работает не по спецификации
Отсутствует заявленная функциональность

Пример: Кнопка “Добавить в корзину” не добавляет товар, а перенаправляет на главную страницу.

2. UI/UX баги — проблемы с интерфейсом:

Несоответствие дизайн-макетам
Проблемы с выравниванием, отступами, шрифтами
Неработающие элементы интерфейса
Плохая адаптивность (responsive design)
Проблемы с цветовой схемой, контрастностью

Пример: На мобильных устройствах текст выходит за границы экрана, кнопки перекрывают друг друга.

3. Логические баги — ошибки в бизнес-логике:

Неправильные вычисления
Некорректная обработка условий
Ошибки в формулах
Нарушение бизнес-правил

Пример: При оформлении заказа применяется скидка 20% вместо заявленных 10%, что приводит к убыткам компании.

4. Баги производительности — проблемы со скоростью и ресурсами:

Медленная загрузка страниц
Высокое потребление CPU/памяти
Утечки памяти (memory leaks)
Долгое выполнение запросов

Пример: Страница каталога загружается 15 секунд вместо требуемых 2 секунд.

5. Баги безопасности — уязвимости, угрожающие данным:

SQL injection
(как обсуждается в Testing Principles: 7 Golden Rules of ISTQB) XSS (Cross-Site Scripting)
CSRF (Cross-Site Request Forgery)
Проблемы с аутентификацией и авторизацией
Утечки данных

Пример: API endpoint возвращает данные всех пользователей без проверки прав доступа.

6. Баги совместимости — проблемы на разных платформах:

Не работает в определённом браузере
Проблемы на iOS/Android
Несовместимость с версиями ОС
Конфликты с другим ПО

Пример: Приложение крашится на iOS 14, но работает на iOS 15+.

7. Локализационные баги — проблемы с переводами:

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

Пример: Приложение показывает даты в формате MM/DD/YYYY для всех регионов, включая Европу, где принят формат DD/MM/YYYY.

Жизненный цикл бага (Bug Life Cycle)

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

Классический Bug Life Cycle

1. New (Новый)

Тестировщик обнаружил и задокументировал баг
Баг ещё не был просмотрен командой
Ожидает триажа (triage)

2. Open / Assigned (Открыт / Назначен)

Баг прошёл триаж
Признан валидным дефектом
Назначен разработчику для исправления
Установлен приоритет и severity

3. In Progress (В работе)

Разработчик начал работу над исправлением
Баг находится в активной разработке
Может требоваться дополнительная информация

4. Fixed (Исправлен)

Разработчик завершил исправление
Код закоммичен и смержен
Баг готов для проверки тестировщиком
Указан билд/версия, в которой исправлен

5. Pending Retest (Ожидает повторного тестирования)

Исправление развёрнуто в тестовом окружении
Ожидает проверки тестировщиком
Может быть включён в релиз-кандидат

6. Retest (Повторное тестирование)

Тестировщик активно проверяет исправление
Выполняется ретест оригинального сценария
Проверяются смежные области (regression)

7. Verified / Closed (Подтверждён / Закрыт)

Тестировщик подтвердил, что баг исправлен
Функциональность работает корректно
Не выявлено побочных эффектов
Баг закрыт

Альтернативные статусы

Rejected / Invalid (Отклонён / Невалиден)

Поведение соответствует требованиям
Проблема не воспроизводится
Является задачей (task), а не багом
Дубликат существующего бага

Cannot Reproduce (Не воспроизводится)

Разработчик не может воспроизвести проблему
Требуется дополнительная информация от тестировщика
Может быть связано с конкретным окружением

Deferred / Postponed (Отложен)

Баг признан валидным, но исправление отложено
Не критичен для текущего релиза
Будет исправлен в будущих версиях
Добавлен в backlog

Won’t Fix (Не будет исправлен)

Исправление слишком дорогое
Влияет на крайне редкий edge case
Устаревшая функциональность будет удалена
Бизнес решил не инвестировать в исправление

Reopened (Переоткрыт)

Баг не был исправлен полностью
Проблема проявляется в других сценариях
Регрессия после другого изменения
Возвращается разработчику

Диаграмма жизненного цикла

New → Open/Assigned → In Progress → Fixed → Retest → Verified/Closed
  ↓         ↓              ↓           ↓        ↓
  └→ Rejected              └→ Cannot Reproduce  └→ Reopened → (возврат в In Progress)
            ↓
            └→ Deferred/Won't Fix

Классификация багов: Severity и Priority

Правильная классификация багов критична для эффективного управления дефектами и приоритизации работы команды.

Severity (Серьёзность) — техническое влияние

Severity измеряет техническое влияние бага на систему. Это объективная характеристика.

Critical / Blocker (Критический / Блокирующий)

Приложение крашится или полностью недоступно
Потеря или повреждение данных
Критичная безопасность (security breach)
Блокирует продолжение тестирования
Делает основную функциональность недоступной

Примеры:

Пользователи не могут войти в систему
При оформлении заказа деньги списываются дважды
База данных production удаляется при определённом действии
SQL (как обсуждается в Security Testing for QA: A Practical Guide) injection позволяет получить доступ к данным всех пользователей

Major / High (Значительный / Высокий)

Существенная функциональность работает неправильно
Есть workaround, но неудобный
Влияет на большинство пользователей
Значительное отклонение от требований

Примеры:

Поиск не работает, но пользователи могут найти товары через категории
Email-уведомления не отправляются
Экспорт данных в PDF не работает
Формы валидации пропускают некорректные данные

Medium / Normal (Средний / Нормальный)

Функциональность работает, но с недостатками
Незначительное отклонение от требований
Влияет на небольшую группу пользователей
Есть простой workaround

Примеры:

Кнопка имеет неправильный цвет
Опечатки в текстах
Небольшие проблемы с выравниванием UI
Некритичные поля не сохраняются

Low / Minor (Низкий / Незначительный)

Косметические проблемы
Не влияет на функциональность
Крайне редкие edge cases
Проблемы в неважных областях

Примеры:

Неправильный отступ в футере
Консольные warnings в DevTools
Tooltip появляется с небольшой задержкой
Некорректное отображение в устаревшем браузере

Priority (Приоритет) — бизнес-важность

Priority измеряет срочность исправления с точки зрения бизнеса. Это субъективная характеристика, зависящая от контекста.

P1 / Urgent (Срочный)

Нужно исправить немедленно
Блокирует релиз
Критично для бизнеса
Может требовать hotfix

P2 / High (Высокий)

Должен быть исправлен в текущем релизе
Важен для основного пользовательского сценария
Влияет на ключевые метрики

P3 / Medium (Средний)

Должен быть исправлен в ближайших релизах
Включается в backlog
Исправляется при наличии ресурсов

P4 / Low (Низкий)

Nice to have
Исправляется когда есть свободное время
Может быть никогда не исправлен

Матрица Severity vs Priority

Severity ↓ / Priority →	P1 Urgent	P2 High	P3 Medium	P4 Low
Critical	Приложение не работает перед Black Friday	База крашится в редком сценарии	-	-
Major	Оплата не работает	Экспорт отчётов сломан	API медленный	-
Medium	Опечатка в названии кампании	Фильтры работают некорректно	UI баг на внутренней странице	-
Low	-	Бренд-цвет неточный	Отступ неправильный	Консольное предупреждение

Важно понимать:

High Severity + Low Priority: Критичный баг в функции, которой почти никто не пользуется
Low Severity + High Priority: Опечатка в имени CEO на главной странице сайта
Severity определяет техническую команда, Priority — продуктовая команда и бизнес

Как правильно репортить баги: Best Practices

Качество баг-репорта напрямую влияет на скорость исправления. Плохой баг-репорт = потерянное время команды.

Обязательные элементы баг-репорта

1. Краткое, но информативное название (Summary)

❌ Плохо:

“Не работает”
“Баг на странице логина”
“Проблема с кнопкой”

✅ Хорошо:

“Login button does not respond on iOS Safari 15.2”
“Payment form accepts expired credit cards”
“Dashboard crashes when loading >1000 records”

Формула: [Область] Что не работает при каких условиях

2. Окружение (Environment)

Операционная система: Windows 11, macOS 14.2, iOS 17.1
Браузер и версия: Chrome 120.0.6099, Safari 17.2
Версия приложения: 2.5.3 (build 456)
URL: https://app.example.com/dashboard
Тип устройства: iPhone 15 Pro, Desktop 1920x1080
Network conditions: WiFi, 4G, Offline mode

3. Шаги воспроизведения (Steps to Reproduce)

Детальная пошаговая инструкция:

Prerequisites:
- User logged in as admin
- At least 5 products in cart

Steps:
1. Navigate to https://app.example.com/cart
2. Click "Apply Coupon" button
3. Enter coupon code "SAVE20"
4. Click "Apply"
5. Click "Proceed to Checkout"

Expected Result:
- Coupon discount 20% applied
- Total price reduced by 20%
- User redirected to checkout page

Actual Result:
- Coupon appears applied in UI
- Total price NOT reduced
- Error in console: "calculateDiscount is not defined"
- User CAN proceed to checkout with wrong price

Золотые правила Steps to Reproduce:

Пишите от лица пользователя, не предполагайте контекст
Каждый шаг должен быть конкретным и выполнимым
Указывайте точные данные (не “введите email”, а “введите test@example.com”)
Включайте prerequisites (предварительные условия)
Нумеруйте шаги

4. Ожидаемый и фактический результат

Всегда указывайте ОБА:

Expected Result: что должно произойти согласно требованиям
Actual Result: что происходит на самом деле

5. Severity и Priority

Указывайте обоснованно с объяснением (особенно если высокий severity/priority).

6. Прикрепления (Attachments)

Скриншоты — обязательно для UI багов
Видео — для сложных сценариев, крашей, анимаций
Логи — browser console, server logs, mobile logs
Network traces — для API/network багов
Crash dumps — для крашей приложения

Инструменты:

Loom, CloudApp — для записи экрана
Chrome DevTools — для network/console логов
Postman — для API запросов

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

Frequency: Always / Sometimes / Rarely
Workaround: если есть способ обойти проблему
Related issues: ссылки на связанные баги
Impact: оценка влияния на пользователей/бизнес

Чек-лист качественного баг-репорта

✅ Краткое, информативное название
✅ Полная информация об окружении
✅ Детальные шаги воспроизведения
✅ Ожидаемый и фактический результат чётко разделены
✅ Severity и Priority обоснованы
✅ Прикреплены скриншоты/видео/логи
✅ Проверено, что баг не дубликат
✅ Баг воспроизводится стабильно
✅ Убраны лишние шаги (минимальный сценарий воспроизведения)

Типичные ошибки при репортинге

❌ Множественные баги в одном репорте

Один баг = один репорт. Не объединяйте несколько проблем.

❌ Субъективные описания

Не пишите “выглядит странно”, “работает медленно”
Пишите конкретно: “загрузка занимает 8 секунд вместо требуемых 2”

❌ Отсутствие данных для воспроизведения

“Баг при вводе email” — какого email? В каком поле? На какой странице?

❌ Эмоциональный окрас

“Ужасный баг”, “Как вообще такое могло попасть в релиз”
Будьте профессиональны и объективны

❌ Отсутствие проверки актуальности

Проверьте, что баг все ещё воспроизводится перед репортом

Примеры критических багов из реальной практики

Изучение реальных примеров помогает понять важность качественного тестирования.

1. Therac-25 (1985-1987) — Медицинский ускоритель

Что произошло: Radiation therapy machine Therac-25 имела баг в системе контроля, который при определённой последовательности действий оператора выдавал смертельную дозу радиации.

Техническая причина:

Race condition в software
Отсутствие hardware safety interlocks (полагались только на software)
Плохая обработка ошибок — система показывала непонятное сообщение “Malfunction 54”

Последствия:

6 пациентов погибли
Множество пострадавших от overdose
Судебные иски на миллионы долларов
Полная остановка использования устройства

Урок для QA:

Safety-critical системы требуют особенно тщательного тестирования
Важность понятных error messages
Hardware + Software redundancy в критических системах
Нельзя игнорировать race conditions

2. Ariane 5 (1996) — Ракета стоимостью $370M

Что произошло: Первый запуск ракеты Ariane 5 закончился самоуничтожением через 37 секунд после старта.

Техническая причина:

Integer overflow в системе навигации
Код был переиспользован из Ariane 4
В Ariane 5 скорость была выше, что вызвало overflow при конвертации 64-bit float в 16-bit integer
Exception handling привёл к shutdown обеих резервных систем одновременно

Последствия:

Потеря $370 миллионов
Уничтожение 4 научных спутников
Задержка программы на годы

Урок для QA:

Тестировать нужно в реальных условиях, а не только по старым спецификациям
Переиспользование кода требует regression testing с новыми параметрами
Критичные расчёты нужно проверять на boundary values
Redundant systems не должны падать одновременно

3. Knight Capital (2012) — $440M за 45 минут

Что произошло: Обновление trading software привело к тому, что система начала отправлять миллионы ошибочных торговых ордеров.

Техническая причина:

При деплое нового кода на 8 серверов, один сервер не был обновлён
На необновлённом сервере активировалась старая, неиспользуемая функция
Эта функция начала покупать акции по высокой цене и продавать по низкой в огромных объёмах
Ошибку заметили через 45 минут

Последствия:

$440 миллионов убытков
Компания обанкротилась и была выкуплена
SEC fines $12 миллионов

Урок для QA:

Критична важность полного deployment на всех серверах
Smoke tests после каждого deployment
Мониторинг и алерты в реальном времени
Наличие kill switch для критических систем
Testing на production-like environment

4. Toyota (2009-2011) — Unintended Acceleration

Что произошло: Автомобили Toyota неожиданно ускорялись без нажатия на педаль газа.

Техническая причина (частично подтверждено):

Stack overflow в electronic throttle control system
Недостаточное memory allocation
Плохой код: global variables, спагетти-код, недостаточные error checks
Возможные bit flips из-за cosmic rays (не шутка)

Последствия:

89 смертей (claimed)
Отзыв 9+ миллионов автомобилей
$3+ миллиардов штрафов и settlements
Огромный урон репутации

Урок для QA:

Automotive software требует строжайших стандартов (ISO 26262)
Важность code quality в embedded systems
Тестирование на electromagnetic interference
Hardware-in-the-Loop (HIL) testing обязательно
Static code analysis и code reviews критичны

5. GitHub (2012) — Удаление всех репозиториев

Что произошло: Баг в системе резервного копирования мог привести к удалению production базы данных.

Техническая причина:

Скрипт, который должен был удалять файлы из /tmp/, получил пустую переменную
В результате выполнился rm -rf / вместо rm -rf /tmp/backups/
К счастью, обнаружили на тестовой системе до production

Последствия:

Никаких (обнаружили до production)
Но это был “wake-up call” для индустрии

Урок для QA:

Всегда проверять переменные на пустые значения перед деструктивными операциями
Testing backup/recovery процедур
Никогда не запускать rm -rf с переменными без validation
Dry-run mode для критических скриптов
Code review для infrastructure code

6. AWS S3 Outage (2017) — Опечатка стоила миллиарды

Что произошло: Сотрудник AWS выполнил команду для удаления небольшого количества серверов, но случайно удалил гораздо больше, что привело к 4-часовому outage S3.

Техническая причина:

Человеческая ошибка при вводе команды
Отсутствие protection от случайного массового удаления
Recovery процесс занял несколько часов

Последствия:

Миллионы сайтов недоступны
Потери оцениваются в $150+ миллионов для всей интернет-экономики
Amazon сами потеряли около $3-4 миллионов

Урок для QA:

Даже опытные инженеры делают ошибки
Критичные операции должны требовать подтверждения
Rollback strategy должна быть быстрой
Testing disaster recovery процедур

Best Practices работы с багами в команде

1. Bug Triage

Регулярные встречи (обычно daily или несколько раз в неделю) для:

Просмотра новых багов
Валидации и приоритизации
Назначения исполнителей
Удаления дубликатов

Участники: QA Lead, Dev Lead, Product Manager

2. Bug Metrics

Отслеживайте метрики:

Bug detection rate — сколько багов находится
Bug fixing rate — сколько исправляется
Bug leakage — сколько попадает в production
Reopen rate — сколько багов переоткрывается
Average time to fix — среднее время исправления

3. Root Cause Analysis (RCA)

Для критичных багов проводите RCA:

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

4. Regression Prevention

Добавляйте автотесты для каждого значительного бага
Поддерживайте regression test suite
Проводите impact analysis при изменениях

5. Коммуникация

Используйте профессиональный тон
Фокусируйтесь на проблеме, а не на людях
Не обвиняйте (“кто написал этот код?”)
Конструктивно предлагайте решения

Заключение

Работа с багами — это искусство и наука одновременно. Качественный баг-репортинг экономит время всей команды, ускоряет исправления и улучшает качество продукта.

Ключевые выводы:

Баг — это любое отклонение от ожидаемого поведения, будь то функциональность, UI или производительность.
Понимание жизненного цикла помогает эффективно отслеживать статус и не терять дефекты.
Severity и Priority — разные вещи. Первое — техническое, второе — бизнесовое. Научитесь их различать.
Качество баг-репорта критично важно. Плохой репорт = потраченное время команды = медленное исправление = больше багов в продакшене.
Изучайте реальные примеры критических багов. История учит, ошибки стоят дорого, урок бесценен.
Работа с багами — командный процесс. Тестировщики, разработчики, менеджеры — все должны эффективно взаимодействовать.

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

Следующие шаги:

Изучите SDLC и STLC, чтобы понять, где тестирование встраивается в разработку
Ознакомьтесь с принципами тестирования для более глубокого понимания
Практикуйтесь в написании баг-репортов на реальных или учебных проектах