Exploratory testing: как тестировать без тест-кейсов и документировать результаты

Представьте: у вас новая фича, дедлайн через два дня. Вы открываете Jira, смотрите на список из 150 тест-кейсов. На каждый нужно 10 минут. Итого 25 часов работы. У вас есть 8 часов.

Вы начинаете кликать по тест-кейсам. Шаг 1: войти в систему. Шаг 2: перейти в раздел настроек. Шаг 3: кликнуть на кнопку. Шаг 4... Механически. Скучно. Вы выполняете инструкции, а не думаете.

А потом в production вылезает баг. Критичный. Он не был покрыт ни одним тест-кейсом. Потому что он появляется только если: залогиниться через Google, переключить язык на японский, добавить товар в корзину, вернуться назад, снова добавить и затем изменить количество. Кто додумается написать тест-кейс на такую комбинацию?

Вот для чего нужен exploratory testing. Это не бездумное кликанье. Это структурированное исследование продукта, где тестировщик думает, анализирует, ищет неочевидные проблемы. Без заранее написанных шагов, но с чёткой целью и документацией.

По данным исследования World Quality Report (2023), 78% критичных багов в production находят не скриптовые тесты, а exploratory testing или реальные пользователи. Microsoft, Google, Netflix активно используют ET как часть стратегии тестирования.

Проблема в том, что многие путают exploratory testing с ad-hoc testing (беспорядочное тыканье). Это не одно и то же. ET — это дисциплина, методика, навык. Её можно освоить, применять системно и измерять результаты.

Эта статья — практическое руководство. Что такое exploratory testing, чем отличается от scripted, когда использовать, какие техники применять, как документировать, как планировать сессии, примеры чартеров, инструменты, типичные ошибки. С конкретными шаблонами и чек-листами.

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

Определение от Джеймса Баха:

"Exploratory testing — это одновременное обучение, проектирование тестов и выполнение тестирования. Тестировщик активно контролирует дизайн тестов по мере их выполнения и использует информацию из последнего теста для проектирования следующего".

Простыми словами:

Вы исследуете продукт как детектив. Формируете гипотезы, проверяете их, на основе результатов создаёте новые гипотезы. Цикл: действие → наблюдение → анализ → новое действие.

Ключевые характеристики ET

Что НЕ является exploratory testing

• Ad-hoc testing: Беспорядочное кликанье без плана и документации

• Monkey testing: Случайные действия для проверки стабильности

• Отсутствие тестирования: "Просто покликаем и посмотрим"

• Замена всех тест-кейсов: ET дополняет scripted testing, не заменяет

Виды exploratory testing

1. Freestyle exploratory testing

Полная свобода. Тестировщик исследует продукт без ограничений. Подходит для: первого знакомства с продуктом, поиска неожиданных проблем, креативных сценариев.

2. Scenario-based exploratory testing

Тестирование на основе пользовательских сценариев. Пример: "Пользователь хочет купить подарок другу". Действия определяете сами, но цель ясна.

3. Session-based test management (SBTM)

Структурированный подход с чартерами, таймбоксами, отчётами. Самый формализованный вариант ET.

«Scripted testing проверяет то, что вы знаете. Exploratory testing находит то, чего вы не знали» — Майкл Болтон, эксперт по тестированию

2. Когда использовать exploratory testing

ET не для всех ситуаций. Есть случаи, когда он максимально эффективен.

Идеальные сценарии для ET

1. Новый функционал без документации

Фича только что разработана. Требований нет или они расплывчаты. Тест-кейсы писать не из чего. ET позволяет исследовать и одновременно понимать, как работает.

2. Ограниченное время на тестирование

Релиз завтра, на тестирование 4 часа. Написать и выполнить тест-кейсы нереально. ET с чёткими чартерами даёт максимум покрытия за минимум времени.

3. Поиск неожиданных багов

Scripted тесты покрыли happy path. Нужно найти edge cases, integration issues, UX проблемы. ET отлично справляется.

4. Дополнение автоматизации

Автотесты проверяют регрессию. Но они не думают, не импровизируют. ET ищет то, что автоматизация пропустит.

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

