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

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

Объясните, как исследовательское тестирование превращает результаты одной проверки в следующие проверки.

Разработчик отклонил дефект со статусом «не воспроизводится». Как тестировщику повысить воспроизводимость такого дефекта?

В требовании сказано: «Отчёт должен формироваться быстро». Что сделать до начала тестирования?

После исправления дефекта достаточно ли повторить только шаги из его отчёта? Обоснуйте решение.

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

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

В тест-кейсе ожидаемый результат записан как «система работает корректно». Что в такой формулировке мешает объективно принять результат проверки?

В каком случае чек-лист предпочтительнее подробного тест-кейса при ручной проверке?

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

Представьте форму с пятью фильтрами по три значения: как выбрать набор проверок, чтобы не перебирать все комбинации?

Как матрица трассируемости помогает обнаружить риск, который не виден при просмотре тест-кейсов по отдельности?

По каким признакам обосновать завершение ручного тестирования функции, если дефекты могут остаться?

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

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

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

При расхождении результата в двух окружениях как доказать, что дефект относится к продукту, а не к тестовой среде?

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

Есть функция со статусами «Черновик», «Опубликован» и «Архив»: как построить ручные проверки, чтобы обнаружить недопустимый переход между состояниями?

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