Тестировал ли требования

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

Да, я регулярно тестирую требования еще до того, как разработчик начнет кодить. Это критичная часть качественной разработки.

Что значит тестировать требования

Анализ на полноту Проверяю что требования описывают все сценарии:

• Главный путь (happy path)
• Альтернативные пути
• Граничные случаи
• Ошибочные сценарии

Анализ на точность Проверяю что требования однозначны:

• Есть ли неоднозначные формулировки?
• Можно ли интерпретировать по-разному?
• Все ли детали описаны?

Анализ на тестируемость Смотрю можно ли автоматизировать:

• Требование должно быть проверяемо
• Должны быть четкие критерии приемки
• Должны быть входные и выходные данные

Пример из практики

Требование (как пришло): "Пользователь может отключить двухфакторную авторизацию"

Проблемы которые я нашел:

1. Что происходит если пользователь имеет ТОЛЬКО двухфакторную авторизацию? Это лучше ограничить?
2. Нужна ли re-авторизация перед отключением?
3. Что отправляем на email? Подтверждение? Предупреждение?
4. Есть ли логирование для security audit?
5. Если пользователь отключил, может ли он включить обратно? Сразу или с задержкой?

Улучшенное требование (после моего анализа):

User can disable Two-Factor Authentication (2FA)

Preconditions:
- User has 2FA enabled
- User has at least one backup authentication method (email, password)

Scenario:
1. User navigates to Security Settings
2. Finds "Two-Factor Authentication" section
3. Clicks "Disable 2FA" button
4. System requests password confirmation
5. After entering correct password:
   - 2FA is disabled
   - Confirmation email sent
   - Action logged in security audit log
   - Redirect to security settings with success message

Error Cases:
- Password incorrect: Show error, block after 3 attempts
- Network error: Show retry button
- User only has 2FA: Show error "At least one backup method required"

Acceptance Criteria:
- 2FA disabled only after correct password
- Email confirmation sent within 5 seconds
- Action visible in security log
- Can re-enable 2FA anytime

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

1. Требования Review (Requirements Review) Читаю требования вместе с Product Owner и разработчиком:

• Задаю вопросы если что-то непонятно
• Предлагаю сценарии которые не описаны
• Указываю на противоречия

2. Создание тестовых сценариев ДО разработки Напишу тестовые сценарии на основе требований:

• Если сценарий сложно описать — требование нечеткое
• Если появляются вопросы — требование неполное
• Это помогает выловить проблемы рано

3. Mind Mapping Создаю mind map всех сценариев:

• Happy path
• Alternative paths
• Error cases
• Edge cases
• Security cases
• Performance cases

Это выявляет пробелы.

4. Трассируемость требований (Requirements Traceability Matrix) Каждое требование должно быть:

• Одному или нескольким тестовым сценариям
• Покрыто тестами
• Проверяемо

Если требование не покрыто тестом — это проблема.

Типичные проблемы в требованиях

Амбигуозность (неоднозначность)

Плохо: "Система должна быть быстрой"
Хорошо: "API должен ответить за < 200ms для 95-го процентиля"

Неполнота

Плохо: "Пользователь может фильтровать товары"
Хорошо: "Пользователь может фильтровать товары по категории, цене (0-1000), рейтингу (1-5 звезд)"

Неправильная уровень детализации

Плохо (слишком мало): "Реализовать платежи"
Хорошо: "Интегрировать Stripe API для обработки платежей кредитных карт"

Противоречия

Требование A: "Минимальный возраст 18 лет"
Требование B: "Дети могут использовать"
→ Противоречие

Практический подход

На этапе Requirements

1. Читаю требования
2. Задаю вопросы Product Owner
3. Создаю потенциальные тестовые сценарии
4. Указываю на пробелы

Результат

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

Зачем это нужно

Экономия времени Проблемы найденные на этапе требований стоят в 10 раз дешевле, чем найденные в готовом коде.

Качество Тестирование требований — это профилактика дефектов.

Коммуникация В процессе выясняются недопонимания между Product Owner и разработчиком.

Полнота тестирования Если требование нечеткое — я не смогу написать хороший тест.

Тестирование требований — это признак зрелого QA процесса в команде.