🫣 Как выделять тестовые сценарии из требований

Часто требования звучат как «система должна работать быстро» или «пользователь может управлять настройками». Формально все есть, а тестировать нечего.

1️⃣ Разбиваем «воду» на сущности и действия

Пример: «Пользователь управляет профилем» 👉 сущность: профиль, действия: редактировать, сохранить, сбросить.

2️⃣ Используем CRUD как подсказку

Для каждой сущности проверяем: create, read, update, delete

3️⃣ Ищем граничные условия

Кривое ТЗ редко пишет про пустые значения, длинные строки или лимиты ((например, 10MB для аватара).

👉 Эти сценарии QA должен додумывать сам.

4️⃣ Проверяем бизнес-правила

Если в требованиях написано «пароль должен быть надёжным» — переводим в конкретику:

👉 Минимальная длина?
👉 Обязательные символы?
👉 Что будет при 100 неудачных попытках входа?

5️⃣ Формируем тестовые сценарии

Каждый сценарий = «что делает пользователь» + «ожидаемый результат». Даже из кривого текста получается набор конкретных кейсов.

💡 Если ТЗ расплывчатое — вопросы бизнесу/аналитикам must have.

🐸 Библиотека тестировщика

#буст