Manual Testing

БЛОК 8. Процессы тестирования — 25. Exploratory testing

📚 25 вопросовПройти тест →
Лекция

БЛОК 8. Процессы тестирования — 25. Exploratory testing

Manual Testing

БЛОК 8. Процессы тестирования — 25. Exploratory testing

🧭 Введение: зачем QA нужен exploratory testing

В реальном проекте не всё можно закрыть только тест-кейсами и чек-листами.
Всегда остаются зоны, где важно «поисследовать» систему: нестандартные действия пользователя, редкие переходы, неочевидные комбинации данных.
Exploratory testing как раз про это: тестировщик одновременно думает, проверяет и учится на том, что видит в системе.
💡 Совет:
Используй exploratory testing не как «хаотичное тыканье», а как управляемое исследование с целью и заметками.
✅ Вывод:
Exploratory testing помогает находить дефекты, которые часто не видны в заранее прописанных сценариях.

⚠️ Проблема -> решение

Проблема: junior QA часто понимает exploratory testing как «делаю что угодно без структуры».
Из-за этого много времени уходит, а результат трудно объяснить команде.
Решение: строить exploratory через короткие сессии, чёткую цель (charter), ограничение по времени (timebox) и фиксацию находок.
🟢 Если совсем просто:
Exploratory = свободное, но управляемое исследование продукта.
🎯 Как понять, что этап прошел успешно:
После сессии есть понятный результат: что проверили, что нашли, где остался риск.

🛠️ Чем помогает и как работает

Exploratory testing нужен там, где заранее сложно описать все пути в тест-кейсах.
Он особенно полезен для новых фич, сложных UI-потоков, интеграций и «плавающих» дефектов.
Как это работает:
  • Шаг 1: выбираем цель сессии (charter).
  • Шаг 2: ставим timebox (обычно 30-90 минут).
  • Шаг 3: исследуем продукт по гипотезам и наблюдениям.
  • Шаг 4: фиксируем баги, заметки и покрытие.
  • Шаг 5: делаем короткий debrief с командой.
✅ Вывод:
Ценность exploratory не в «свободе», а в скорости обнаружения реальных рисков при сохранении управляемости процесса.

📚 Ключевые термины (простыми словами)

  • Exploratory testing — подход, где тестировщик одновременно проектирует и выполняет проверки.
  • Charter — цель исследовательской сессии: что именно проверяем и зачем.
  • Timebox — ограничение времени на сессию.
  • Session notes — краткие заметки: шаги, наблюдения, идеи, риски.
  • Debrief — короткий разбор сессии: что нашли, что не успели, что делать дальше.
  • Heuristics — практические ориентиры «где чаще ломается».

1. Что такое exploratory testing

Exploratory testing — это осознанное исследование системы, а не случайные действия.
🟢 Если совсем просто:
Ты проверяешь продукт и одновременно думаешь, куда копать дальше.
🎯 Как понять, что этап прошел успешно:
Ты нашёл новые риски или подтвердил стабильность зоны и можешь это объяснить фактами.
Назначение:
Быстро находить дефекты и риски в зонах, где заранее прописанные сценарии неполны.
Простыми словами:
Это «умный поиск проблем» в живом продукте.
Для новичка:
Exploratory не заменяет тест-кейсы полностью.
Он дополняет их там, где нужна гибкость и наблюдательность.
Аналогия:
Тест-кейс — это маршрут по карте.
Exploratory — это разведка местности, где карта ещё неполная.
Пример: Фича «быстрая оплата в один клик» формально проходит happy path, но в exploratory-сессии QA находит:
  • двойную отправку при rapid-click;
  • некорректное состояние кнопки после timeout;
  • несоответствие статуса заказа после retry.
🔎 Как это происходит на практике:
QA запускает сессию с целью «проверить устойчивость one-click оплаты при нестабильной сети», фиксирует наблюдения и сразу формирует баги с evidence.
Характеристики:
  • гибкость в выборе следующего шага;
  • высокая чувствительность к «живым» дефектам;
  • сильная зависимость от опыта и фокуса QA.