Платежи, регистрация, checkout. Тест-кейсы есть, но нужна дополнительная проверка нестандартных комбинаций.

6. Новая команда знакомится с продуктом

Новый тестировщик. ET — отличный способ изучить продукт через исследование.

Когда ET менее эффективен

Баланс ET и scripted testing

Оптимальное соотношение зависит от контекста:

• Стартап, MVP, частые изменения: 60-70% ET, 30-40% scripted

• Enterprise, регулируемая индустрия: 30% ET, 70% scripted/автотесты

• Средний продукт: 50/50 баланс

3. Session-Based Test Management (SBTM)

Самый популярный подход к структурированному ET.

Что такое SBTM

Метод организации exploratory testing через ограниченные по времени сессии с чёткими целями (чартерами) и последующей отчётностью.

Основные элементы SBTM

1. Charter (чартер, миссия)

Цель тестовой сессии. Формат: "Исследовать [область] с помощью [ресурсов] чтобы обнаружить [информацию]".

Примеры хороших чартеров:

• "Исследовать функцию регистрации с различными email форматами чтобы обнаружить проблемы валидации"

• "Исследовать корзину покупок с большим количеством товаров (50+) чтобы найти проблемы производительности"

• "Исследовать мобильное приложение на разных разрешениях экрана чтобы найти UI проблемы"

Примеры плохих чартеров:

• "Протестировать приложение" (слишком широко)

• "Найти баги" (нет конкретики)

• "Проверить всё" (невыполнимо)

2. Time-box (таймбокс)

Ограниченное время на сессию. Обычно 45-90 минут. Это оптимум для фокуса и продуктивности.

Почему не 3 часа: Внимание падает, находки становятся менее ценными

Почему не 15 минут: Недостаточно времени для глубокого исследования

3. Test notes (заметки)

Записи во время сессии: что делали, что нашли, идеи для следующих тестов. Можно в любой форме: текст, скриншоты, видео.

4. Session report (отчёт сессии)

Краткая сводка после сессии.

Шаблон отчёта сессии:

• Charter: Какая была цель

• Start time: Когда начали

• Tester: Кто тестировал

• Duration: Сколько длилась сессия

• Test notes: Что делали (кратко)

• Bugs: Какие баги нашли (ссылки на issue tracker)

• Issues: Что мешало тестированию

• Coverage: Что покрыли (оценка %)

• Questions: Вопросы к команде

• Ideas for next session: Что проверить дальше

Пример отчёта:

Charter: Исследовать форму оплаты с разными типами карт

Duration: 60 минут

Test notes: Проверил Visa, MasterCard, AmEx, карты с истекшим сроком, невалидные номера, различные CVC коды. Тестировал на десктопе Chrome и Safari.

Bugs found: 3 (JIRA-1234, JIRA-1235, JIRA-1236)

Coverage: ~70% основных сценариев покрыто

Ideas: Проверить поведение при медленном интернете, протестировать на мобильных устройствах

4. Техники exploratory testing

Конкретные приёмы, которые помогают в ET.

Техника 1: Tours (туры)

Метафора туриста, который исследует город разными маршрутами.

Техника 2: Heuristics (эвристики)

Правила большого пальца для генерации тест-идей.

SFDPOT (San Francisco Depot):

• Structure: проверить структуру (навигация, иерархия)

• Function: проверить функциональность

• Data: разные типы данных (пустые, огромные, спецсимволы)

• Platform: разные платформы, ОС, браузеры

• Operations: последовательность действий, прерывания

• Time: временные факторы (таймауты, задержки)

FCC CUTS VIDS (эвристики для тестирования):

• Familiarity: насколько знакомо пользователю

• Complexity: насколько сложно

• Criticality: насколько критично

• И так далее...

Техника 3: Boundary testing

Проверка граничных значений:

• Минимум/максимум (например, поле "возраст": 0, 1, 150, 151)

• Пустые значения

• Очень длинные строки

• Спецсимволы, emoji, Unicode

Техника 4: Soap Opera testing

