Что такое исследовательское тестирование?

Что такое исследовательское тестирование?

Исследовательское тестирование (Exploratory Testing) — это адаптивная форма тестирования, при которой тестер одновременно изучает приложение, планирует тесты, выполняет тесты и отчитывается о результатах, без заранее написанных тест-кейсов.

Суть

Разница между scripted и exploratory тестированием:

Scripted Testing:

• Тест-кейсы написаны заранее
• Шаги описаны точно
• Ожидаемый результат известен
• Ты просто выполняешь шаги по инструкции

Exploratory Testing:

• Нет заранее написанных сценариев
• Ты исследуешь приложение интуитивно
• Адаптируешь тесты на основе найденного
• Думаешь в процессе, не следуешь скрипту

Основные характеристики

Time-boxed: обычно фиксированное время (1-4 часа), а не неограниченное.

Charter (задача): есть общее направление, что искать (баги в поиске, проблемы с платежом и т.д.).

Одновременность: планирование, выполнение и отчётность идут параллельно.

Адаптивность: если найдена проблема, копаешь глубже в этом направлении.

Ментальная нагрузка: требует опыта, интуиции и знания домена.

Пример

Scripted:

Тест: Поиск продукта
1. Открыть сайт
2. Вводимое "laptop" в поле поиска
3. Нажать Enter
4. Ожидаемый результат: список ноутбуков
5. Проверить, что показано минимум 10 результатов

Exploratory:

1. Открыл сайт
2. Вижу поле поиска, введу "laptop"
3. Результаты загружаются... очень долго
4. Интересно, давай попробую поиск пустой строки
5. Результаты показываются быстро (может быть баг с фильтрацией)
6. Введу специальные символы: "laptop & #@"
7. Приложение упало! Найден баг!
8. Попробую ввести очень длинную строку (1000 символов)
9. Строка не обрезается и сломала UI... ещё баг
10. Интересно, работает ли поиск при отключённом JavaScript?

Процесс исследовательского тестирования

1. Планирование (быстро): что буду тестировать (20 минут)
2. Исследование: активное тестирование (2-3 часа)
3. Отчётность: документирование найденных багов

Когда использовать

Хорошо для:

• Новый функционал (ещё нет тест-кейсов)
• Когда требования расплывчаты
• Когда нужно найти максимум багов в короткий срок
• Когда код менялся (регрессия)
• Когда есть опытный QA с хорошей интуицией

Плохо для:

• Регулярных повторяющихся проверок (нужна автоматизация)
• Критичного функционала (нужна полнота)
• Когда требования строгие (нужны scripted тесты)

Техники исследовательского тестирования

1. Смена контекста

• Быстро переключаюсь между разными функциями
• Вижу, как они взаимодействуют
• Находишь баги на границах

2. Smoke Testing подход

• Быстро проверяю базовые функции
• Не углубляюсь в детали
• Ловлю obvious проблемы

3. Deep Dive

• Выбираю одну функцию
• Углубляюсь в детали
• Проверяю все параметры
• Ищу граничные случаи

4. Persona-based Testing

• Представляю себе разные типы пользователей
• Тестирую как они будут использовать
• "Я пожилой пользователь, может ли я найти кнопку?"
• "Я спешу, могу ли быстро выполнить задачу?"

5. Negative Testing

• Специально вводу неправильные данные
• Вводу пустые поля
• Вводу очень большие значения
• Вводу специальные символы

Примеры багов, найденные через exploratory

• Приложение падает при быстром двойном клике
• Форма не валидирует email с плюсом (user+tag@domain.com)
• При отключённом JavaScript кнопка не работает
• Cache не обновляется при обновлении данных
• Приложение не работает при медленном интернете
• У других пользователей видны личные данные (security)
• Баги при копировании текста в буфер обмена
• Проблемы с кириллицей в некоторых полях

Мои инструменты

• DevTools: для инспекции HTML, console errors
• Charles/Burp: для перехвата и редактирования запросов
• Screenshots: фотографирую багу (для отчёта)
• Notes: пишу заметки по процессу
• Video recording: снимаю на видео, как воспроизвести баг

Отчётность по результатам

Каждый найденный баг:

1. Описание что произошло
2. Шаги для воспроизведения
3. Ожидаемое поведение
4. Фактическое поведение
5. Severity (critical, high, medium, low)
6. Screenshots/видео
7. Environment (browser, OS, device)

Метрики исследовательского тестирования

• Количество найденных багов
• Severity distribution (сколько critical vs low)
• Баги на час тестирования
• Баги на функцию
• Coverage функционала

Мой совет

Опытный QA должен уметь исследовательское тестирование. Это найденные баги, которые невозможно найти scripted тестами. Требует опыта, интуиции, знания домена.

Процесс:

1. Выбираю функцию или область
2. Устанавливаю time-box (например, 2 часа)
3. Исследую, адаптирую на основе находок
4. Документирую найденные баги
5. Передаю разработчикам

Исследовательское тестирование — это искусство, а не наука. Чем больше опыта, тем больше багов найдёшь.