Ручное тестирование

Зачем перед началом тестирования фиксируют критерии входа?

В требовании описан только успешный сценарий. Как определить границы негативных проверок, не додумывая бизнес-правила?

Для поля промокода система различает действующий, просроченный, уже использованный и неизвестный код. Как построить классы эквивалентности для ручной проверки?

Как зафиксировать результат ручной проверки, чтобы его мог независимо подтвердить другой тестировщик?

Релиз блокирует подтверждённый дефект, но исправление рискованнее самого дефекта. Как оформить обоснованное решение о выпуске?

Регрессионный набор годами не менялся, хотя продукт активно развивался. Как понять, что он создаёт ложную уверенность в качестве?

В правилах скидки результат зависит от трёх независимых условий. Как выявить комбинации условий, которые не покрывает набор тестов?

Команда заявляет: «тестами покрыто 100% требований». Как проверить, что этот показатель действительно отражает достаточность ручных проверок?

Тестировщик обнаружил дефект в новой версии продукта. Как доказать, что это регрессия?

В заказе нет заранее известной эталонной суммы. Как по данным ответа проверить, что итог рассчитывается согласованно?

{
  "позиции": [
    {"цена": 250, "количество": 2},
    {"цена": 300, "количество": 1}
  ],
  "скидка": 100,
  "итого": 700
}

Постановка: при сетевом таймауте клиент может повторить запрос создания заказа. Как вручную проверить, что повтор не создаёт дубликат, используя один и тот же ключ операции?

POST /orders HTTP/1.1
Content-Type: application/json
Idempotency-Key: order-2025-001

{"productId":"A-17","quantity":1}

Во время ручной проверки отчёта, зависящего от текущей даты, результат меняется каждый день. Как организовать проверку, чтобы вывод оставался воспроизводимым?

Сценарий стабильно проходит утром, но иногда падает при тех же входных данных: как доказать, что это нестабильность продукта, а не ошибка проверки?

Сравните smoke- и sanity-проверки по цели и моменту применения.

Тест-кейс месяцами проходит без изменений продукта, но его тестовые данные больше не гарантируют исходные условия. Как доказать, что проверка всё ещё валидна?

В отчёте о дефекте фактический результат отличается от ожидаемого, но требование не объясняет, каким должен быть результат. Как решить, достаточно ли данных для регистрации дефекта?

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

Как дробление составного шага тест-кейса повышает диагностичность результата?

Набор тестов уже покрывает классы эквивалентности, но дефекты всё равно находят пользователи. Как применить метод ошибочного угадывания, чтобы целенаправленно расширить ручную проверку?

Сервис, от которого зависит тест-кейс, недоступен. Какой результат выполнения зафиксировать и почему?