Драматичные, нереалистичные, но возможные сценарии:

• Пользователь нажал кнопку 100 раз подряд

• Открыл приложение в 50 вкладках одновременно

• Изменил системное время во время работы

• Потерял интернет на критичном моменте

Техника 5: Goldilocks testing

Слишком мало, слишком много, в самый раз. Пример для корзины:

• 0 товаров (слишком мало)

• 1000 товаров (слишком много)

• 5 товаров (в самый раз)

Техника 6: Pair exploratory testing

Два тестировщика вместе: один тестирует, второй наблюдает и генерирует идеи. Затем меняются ролями. Находят на 40-60% больше багов, чем поодиночке.

5. Как документировать exploratory testing

Главный страх менеджеров: "Как я узнаю, что ты протестировал?" Документация решает это.

Уровень 1: Минимальная документация

Для быстрых сессий, когда времени совсем нет.

Что фиксировать:

• Charter (что тестировали)

• Время (сколько потратили)

• Баги (ссылки на issue tracker)

Формат: Одно сообщение в Slack/Jira.

Пример:

"ET сессия 60 мин: форма регистрации, разные email форматы. Нашёл 2 бага: JIRA-123 (не принимает email с +), JIRA-124 (ошибка при клике Enter вместо кнопки)"

Уровень 2: Стандартная документация

Для большинства сессий.

Шаблон session sheet:

Charter: [Цель сессии]

Tester: [Имя]

Date/Time: [Когда]

Duration: [Сколько]

Areas covered:

• Функция A (70% покрыто)

• Функция B (30% покрыто)

Test approaches used:

• Boundary testing

• Different user roles

• Browser compatibility (Chrome, Firefox)

Bugs found:

• JIRA-234: Critical - Payment fails with AmEx

• JIRA-235: Minor - Typo on error message

Questions/Blockers:

• Нет тестового аккаунта с VIP статусом

• Staging environment недоступен

Next steps:

• Проверить на мобильных устройствах

• Тестировать интеграцию с CRM

Уровень 3: Детальная документация

Для критичных областей, compliance, обучения.

Дополнительно к уровню 2:

• Скриншоты/видео важных моментов

• Детальные шаги воспроизведения багов

• Mind map покрытия

• Матрица рисков

Инструменты документирования

Mind mapping для ET

Mind map — отличный способ планировать и документировать ET. Центр — область тестирования. Ветви — аспекты для проверки.

Пример структуры для "Login functionality":

• Login

  • Valid credentials

  • Invalid credentials

    • Wrong password

    • Wrong email

    • Non-existent user

  • Edge cases

    • Empty fields

    • SQL injection

    • XSS attempts

  • Different browsers

  • Session management

По мере тестирования отмечаете покрытые ветви цветом (зелёный = ОК, красный = баг, жёлтый = вопрос).

6. Планирование exploratory testing

ET требует планирования, даже если сами тесты импровизационные.

Шаг 1: Определите области для ET

Не всё подряд. Выберите приоритеты:

• Новый функционал

• Критичные user flows

• Области с частыми багами в прошлом

• Интеграционные точки

• Редко используемые функции (низкое покрытие автотестами)

Шаг 2: Создайте чартеры

Для каждой области 2-5 чартеров с разными углами атаки.

Пример для "Shopping cart":

1. Исследовать добавление товаров в корзину с различными атрибутами (размер, цвет) для выявления проблем синхронизации

2. Исследовать корзину при большом количестве товаров (50+) для обнаружения проблем производительности

3. Исследовать корзину при различных состояниях сети (медленное соединение, обрывы) для выявления проблем сохранения данных

4. Исследовать корзину на разных устройствах и браузерах для нахождения UI/UX проблем

Шаг 3: Оцените время

Каждый чартер = 1 сессия = 60-90 минут. Если чартер требует больше — разбейте на несколько.

Шаг 4: Распределите сессии

Между тестировщиками, учитывая экспертизу. Новичкам — простые чартеры, опытным — сложные.

Шаг 5: Установите метрики

Как измерите успех ET:

• Количество сессий