Когда использовать:
  • новая функциональность;
  • ранний этап фичи, когда требования ещё уточняются;
  • нестабильные и «редкие» баги;
  • после крупных изменений в UI/потоке.
✅ Вывод:
Exploratory testing особенно силён там, где заранее сложно предусмотреть все сценарии.

2. Charter и timebox: ядро exploratory-сессии

Без charter и timebox exploratory быстро превращается в хаотичный прогон.
🟢 Если совсем просто:
Charter задаёт фокус, timebox удерживает темп.
🎯 Как понять, что этап прошел успешно:
Сессия не расползлась, а дала конкретный результат в пределах времени.
Назначение:
Сделать исследовательское тестирование управляемым и повторяемым.
Простыми словами:
Сначала отвечаем «что исследуем», потом «сколько времени на это даём».
Для новичка:
Один charter = одна проверяемая цель.
Пример charter: Исследовать поток регистрации с фокусом на валидацию email и устойчивость к повторной отправке формы за 45 минут.
🔎 Как это происходит на практике:
QA пишет 1-2 строки цели, ставит таймер, ведёт заметки по шагам и по завершении делает краткий debrief.
Характеристики:
  • высокий контроль фокуса;
  • предсказуемая длительность;
  • удобная передача результата команде.
Когда использовать:
  • когда есть ограниченное время;
  • когда нужно быстро проверить «неизведанную» зону;
  • когда важно сравнивать эффективность разных сессий.
✅ Вывод:
Charter и timebox превращают exploratory из «ад-хок» в рабочий инженерный процесс.

3. Mini-шаблон exploratory session

Ниже готовый формат, который junior QA может взять и использовать сразу в работе.
🟢 Если совсем просто:
Это каркас сессии, который не даёт уйти в хаос.
🎯 Как понять, что этап прошел успешно:
После сессии каждый пункт шаблона заполнен, а выводы понятны команде.
Exploratory Session Template
Charter:
Timebox:
Environment:
Focus area:
Risks / hypotheses:
Notes:
Bugs found:
Follow-up actions:
✅ Вывод:
Шаблон помогает сохранить скорость exploratory и одновременно повысить качество результата.

4. Где искать дефекты в exploratory

Сильный exploratory строится вокруг зон повышенного риска, а не вокруг случайных кликов.
🟢 Если совсем просто:
Ищи там, где сложная логика, состояния и интеграции.
🎯 Как понять, что этап прошел успешно:
Покрыты ключевые риск-зоны, а не только поверхностный UI.
Назначение:
Сфокусировать исследование на местах, где вероятность дефектов выше.
Простыми словами:
Не «что нажать», а «где чаще ломается».
Для новичка:
Используй простую карту риска:
  • ввод и валидация данных;
  • смена состояний (draft -> submitted -> paid);
  • роли и права доступа;
  • интеграции и внешние ответы;
  • сетевые проблемы и retry;
  • параллельные действия (double submit, две вкладки).
Пример: В checkout-сессии QA целенаправленно проверяет:
  • timeout на платёжном шаге;
  • refresh на подтверждении;
  • повторное нажатие кнопки оплаты;
  • переход назад после частичного успеха.
🔎 Как это происходит на практике:
QA заранее выписывает 5-7 риск-гипотез и в сессии идёт именно по ним.
Характеристики:
  • выше шанс найти «боевые» баги;
  • проще обосновать приоритет найденных дефектов;
  • меньше случайного шума.
Когда использовать:
Всегда, когда exploratory запускается на критичных потоках.
✅ Вывод:
Хороший exploratory — это исследование по гипотезам риска, а не хаотичный прогон интерфейса.

5. Как фиксировать результаты exploratory

