Тест-кейсы — это заранее подготовленные сценарии с чётко прописанными шагами, входными и ожидаемыми результатами. Исследовательское тестирование (exploratory testing) строится по месту: тестировщик по ходу освоения продукта генерирует проверки, используя свою экспертизу и интуицию. Исторически сначала господствовали тест-кейсы, но с усложнением систем и ростом объёма ручной проверки исследовательское тестирование стало дополнять формальные подходы.
Слепое следование только одному виду тестирования ограничивает находчивость тестировщика и может оставить продукт с незамеченными багами, неописанными в кейсах.
Использовать оба подхода в сбалансированном виде: тест-кейсы — для регрессионного и критического функционала, исследовательское — для новых, ещё не до конца формализованных разделов и при шорт-таймах.
Ключевые особенности:
Можно ли использовать только тест-кейсы для 100% покрытия?
Нет. Даже самый подробный набор кейсов не покрывает неожиданное поведение пользователя или нестандартные баги.
Требует ли exploratory testing предварительной подготовки?
Да. Необходимо разобраться в функциональности, изучить требования, понять бизнес-логику перед тем, как свободно исследовать продукт.
Обязателен ли баг-репорт после exploratory testing?
Да. Любой найденный дефект должен быть оформлен так же подробно, как и баг из формального сценария, иначе его сложно воспроизвести и исправить.
Команда покрыла релиз только формальными тест-кейсами. Один тестировщик выполнил их строго по инструкции, не проверяя "смежные" кейсы, из-за чего был упущен баг, появляющийся при определённой последовательности действий, не предусмотренной заранее.
Плюсы:
Минусы:
Тестировщик после прохождения ключевых тест-кейсов выделил час на exploratory testing, нашёл баг, который воспроизводится только при смене времени на устройстве во время работы приложения.
Плюсы:
Минусы: