---

Глава 5. Дефекты
5.1. Понятие дефекта и рекомендации к его описанию
 * Дефект (defect, bug, problem, fault) — недостаток в компоненте или системе, способный привести к ситуации отказа.
 * Классификация дефектов:
   * По степени серьёзности: критические (сбой ПО, потеря данных), значительные (снижение производительности/удобства), малозначительные (не влияют на функции, ухудшают качество).
   * По типу: функциональные (неправильная работа функций), нефункциональные (производительность, безопасность, удобство), логические (ошибки в алгоритмах).
   * По стадии возникновения: дефекты проектирования, кодирования, тестирования.
 * Методы обнаружения: ручное тестирование, автоматизированное тестирование, статический анализ кода (без запуска программы), динамический анализ кода (в процессе выполнения ПО).
 * Этапы устранения: 1. Идентификация \rightarrow 2. Разработка исправления \rightarrow 3. Внедрение исправления \rightarrow 4. Повторное тестирование.
 * Меры предотвращения: соблюдение стандартов разработки, повышение квалификации программистов, инструменты статического/динамического анализа, регулярное тестирование.
Структура описания дефекта (Баг-репорта)
> При составлении следует избегать субъективных и размытых слов: «корректный/некорректный», «правильный/неправильный», «длинный».
> 
 * Заголовок (Headline, Summary): отвечает на три вопроса: «Где?», «Что?», «Когда?».
 * Окружение (Environment): подробные технические данные без сленга (версия и сборка ОС, точная версия браузера, локаль).
 * Шаги воспроизведения (Steps to Reproduce): исчерпывающий пошаговый путь воспроизведения для персонала любой квалификации.
 * Актуальный результат (Actual Result): реальное ошибочное поведение программы.
 * Ожидаемый результат (Expected Result): правильная реакция системы согласно требованиям или спецификации.
 * Критичность (Severity): степень влияния бага на работу приложения.
 * Скриншоты (Attachments): визуальные материалы, область захвата которых однозначно раскрывает место и суть проблемы.
5.2. Уровни критичности и связь с приоритетом
 * Критичность (Severity): техническая оценка влияния дефекта на приложение. Определяется тестировщиком с точки зрения конечного пользователя.
 * Приоритет (Priority): очередность и срочность устранения ошибки разработчиками. Назначается проектным менеджером (иногда тестировщиком).
   * Взаимосвязь: Severity не определяет очередность исправления напрямую. Менеджер может присвоить малозначительному дефекту приоритет «Resolve immediately», а критическому — «Low priority», исходя из бизнес-требований.
Шкала критичности (Severity)
 * Blocker (Блокирующий): ПО полностью неработоспособно, тестирование продолжать невозможно.
 * Critical (Критический): частичная блокировка критических функций, падения системы, потеря данных, невозможность установить ПО или сбой лицензирования.
 * Major (Серьезный): существенное нарушение нормальной работы функций, некорректные расчеты, но дальнейшее тестирование возможно.
 * Average (Средний): не блокирует работу, есть обходные пути; частичные расхождения со сценарием, сбои навигации.
 * Minor (Незначительный): мелкие недочеты, не влияющие на функционал (опечатки, расхождения форматов, отступы, неверный порядок колонок).
 * Trivial (Несущественный): минимальные дефекты GUI, не ухудшающие восприятие интерфейса.
 * Enhancement (Рекомендация): предложения по улучшению функциональности или интерфейса.
5.3. Правила изменения уровней критичности
Оценка Severity субъективна и может корректироваться. Тестировщику запрещено завышать критичность исключительно ради привлечения внимания менеджера.
 * Понижение уровня допускается, если:
   * дефект воспроизводится на устаревшей/редкой ОС (например, Windows 7);
   * ошибка воспроизвелась единожды и не имеет четкого алгоритма шагов;
   * проблема затрагивает крайне редко используемый функционал.
 * Повышение уровня допускается, если:
   * ошибка интерфейса бросается в глаза на виду или несет оскорбительный/негативный подтекст;
   * дефект находится в основном, самом важном сценарии использования;
   * ошибка потенциально может нанести критический ущерб пользователю.
5.4. Жизненный цикл дефекта
 * Open (Обнаружен / Новый): дефект зарегистрирован тестировщиком в баг-трекере. Менеджер изучает отчет и принимает решение: передать в работу, отложить (Postponed) или вернуть на доработку (To Be Reformulated).
 * Assigned (Назначен): менеджер назначает ответственного разработчика и выставляет поле Priority.
 * In Progress (В работе): разработчик приступил к исправлению.
 * Resolved (Решен): разработка завершена. Разработчик указывает статус/резолюцию:
   * Fixed (исправлено);
   * Won't Fix (не будет исправлено);
   * FAD / Function as designed (работает как задумано);
   * Duplicate (дубликат существующей задачи);
   * Cannot Reproduce (не воспроизводится);
   * Fixed Indirectly (исправлено косвенно).
   * Дополнительно указывается сборка, в которой дефект устранен (Fixed Version).
 * Проверка (Валидация): тестировщик берет сборку с соответствующим Fixed Version и проверяет исправление.
 * Closed (Закрыт) / Reopen: если дефект исправлен — переводится в Closed; если проблема воспроизводится — возвращается в статус Open.
5.5–5.6. Требования к качественному баг-репорту
 * Точность: обязательно приводить ссылку на пункт требований/ТЗ, который был нарушен.
 * Однозначность: полное исключение сленга, указание версий всех задействованных компонентов.
 * Полнота: наличие подробных шагов, реального и ожидаемого результатов, а также любой сопутствующей информации (логи, дампы, скриншоты), ускоряющей локализацию бага.