Если результаты не зафиксированы, ценность сессии быстро теряется.
🟢 Если совсем просто:
Исследование без заметок = знание, которое нельзя переиспользовать.
🎯 Как понять, что этап прошел успешно:
Другой член команды может понять, что проверяли и что нашли, без созвона.
Назначение:
Сделать результат сессии воспроизводимым и полезным для команды.
Простыми словами:
После exploratory должно остаться «что проверено / что найдено / что осталось риском».
Для новичка:
Минимум после сессии:
  • charter;
  • время сессии;
  • список исследованных зон;
  • найденные дефекты;
  • открытые вопросы и риски.
Пример структуры заметок:
  1. Charter
  2. Environment
  3. Steps/observations
  4. Defects (links)
  5. Risks/follow-up
🔎 Как это происходит на практике:
QA параллельно ведёт короткие заметки и сразу заводит баги по горячим находкам.
Характеристики:
  • прозрачность;
  • воспроизводимость;
  • удобная передача контекста между участниками команды.
Когда использовать:
В каждой exploratory-сессии без исключений.
✅ Вывод:
Результат exploratory ценен только тогда, когда его можно передать и переиспользовать.

6. Exploratory vs scripted testing

Эти подходы не конкурируют, а дополняют друг друга.
🟢 Если совсем просто:
Scripted даёт стабильное покрытие, exploratory даёт гибкий поиск нового риска.
🎯 Как понять, что этап прошел успешно:
Команда осознанно использует оба подхода в нужной пропорции.
ПодходСильная сторонаОграничениеКогда особенно полезен
Scripted (тест-кейсы/чек-листы)Повторяемость и контроль покрытияМеньше гибкости для новых путейРегресс, стабильные потоки, compliance
ExploratoryБыстрое обнаружение неочевидных дефектовТребует дисциплины и опытаНовые фичи, риск-зоны, плавающие баги
✅ Вывод:
Лучшая стратегия: scripted для базы качества + exploratory для поиска неизвестных рисков.

7. С чего начать джуну: первый безопасный формат

Это простой стартовый алгоритм первой exploratory-сессии.
🟢 Если совсем просто:
Берём одну зону риска и идём коротким циклом.
🎯 Как понять, что этап прошел успешно:
Ты завершил сессию в timebox и можешь показать конкретный результат.
Первый безопасный формат для junior:
  1. Выбрать 1 риск-зону.
  2. Написать charter в 1 строку.
  3. Поставить таймер на 30 минут.
  4. Выписать 3-5 гипотез.
  5. Тестировать и записывать наблюдения.
  6. В конце сделать короткий summary.
✅ Вывод:
Такой старт даёт дисциплину и уверенность без перегрузки.

8. Как выбрать формат на задаче

В продакшене редко работает правило «только один подход».
🟢 Если совсем просто:
Выбирай формат по цели, риску и времени.
🎯 Как понять, что этап прошел успешно:
На каждую задачу есть понятный аргумент, почему выбран этот формат.
Быстрое правило выбора:
  • стабильный поток и частый регресс -> scripted;
  • новая логика и много неизвестного -> exploratory;
  • релиз под дедлайн -> scripted база + targeted exploratory в риск-зонах;
  • баг «иногда воспроизводится» -> exploratory с фокусом на условия воспроизведения.
✅ Вывод:
Сильный QA не «верит в один стиль», а подбирает подход под контекст задачи.

9. Где junior чаще ошибается

Ошибки чаще всего процессные: цель не ясна, результат не оформлен, выводы не доказаны.
🟢 Если совсем просто:
Главная ошибка — путать exploratory с хаотичным тестом без фокуса.
🎯 Как понять, что этап прошел успешно:
В отчёте видно цель сессии, покрытие, баги и остаточный риск.

Exploratory anti-patterns

  • идти без charter;
  • не ставить timebox;
  • не писать заметки;
  • смешивать 5 разных целей в одной сессии;
  • не оформлять найденные баги сразу;
  • не делать debrief.