• Покрытие областей (%)

• Баги найдены / час ET

• Критичность багов

Пример плана ET на неделю:

Итого: 7.5 часов ET, 6 сессий, покрытие 4 критичных областей.

7. Навыки для эффективного ET

ET требует больше навыков, чем scripted testing.

1. Критическое мышление

Способность видеть неочевидные связи, задавать вопросы "а что если", строить гипотезы.

Как развивать: Читать postmortem багов, анализировать чужие находки, практиковать root cause analysis.

2. Доменная экспертиза

Понимание бизнес-логики, индустрии, пользователей. Нельзя хорошо тестировать банковское приложение, не понимая как работают переводы.

Как развивать: Разговаривать с продактами, читать требования, использовать продукт как пользователь.

3. Технические знания

Понимание архитектуры, DevTools браузера, SQL, API, логов. Это помогает идти глубже.

Как развивать: Изучать код, работать с разработчиками, использовать технические инструменты.

4. Наблюдательность

Замечать мелкие детали: задержки, неконсистентность, странное поведение. Баг не всегда кричит "Я БАГ!".

Как развивать: Записывать сессии на видео, пересматривать, учиться видеть паттерны.

5. Коммуникация

Умение описать баг, объяснить риск, аргументировать находки.

Как развивать: Практика написания баг-репортов, презентации результатов команде.

6. Креативность

Придумывать нестандартные сценарии, комбинации действий, которые никто не ожидает.

Как развивать: Играть в "а что если", изучать user behavior analytics, смотреть как используют конкуренты.

Прогрессия навыков ET

8. Инструменты для exploratory testing

Категория 1: Планирование и документирование

• Rapid Reporter: Лёгкий инструмент для заметок с автоматическими timestamps. Бесплатный.

• Session Tester: Специализированный инструмент для SBTM с шаблонами отчётов.

• XMind: Mind mapping для планирования покрытия.

• Miro / Mural: Коллаборативные доски для team exploratory sessions.

Категория 2: Запись и воспроизведение

• Loom: Запись экрана + комментарии. Отлично для документирования багов.

• OBS Studio: Профессиональная запись сессий.

• Testify: Специально для тестировщиков, захват шагов + screenshots.

Категория 3: Технические инструменты

• Browser DevTools: Console, Network, Performance для глубокого анализа.

• Postman: Для ET на уровне API.

• Charles Proxy / Fiddler: Перехват трафика, изменение запросов/ответов.

• React/Vue DevTools: Инспектирование state, props.

Категория 4: Моделирование условий

• Network Link Conditioner: Симуляция медленного интернета.

• BrowserStack / Sauce Labs: Тестирование на разных устройствах/браузерах.

• Lighthouse: Performance, accessibility, SEO audit.

Категория 5: Генерация тестовых данных

• Faker.js / Python Faker: Генерация реалистичных данных.

• Mockaroo: Создание CSV/JSON datasets.

• Big List of Naughty Strings: Опасные строки для проверки валидации.

Рекомендуемый набор инструментов

Для начала достаточно:

1. Rapid Reporter или просто Google Doc (документация)

2. XMind (планирование)

3. Browser DevTools (анализ)

4. Loom (запись багов)

Это бесплатно и покрывает 90% нужд.

9. Метрики и оценка эффективности ET

Как доказать, что ET приносит пользу?

Метрика 1: Bugs per session

Среднее количество багов на одну сессию ET.

Формула: Количество багов / Количество сессий

Benchmark: 1-3 бага на сессию — хорошо. 0.5 или меньше — возможно, слишком поверхностно или область стабильна.

Метрика 2: Critical bugs found

Сколько критичных/высокоприоритетных багов нашёл ET vs scripted testing.

Пример данных:

• ET: 15 critical bugs за квартал

• Scripted testing: 8 critical bugs

• Автотесты: 3 critical bugs

ET находит больше критичных — это его ценность.

Метрика 3: Coverage estimation

Процент покрытых областей. Субъективная оценка тестировщика после сессии.

Шкала:

• 0-30%: Поверхностное покрытие

