Как называется вид тестирования, когда баг обнаружен в требованиях

Question

deepseek-v3.2 · Accepted Answer

## Тестирование требований (Requirements Testing)

В профессиональной сфере тестирования ПО ситуация, когда дефект (баг) обнаружен непосредственно в требованиях, называется **тестированием требований (Requirements Testing)** или **статическим тестированием требований (Static Requirements Testing)**. Этот вид деятельности не связан с выполнением кода, а фокусируется на анализе документации на ранних стадиях жизненного цикла разработки (SDLC).

### Суть и цели тестирования требований

Основная цель — выявить **дефекты в документации** до того, как на её основе будет написан код. Такие дефекты могут включать:

*   **Неполноту (Incompleteness):** Отсутствие описания важных сценариев, состояний или граничных условий.
*   **Противоречивость (Inconsistency):** Разные части документации противоречат друг другу.
*   **Неясность/Двусмысленность (Ambiguity):** Требования можно интерпретировать по-разному, что ведет к разному пониманию у разработчиков, тестировщиков и заказчика.
*   **Нетестируемость (Untestability):** Невозможно создать объективный тест для проверки выполнения требования (например, "интерфейс должен быть удобным").
*   **Нереализуемость (Unfeasibility):** Техническая или ресурсная невозможность реализации требования в заданных рамках.
*   **Несоответствие бизнес-целям (Misalignment with Business Goals):** Требование не решает актуальной бизнес-задачи пользователя.

Найденный на этом этапе дефект формально является **дефектом в артефакте требований**, но в контексте управления дефектами его также называют **логгированием бага в требованиях**.

### Почему это критически важно?

Обнаружение и исправление багов в требованиях — одна из самых экономически эффективных практик в QA. Стоимость исправления дефекта растет экспоненциально по мере продвижения по стадиям SDLC. Блок кода ниже иллюстрирует разницу в усилиях:

```python
def cost_of_fix(defect_stage):
    """
    Условная модель стоимости исправления дефекта.
    Усилия измеряются в условных единицах.
    """
    cost_base = {
        'requirements': 1,      # Исправить текст в документе
        'design': 5,           # Перепроектировать
        'coding': 10,          # Переписать код
        'testing': 50,         # Регрессионное тестирование
        'production': 100      # Исправить у клиента + репутационные риски
    }
    return cost_base.get(defect_stage, 1000)

# Пример
print(f"Стоимость исправления на этапе требований: {cost_of_fix('requirements')}")
print(f"Стоимость исправления в продакшене: {cost_of_fix('production')}")
```

### Методы и техники тестирования требований

Для выявления дефектов в требованиях используются методы **статического тестирования**:

*   **Ревью требований (Reviews):** Формальные или неформальные сессии с участием аналитиков, разработчиков, тестировщиков и бизнес-представителей.
*   **Инспекции (Inspections):** Наиболее формальный тип ревью с заранее определёнными ролями и чек-листами.
*   **Анализ на тестируемость (Testability Analysis):** Оценка каждого требования с точки зрения возможности создания для него тестов.
*   **Мозговой штурм сценариев (Scenario Brainstorming):** Попытка представить пользовательские сценарии на основе требований.
*   **Прототипирование и моделирование (Prototyping & Modeling):** Создание макетов интерфейсов или диаграмм процессов для валидации требований с заказчиком.

### Практический пример процесса

Представим историю пользователя (User Story):
> **Как** пользователь, **я хочу** видеть список последних 20 транзакций, **чтобы** быстро проверять свою активность.

Тестировщик, анализируя это требование, может выявить следующие потенциальные дефекты:

*   **Неполнота:** Что делать, если транзакций меньше 20? Больше 20?
*   **Двусмысленность:** Что значит "последних"? По дате совершения или дате отображения в системе?
*   **Нетестируемость:** Какие именно данные должны отображаться для каждой транзакции (дата, сумма, контрагент)?

**Логгирование такого бага** в трекере может выглядеть так:

```markdown
**Заголовок:** [Требования] Неполное/неясное требование для истории "Просмотр последних транзакций"
**Описание:** В текущей формулировке требования отсутствуют критерии приемки (Acceptance Criteria).
**Шаги для воспроизведения:**
1. Открыть спецификацию требований v1.2, раздел "Личный кабинет".
2. Прочитать историю пользователя US-45.
**Фактический результат:** Требование описывает только базовый сценарий.
**Ожидаемый результат:** Требование должно включать Acceptance Criteria, например:
- AC1: Если транзакций 0, отображается сообщение "Операций не найдено".
- AC2: Если транзакций от 1 до 20, отображаются все.
- AC3: Если транзакций >20, отображаются 20 самых свежих по дате операции.
- AC4: Для каждой транзакции отображаются: Дата (ДД.ММ.ГГГГ), Сумма, Назначение платежа.
**Серьезность:** Minor
**Приоритет:** Medium
```

Таким образом, термин **"тестирование требований"** точно описывает деятельность по выявлению дефектов в них. Умение находить такие баги — ключевой навык опытного QA-инженера, который предотвращает дорогостоящие переделки и существенно повышает качество конечного продукта.

Как называется вид тестирования, когда баг обнаружен в требованиях

Комментарии (2)

Тестирование требований (Requirements Testing)

Суть и цели тестирования требований

Почему это критически важно?

Методы и техники тестирования требований

Практический пример процесса