Что такое тестирование требований?

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

Это одна из самых важных, но часто упускаемых практик в QA. Я назвал бы это «тестированием до разработки».

Определение

Тестирование требований — это процесс проверки того, что требования к функционалу:

1. Полные — ничего не забыто
2. Ясные — однозначно интерпретируются всеми
3. Выполнимые — разработчики могут их реализовать
4. Тестируемые — можно проверить, что они выполнены
5. Консистентные — не противоречат друг другу

Когда я тестирую требования

1. На этапе планирования (Planning Meeting)

Когда я первый раз видим требование, я сразу задаю вопросы:

Примеры вопросов:

• Что означает "быстро"? < 1 сек? < 100 мс?
• Что произойдёт, если payment gateway downtime? Retry? Уведомление?
• Как обрабатываются duplicate платежи?
• На каких браузерах должно работать?
• Какой максимальный размер файла при upload?
• Что если пользователь оффлайн?

Мой инструмент: Я создаю список вопросов в Jira comment или Confluence и ассайню Product Owner.

2. На этапе Definition of Ready (DoR)

Прежде чем истории идут в спринт, я проверяю:

Чеклист Requirements Testing:

• Требование описано в формате User Story с Given-When-Then
• Acceptance criteria чёткие и measurable
• Определены edge cases
• Прописано, что не входит в scope (out of scope)
• Нет технических contradictions
• Дизайны/мокапы приложены
• Зависимости от других историй ясны

Пример хорошего требования:

As a customer
I want to reset my password
So that I can regain access to my account

Acceptance Criteria:
1. User вводит email → система отправляет reset link
2. Link активен 24 часа
3. Если email не найден → сообщение "email does not exist"
4. Новый пароль должен быть >= 8 символов
5. После reset → пользователь может залогиниться с новым паролем

Пример плохого требования:

"Улучшить систему авторизации"

(Слишком vague!)

Техники тестирования требований

1. Syntax Review

Проверяем: Грамматика, ясность, читаемость.

Ищу:

• Typos
• Неоднозначные формулировки ("sometimes", "maybe", "usually")
• Местоимения без контекста ("it", "this" — что имеется в виду?)

Пример проблемы:

"User может скачать файл. Его размер должен быть не более 10 МБ."
→ "Его" может относиться к file или к user?

2. Completeness Check

Ищу, что забыли:

• Граничные случаи (empty list, single item, huge list)
• Error scenarios (что если server down, network timeout?)
• Performance requirements (how fast должно быть?)
• Security (authentication, authorization, encryption)
• Usability (do users understand error messages?)
• Compliance (GDPR, PCI-DSS, локальные законы)

Мой метод: Я рисую user journey и на каждом шаге спрашиваю себя:

• Что может пойти не так?
• Кто может это использовать неправильно?
• Какие данные нужны?
• Кто может это видеть?

3. Feasibility / Technical Review

Проверяю с разработчиком:

• Это реально сделать за оценённое время?
• Нужны ли архитектурные изменения?
• Есть ли technical debt, который мешает?
• Это возможно с текущим стеком?

Мой процесс: Я зову tech lead на meeting и говорю: "Вот требования, это реально?" Иногда требования нужно переделать, если они технически невозможны.

4. Traceability Matrix

Создаю матрицу:

Requirement ID | Description            | User Story | Test Cases | Priority
---|---|---|---|---
REQ_001        | User can login         | US-123     | TC1, TC2   | High
REQ_002        | Reset password link    | US-124     | TC3, TC4   | High
REQ_003        | Logout button present  | US-123     | TC5        | Medium

Зачем: Убеждаемся, что каждое требование имеет тест-кейсы. Если требование забыли — оно будет видно в матрице.

5. Consistency Check

Проверяю, что требования не противоречат друг другу:

Пример конфликта:

REQ_001: Password должен быть <= 20 символов
REQ_002: Password должен быть >= 25 символов
→ Impossible!

Другой пример:

REQ_001: User может скачать файл (без ограничений)
REQ_002: Максимальный размер файла 10 МБ
→ Противоречие, нужна уточнение

6. Ambiguity Detection

Ищу формулировки, которые можно интерпретировать по-разному:

Плохо:

"Пароль должен быть сильным"
→ Что означает "сильный"? Только буквы? Только цифры? Special chars?

Хорошо:

"Пароль должен содержать:
- Минимум 8 символов
- Минимум одну прописную букву
- Минимум одну цифру
- Минимум один special char (!@#$%)"

Инструменты и процессы

1. Requirements Management Tool

Мы используем Jira с добавленными полями:

• Story type: User Story, Technical, Bug
• Priority
• Acceptance criteria (Rich Text)
• Out of Scope
• Testing notes

2. Risk Assessment для требований

Не все требования одинаково важны. Я расставляю приоритеты:

High Risk (тестирую тщательно):
- Payment processing
- Authentication
- Data deletion
- Reporting (compliance)

Medium Risk:
- User profile updates
- Search functionality
- Notifications

Low Risk:
- UI tweaks
- Dark mode
- Copy changes

3. Collaboration

Тестирование требований — это team effort:

• PO — объясняет бизнес-логику
• Designer — clarifies UX expectations
• Tech Lead — confirm feasibility
• QA Lead — identify risks and edge cases

Обычно мы делаем 30-минутное meeting для complex требований.

Реальный пример из практики

Было требование:

"User может экспортировать данные в CSV"

Я задал вопросы:

1. Какие данные экспортируются? Все или выбранное?
2. Какой формат CSV? UTF-8? Windows-1251? (Важно для Russian users)
3. Что если данных 1 млн rows? Как долго ждать?
4. Уведомление на email или direct download?
5. На каком сервере хранится файл? Сколько времени?
6. Что если export failed на середине? Retry?
7. Какие permissions нужны для export (only admin?)?
8. Можно ли экспортировать чужие данные? (Security!)
9. Лимит на количество экспортов в день?

Результат:

ПО изначально требование было написано в 1 строке. После моих вопросов оно превратилось в 3 фичи:

1. Quick export — текущая таблица, max 10k rows, instant download
2. Async export — любая таблица, 1 млн rows, by email
3. Scheduled export — ежедневно на email

Это спасило team-а от переделки позже.

Выводы

Тестирование требований экономит время и деньги:

• Без requirements testing: баги находятся в production (дорого)
• С requirements testing: проблемы решаются на planning stage (дешево)

В среднем я трачу 10% времени спринта на requirements testing и экономлю 30% переделок. ROI очень хороший.