• 30-60%: Среднее

• 60-90%: Хорошее

• 90-100%: Полное (редко достижимо)

Метрика 4: Time to bug (TTB)

Сколько времени потребовалось, чтобы найти первый баг.

Низкий TTB (5-10 минут) может означать очевидные проблемы. Высокий (40+ минут) — тщательное исследование или стабильная область.

Метрика 5: Session completion rate

% сессий, завершённых согласно чартеру.

Если много незавершённых — возможно, чартеры слишком амбициозные или есть блокеры.

Метрика 6: Ideas generated

Сколько идей для следующих тестов/улучшений продукта возникло.

ET должен генерировать инсайты, не только находить баги.

Пример дашборда ET метрик:

10. Типичные ошибки в ET

Ошибка 1: Отсутствие чартера

Просто кликаете наугад без цели. Результат: тратите время, находите мало.

Решение: Всегда начинайте с чартера, даже простого.

Ошибка 2: Слишком широкий чартер

"Протестировать весь продукт" за 60 минут невозможно. Получается поверхностно.

Решение: Узкие, конкретные чартеры. Лучше 5 глубоких сессий, чем одна поверхностная.

Ошибка 3: Нет документации

"Я всё помню" — не работает. Через день забудете, что тестировали.

Решение: Минимум — чартер, время, баги. Заведите привычку.

Ошибка 4: Игнорирование времени

Сессия должна была быть 60 минут, растянулась на 3 часа. Эффективность падает.

Решение: Таймер. Когда время вышло — остановитесь, задокументируйте, запланируйте продолжение.

Ошибка 5: Не используете инструменты

Тестируете только UI, не смотрите в DevTools, логи, network.

Решение: Используйте технические инструменты. Там много информации.

Ошибка 6: Повторяете одни и те же паттерны

Каждую сессию делаете одно и то же. Не развиваетесь.

Решение: Изучайте новые техники (tours, heuristics), пробуйте разные подходы.

Ошибка 7: Не коммуницируете находки

Нашли баг, завели тикет, забыли. Команда не знает о рисках.

Решение: Делитесь находками: в Slack, на стендапе, в отчётах. Особенно критичные.

Ошибка 8: ET только перед релизом

Весь спринт scripted тесты, последний день — ET. Поздно находить большие проблемы.

Решение: ET на протяжении всего цикла разработки.

11. ET в agile команде

Как интегрировать exploratory testing в scrum/kanban.

ET в спринте

Неделя 1 (разработка начинается):

• ET на прототипах/моках (если есть)

• Создание чартеров для новых фич

Неделя 2 (фичи на review):

• ET новых фич в dev environment

• Session-based testing критичных областей

• Баги заводятся, приоритизируются

Неделя 3 (staging):

• ET интеграций

• End-to-end сценарии

• Финальная проверка перед релизом

После релиза:

• ET на production (smoke)

• Мониторинг user feedback для идей следующих тестов

ET в ежедневных процессах

Daily standup: Упоминаете планируемые ET сессии

Code review: ET на основе изменений в коде (что могло сломаться?)

Demos: Используете ET подход при просмотре новых фич

Retro: Обсуждаете находки ET, улучшаете процесс

Распределение времени QA

Рекомендация для agile команды:

• 40% — Автоматизация (регрессия, smoke)

• 30% — Scripted testing (тест-кейсы для compliance)

• 20% — Exploratory testing

• 10% — Улучшение процессов, обучение

12. ET и автоматизация: как дополняют друг друга

ET не заменяет автоматизацию. Они работают вместе.

Что делает автоматизация хорошо

• Регрессионное тестирование (повторяемость)

• Большие объёмы данных

• Performance testing (нагрузка)

• CI/CD integration (быстрая обратная связь)

Что делает ET хорошо

• Новый функционал (где нет тест-кейсов ещё)

• Edge cases (нестандартные сценарии)

• UX проблемы (автотесты не видят)

• Интеграционные сюрпризы

• Exploratory mindset (находят неожиданное)

Цикл ET → Автоматизация

1. ET находит баг в новой фиче

