# Жизненный цикл дефекта

### Жизненный цикл дефекта <a href="#defect-life-cycle-in-detail" id="defect-life-cycle-in-detail"></a>

**Жизненный цикл дефекта (бага)** – это цикл, через который проходит дефект за весь период своего существования, включая его различные состояния. Он начинается с момента обнаружения тестировщиком нового бага, и заканчивается, когда тестировщик закрывает баг, гарантируя, что он не будет воспроизведен снова.

### Рабочий процесс дефекта <a href="#defect-workflow" id="defect-workflow"></a>

Разберемся в фактическом рабочем процессе жизненного цикла бага с помощью простой диаграммы, показанной ниже.

<figure><img src="https://qarocks.ru/wp-content/uploads/2023/08/defect-life-cycle-in-hpm1.jpg" alt="рабочий процесс жизненного цикла бага." height="350" width="544"><figcaption></figcaption></figure>

### Состояния дефекта <a href="#defect-states" id="defect-states"></a>

**1. Новый (New):** Это первое состояние дефекта в его жизненном цикле. Когда обнаруживается любой новый баг, он переходит в состояние “Новый”, а его валидация и тестирование выполняются на более поздних стадиях жизненного цикла.

**2. Назначен (Assigned):** На этом этапе заведенный впервые дефект передается команде разработчиков. Разработчика-исполнителя назначает руководитель проекта или менеджер команды тестирования .

**3. Открыт (Open):** Данный статус присваивается дефекту, когда разработчик начинает процесс его анализа и работает над его исправлением, если это необходимо.

Если по мнению разработчика дефект неактуален или некорректен, то он может быть переведен в одно из следующих четырех состояний: “Дубликат”(**“Duplicate“), “Отложено” (“Deferred”), “Отклонено” (“Rejected”) или “Не ошибка”(“Not a Bug”)** на основании определенных фактов. Позже мы рассмотрим подробнее эти четыре состояния.

**4. Исправлен (Fixed):** Когда разработчик завершает задачу по исправлению дефекта, внося необходимые изменения в код, он изменяет статус дефекта на “Исправлен”.

**5. Ожидание повторного тестирования (Pending Retest):** После исправления дефекта разработчик передает его тестировщику для повторного тестирования. Пока этого не произойдет, баг остается в статусе “Pending Retest”.

**6. Нужен повторный тест (Retest):** На этом этапе тестировщик приступает к повторному тестированию дефекта, чтобы проверить, насколько точно он исправлен разработчиком в соответствии с требованиями.

**7. Открыт заново (Reopen):** Если в рамках дефекта какая-либо проблема не была исправлена, он снова передается разработчику, а статус дефекта меняется на “Reopen”.

**8. Проверен (Verified):** Если тестировщик после проведения повторного тестирования считает, что дефект был исправлен, то статус дефекта меняется на “Verified”.

**9. Закрыт (Closed):** Когда дефект больше не существует и полностью исправлен, тестировщик меняет статус дефекта на “Closed”.

**Еще несколько возможных состояний:**

* **Отклонен (Rejected):** Если разработчик считает дефект некорректным, то он помечается как “Rejected”.
* **Дубликат (Duplicate):** Если заведенный баг уже существует или его описание совпадает с любым другим дефектом, то статус меняется на “Duplicate”.
* **Отложенный (Deferred):** Если разработчику кажется, что у дефекта не очень высокий приоритет, и он может быть исправлен в следующих релизах, то статус может быть изменен на ‘Deferred”.
* **Не ошибка (Not a Bug):** Если дефект никак не влияет на функциональность приложения, то его статус меняется на “Not a Bug”.

Обязательные поля, которые тестировщик заполняет при заведении отчета по любому новому дефекту – Версия сборки (Build version), Программный продукт (Product), Модуль (Module), Серьезность (Severity), Краткое описание (Title) и Шаги воспроизведения (Steps to Reproduce).

В вышеприведенный список можно добавить еще несколько необязательных полей. К ним относятся Имя клиента (Customer name), Браузер (Browser), Операционная система (Operating system), Приложенные файлы (File Attachments).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://qabook.gitbook.io/start/teoriya-testirovaniya/bagi-defekty/zhiznennyi-cikl-defekta.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.