Mini-правило хорошей exploratory-сессии

Хорошая exploratory-сессия должна быть:
  • целевой;
  • ограниченной по времени;
  • заметной по результату;
  • полезной для следующих действий команды.
✅ Вывод:
Дисциплина в exploratory так же важна, как и в тест-кейсах.

📌 Must-know факты

  • Exploratory testing = исследование с целью, а не хаотичные клики.
  • Charter и timebox — обязательная база управляемой сессии.
  • Retest/Regression и exploratory решают разные задачи.
  • Без заметок и debrief ценность exploratory резко падает.
  • Лучший практический формат: scripted + exploratory в риск-зонах.

❗ Частые мифы

❌ Миф: Exploratory testing — это тестирование без правил.
✅ Как правильно: У exploratory есть правила: цель, время, фиксация результатов, разбор.
📎 Почему это важно: Без правил невозможно оценить качество и пользу сессии.
❌ Миф: Exploratory нужен только опытным QA.
✅ Как правильно: Junior тоже может делать exploratory, если работает по простому шаблону с charter/timebox.
📎 Почему это важно: Это развивает системное мышление и навык поиска рисков.
❌ Миф: Если есть тест-кейсы, exploratory не нужен.
✅ Как правильно: Тест-кейсы и exploratory дополняют друг друга.
📎 Почему это важно: Только scripted-подход часто пропускает нестандартные проблемы.
❌ Миф: Exploratory всегда дольше, чем scripted.
✅ Как правильно: Хорошая exploratory-сессия в timebox часто быстрее даёт ценные находки.
📎 Почему это важно: Это полезно при сжатых сроках и высокой неопределённости.

Часто спрашивают на собеседованиях

❓ Вопрос: Чем exploratory testing отличается от ad-hoc testing? ✅ Ответ: Exploratory имеет цель, границы по времени и фиксацию результата; ad-hoc обычно менее структурирован.
❓ Вопрос: Что такое charter в exploratory? ✅ Ответ: Это краткая формулировка цели сессии: какую зону и под каким фокусом исследуем.
❓ Вопрос: Какие артефакты должны остаться после exploratory-сессии? ✅ Ответ: Минимум: заметки сессии, найденные баги, покрытые зоны, открытые риски и follow-up.
❓ Вопрос: Можно ли полностью заменить регресс exploratory-тестированием? ✅ Ответ: Нет, exploratory не заменяет стабильное регрессионное покрытие, а дополняет его.

🚨 Типичные ошибки

❌ Неправильно: «Пойду покликаю продукт без плана, вдруг найду баг».
✅ Правильно: Запустить сессию по charter, с timebox и заранее выбранными зонами риска.
❌ Неправильно: Завершить сессию фразой «вроде всё нормально».
✅ Правильно: Завершить сессию структурным summary: что исследовано, что найдено, какие риски остались.
❌ Неправильно: Писать баг без шагов и контекста, потому что «нашёл случайно».
✅ Правильно: Фиксировать наблюдения по ходу сессии и оформлять воспроизводимый bug report с evidence.

✅ Best Practices

  • Используй простой шаблон сессии: charter -> timebox -> notes -> debrief.
  • Держи фокус на риск-зонах, а не на случайной навигации.
  • Фиксируй не только баги, но и открытые вопросы/гипотезы.
  • После exploratory обновляй чек-листы и тест-кейсы, если найден новый повторяемый риск.
  • Проводи короткий debrief с командой сразу после сессии.

🏁 Заключение

Exploratory testing — это практичный инструмент для поиска реальных рисков в живом продукте.
Если применять его структурно, он даёт сильный эффект даже у junior QA: больше найденных дефектов, лучшее понимание продукта и более точные релизные решения.
✅ Вывод:
Хороший exploratory testing — это свобода исследования внутри чётких рамок цели, времени и доказуемого результата.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «БЛОК 8. Процессы тестирования — 25. Exploratory testing»

Пройти тест →