2. Баг фиксится

3. Пишется автотест для регрессии

4. ET переключается на другие области

ET — это разведка. Автоматизация — это оборона территории.

Пример стратегии

Спринт 1 (новая фича):

• 70% времени QA на ET

• 30% на scripted тесты

Спринт 2 (стабилизация):

• 50% ET (edge cases)

• 50% автоматизация (покрытие багов из спринта 1)

Спринт 3+ (maintenance):

• 20% ET (выборочно)

• 80% автотесты (регрессия)

13. Примеры реальных ET сессий

Пример 1: E-commerce checkout

Charter: Исследовать процесс оплаты с различными комбинациями промокодов и способов доставки для выявления проблем расчёта стоимости

Duration: 75 минут

Approach:

• Применял 1, 2, 3 промокода одновременно

• Комбинировал с бесплатной/платной/express доставкой

• Тестировал на граничных суммах (0.01, 9999.99)

• Проверял на разных языках интерфейса

Bugs found:

• Critical: При применении 2 промокодов финальная сумма отрицательная

• High: Некорректный расчёт tax для международных заказов

• Medium: Промокод можно применить после истечения срока

Coverage: 60% сценариев покрыто

Next steps: Проверить поведение при отмене заказа с промокодом, тестировать на мобильных устройствах

Пример 2: Mobile app сценарий

Charter: Исследовать приложение в условиях прерываний (звонки, уведомления, переход в фон) для выявления проблем сохранения состояния

Duration: 60 минут

Approach:

• Начинал заполнение формы, получал звонок, возвращался

• Запускал другие приложения во время загрузки

• Блокировал экран на разных этапах

• Симулировал потерю сети в критичные моменты

Bugs found:

• Critical: Данные формы теряются при входящем звонке

• High: Приложение крашится при возврате из фона после 5+ минут

• Medium: Анимация загрузки зависает если переключиться на другое приложение

Coverage: 70%

Ideas: Проверить на старых версиях Android/iOS, тестировать при низком заряде батареи

14. Что запомнить

Exploratory testing — это не отсутствие планирования. Это планирование на лету с чётким фокусом и документацией.

Ключевые выводы:

• ET ≠ Ad-hoc. Это структурированный подход с чартерами, сессиями, отчётами.

• Дополняет, не заменяет. ET работает вместе со scripted testing и автоматизацией.

• Находит критичные баги. 78% серьёзных багов в production находят ET или пользователи, не scripted тесты.

• SBTM — золотой стандарт. Session-based подход даёт структуру без жёсткости тест-кейсов.

• Документация обязательна. Минимум: чартер, время, баги. Иначе это не ET, а хаос.

• Навыки развиваются. Критическое мышление, доменная экспертиза, креативность учатся практикой.

• Инструменты помогают. Rapid Reporter, mind maps, DevTools делают ET эффективнее.

• Метрики измеримы. Bugs per session, coverage, TTB показывают ценность ET.

«Лучшее тестирование — это когда тестировщик думает как хакер, действует как пользователь и документирует как учёный» — Джеймс Бах

С чего начать сегодня:

1. Выберите одну область продукта для ET (30 минут)

2. Напишите простой чартер: "Исследовать [что] чтобы найти [что]" (10 минут)

3. Заведите таймер на 60 минут (1 минута)

4. Откройте документ для заметок (Rapid Reporter или Google Doc) (2 минуты)

5. Начните сессию: тестируйте, наблюдайте, записывайте (60 минут)

6. Создайте краткий отчёт: что делали, что нашли (15 минут)

7. Поделитесь находками с командой (Slack/Jira) (5 минут)

Всего ~2 часа. Первая ET сессия готова.

Главный урок: Exploratory testing — это мышление, а не отсутствие процесса. Это умение задавать правильные вопросы продукту, видеть неочевидные проблемы и находить баги, которые пропустят все скрипты. Начните с малого, применяйте системно, документируйте результаты. ET станет вашим секретным оружием в борьбе за качество.

А лучшие вакансии для QA-инженеров и тестировщиков ищите на hirehi.ru