Введение в Exploratory Testing
Exploratory testing—это одновременное обучение, проектирование тестов и выполнение тестов. В отличие от скриптованного тестирования, где вы выполняете предопределённые тест-кейсы, exploratory testing—это исследовательский подход, где тестировщик активно контролирует дизайн тестов по мере их выполнения, используя информацию, полученную во время тестирования, для проектирования новых и лучших тестов.
Думайте об exploratory testing (как обсуждается в From Manual to Automation: Complete Transition Guide for QA Engineers) (как обсуждается в Will AI Replace QA Engineers by 2030? The Future of Testing Profession) как о разнице между следованием GPS-маршруту и исследованием нового города пешком. GPS доставляет вас к месту назначения эффективно, но прогулка позволяет обнаружить скрытые жемчужины, понять характер района и найти проблемы, о которых GPS никогда не упоминал.
В этом всеобъемлющем руководстве мы исследуем искусство и науку exploratory testing—от структурированных подходов, таких как session-based testing, до творческих техник, таких как туры, от стратегий документирования до мощных эвристик, которые направляют ваше исследование.
Что такое Exploratory Testing?
Определение
Exploratory testing—это подход к тестированию программного обеспечения, который подчёркивает свободу и ответственность тестировщика непрерывно оптимизировать ценность своей работы, рассматривая обучение, связанное с тестированием, проектирование тестов, выполнение тестов и интерпретацию результатов тестов как взаимно поддерживающие действия, которые выполняются параллельно на протяжении всего проекта.
Ключевые характеристики:
- Управляется обучением: Понимание системы во время её тестирования
- Зависит от контекста: Адаптируется к тому, что вы находите
- Интенсивно по навыкам: Опирается на экспертизу тестировщика и критическое мышление
- Одновременно: Проектирование и выполнение происходят вместе
- Ограничено по времени: Часто структурировано в сфокусированные сессии
Exploratory vs Scripted Testing
Scripted testing:
1. Написать тест-кейсы
2. Пересмотреть тест-кейсы
3. Выполнить тест-кейсы
4. Отчитаться о результатах
Преимущества:
- Повторяемо
- Измеримое покрытие
- Хорошо для регрессии
- Младшие тестировщики могут выполнять
Недостатки:
- Медленно адаптируется
- Пропускает неожиданные сценарии
- Может быть бездумным выполнением
Exploratory testing:
1. Чартер/Миссия → Тест → Обучение → Адаптация → Тест → Обучение...
Преимущества:
- Находит удивительные баги
- Адаптируется в реальном времени
- Вовлекает креативность тестировщика
- Быстрая обратная связь
Недостатки:
- Сложнее измерить
- Требует опытных тестировщиков
- Менее повторяемо
- Может казаться неструктурированным
Реальность: Это не противоположные подходы—они комплементарны. Лучшие стратегии тестирования используют оба.
Когда использовать Exploratory Testing
Идеальные сценарии:
- Новые функции: Понимание незнакомой функциональности
- Короткие сроки: Необходимость быстро найти баги
- Расплывчатые требования: Когда спецификации неполные
- После автоматизации: Поиск того, что пропускают скрипты
- Критические пользовательские пути: Обеспечение реальной юзабилити
- Исследование регрессии: Понимание, почему падают автоматизированные тесты
- Security testing: Творческий поиск уязвимостей
- Оценка юзабилити: Испытание пользовательского путешествия
Не идеально для:
- Тестирование соответствия, требующее аудит-следов
- Требования точной повторяемости
- Сценарии, которые автоматизация обрабатывает хорошо
- Когда тестировщикам не хватает знаний о продукте
Session-Based Test Management (SBTM)
Что такое SBTM?
Session-Based Test Management—это структурированный подход к exploratory testing, который обеспечивает измеримость и ответственность, сохраняя свободу тестировщика исследовать.
Основные концепции:
- Чартер: Миссия или цель для сессии
- Сессия: Ограниченный по времени период непрерывного тестирования (обычно 45-120 минут)
- Дебрифинг: Обзор того, что произошло во время сессии
- Метрики: Отслеживание времени и покрытия
Чартер сессии
Чартер определяет, что вы тестируете, почему и как.
Формат чартера:
Исследовать [область]
С [ресурсами]
Для обнаружения [информации]
Примеры:
Чартер 1:
Исследовать: Рабочий процесс обработки платежей
С: Различными типами кредитных карт и суммами
Для обнаружения: Валидации, обработки ошибок и граничных случаев
Чартер 2:
Исследовать: Настройки профиля пользователя
С: Различными ролями и правами пользователей
Для обнаружения: Проблем контроля доступа и целостности данных
Чартер 3:
Исследовать: Функциональность загрузки файлов
С: Различными типами файлов, размерами и граничными случаями
Для обнаружения: Уязвимостей безопасности и обработки искажённых файлов
Чартер 4:
Исследовать: Функциональность поиска
С: Различными типами запросов (частичный, точный, специальные символы)
Для обнаружения: Проблем производительности и релевантности
Характеристики хорошего чартера:
- Достаточно конкретный для фокусировки тестирования
- Достаточно широкий для разрешения исследования
- Соответствующий по времени для длительности сессии
- Ясная миссия, которая направляет, но не ограничивает
Анти-паттерны чартера:
- ❌ Слишком расплывчато: "Тестировать приложение"
- ❌ Слишком конкретно: "Проверить, что кнопка входа синяя"
- ❌ Слишком широко: "Найти все баги в системе"
- ❌ Без фокуса: "Кликать и смотреть, что происходит"
✓ В самый раз: "Исследовать аутентификацию с различными комбинациями учётных данных для обнаружения уязвимостей безопасности"
Планирование сессии
Перед сессией:
1. Определить чартер
- Что вы тестируете?
- На какие вопросы хотите ответить?
- Какие риски вас беспокоят?
2. Собрать ресурсы
- Тестовые данные
- Инструменты
- Доступ к окружению
- Документацию
3. Установить time box
- Обычно 60-90 минут
- Достаточно короткий для поддержания фокуса
- Достаточно длинный для входа в поток
4. Минимизировать прерывания
- Заблокировать календарь
- Отключить уведомления
- Установить ожидание времени фокуса
Во время сессии
Цикл тестирования:
1. Начать с чартера
2. Исследовать и тестировать
3. Заметить что-то интересное
4. Исследовать глубже
5. Найти баг или узнать что-то новое
6. Кратко документировать
7. Продолжить исследование
8. Следовать новым нитям
9. Вернуться к чартеру, если слишком отклоняетесь
10. Отмечать идеи для будущих сессий
Распределение времени (типичная 90-минутная сессия):
Настройка сессии: 5 минут
Тестирование: 75 минут
Отчёт о багах: 5 минут
Заметки: 5 минут (на протяжении)
Заметки в реальном времени:
Вести журнал тестирования:
- Что вы тестируете
- Что вы наблюдаете
- Возникающие вопросы
- Идеи для дальнейшего тестирования
- Найденные баги
- Потраченное время
Пример журнала:
10:00 - Начата сессия: Чартер обработки платежей
10:05 - Тестирование валидного потока кредитной карты - работает как ожидается
10:15 - Попытка невалидных номеров карт - ошибки ясные
10:20 - Вопрос: Что происходит с истёкшими картами?
10:25 - Найден баг: Истёкшая карта обработана в любом случае! Зарегистрировано как BUG-123
10:35 - Тестирование сумм платежей - отрицательные числа...
10:37 - Баг: Отрицательная сумма создаёт кредит! BUG-124
10:45 - Исследование потока возврата...
После сессии: дебрифинг
Отчёт о сессии должен включать:
Чартер: [Что вы тестировали]
Продолжительность: [Реально потраченное время]
Заметки о тестах: [Что вы делали, что нашли]
Найденные баги: [Список с ID]
Проблемы: [Блокеры или опасения]
Вопросы: [Вещи, в которых не уверены]
Новые чартеры: [Идеи для будущих сессий]
Покрытие: [Что было протестировано vs не протестировано]
Пример отчёта о сессии:
ОТЧЁТ О СЕССИИ
Чартер: Исследовать обработку платежей с различными сценариями кредитных карт
для обнаружения проблем валидации и безопасности
Продолжительность: 90 минут
Протестированные области:
- Валидная обработка кредитных карт (Visa, MasterCard, Amex)
- Обработка невалидного номера карты
- Обработка истёкшей карты
- Различные суммы платежа (малые, большие, десятичные)
- Специальные символы в имени держателя карты
- Конкурентные платежи
Найденные баги:
- BUG-123: Истёкшие кредитные карты принимаются и обрабатываются
- BUG-124: Отрицательные суммы платежа создают кредиты
- BUG-125: XSS уязвимость в поле имени держателя карты
Проблемы:
- Тестовое окружение было медленным, влияя на продуктивность
- Не мог протестировать международные карты (заблокированы в тестовом env)
Вопросы:
- Каково ожидаемое поведение для транзакций $0.00?
- Должны ли мы обрабатывать карты, истекающие в этом месяце, по-другому?
Идеи новых чартеров:
- Исследовать обработку платежей с международными кредитными картами
- Исследовать граничные случаи потока возврата
- Тестировать конкурентные сценарии платежей под нагрузкой
Покрытие:
Протестировано: Базовый счастливый путь, случаи ошибок, основы безопасности
Не протестировано: Производительность при масштабе, все типы международных карт
Заметки:
Фокус был на безопасности и валидации. Найдена критическая проблема
с истёкшими картами. Рекомендую приоритизировать исправление BUG-123.
Метрики SBTM
Отслеживать метрики для показа ценности:
1. Разбивка времени сессии:
Общее время сессии: 90 минут
- Выполнение теста: 70 минут (78%)
- Исследование бага: 10 минут (11%)
- Настройка/админ: 10 минут (11%)
2. Отслеживание покрытия:
Области в чартере: 5
Протестированные области: 4
Непротестированные области: 1
Покрытие: 80%
3. Метрики продуктивности:
Завершённые сессии: 20
Найденные баги: 15
Критические баги: 3
Время до первого бага: Среднее 15 минут
4. Индикаторы обучения:
Поднятые вопросы: 45
Чартеры, сгенерированные из сессий: 12
Идентифицированные пробелы в документации: 8
Tour-Based Testing
Что такое туры?
Туры—это предопределённые паттерны или темы для исследования приложения, как туристический гид, показывающий вам различные аспекты города. Каждый тур фокусируется на конкретной перспективе или типе тестирования.
Метафора туриста
Представьте, что вы посещаете новый город:
- Тур делового района: Увидеть, где происходит работа
- Тур развлекательного района: Испытать ночную жизнь и веселье
- Исторический тур: Узнать историю города
- Тур по переулкам: Найти скрытые и менее отшлифованные области
Аналогично, программные туры исследуют различные аспекты приложения.
Типы туров
Туры делового района (ориентированные на пользователя)
1. Тур по путеводителю
Следуйте "официальным" путям—используйте приложение точно так, как задокументировано
в руководствах пользователя и учебниках.
Цель: Проверить точность документации
Вопросы для задавания:
- Работают ли задокументированные шаги?
- Обновлены ли скриншоты?
- Ясны ли инструкции?
- Соответствует ли фактическое поведение описанному?
Пример: E-commerce сайт
- Следовать руководству "Как сделать первую покупку"
- Попробовать учебник "Как вернуть товар"
- Выполнить инструкции "Как отследить заказ"
2. Денежный тур
Следуйте путями, которые делают деньги или доставляют основную ценность.
Цель: Протестировать критическую бизнес-функциональность
Фокус на:
- Функции, генерирующие доход
- Основные ценностные предложения
- Функции, за которые платят клиенты
- Воронки конверсии
Пример: Сервис подписки
- Поток регистрации → Платёж → Доступ к премиум-функциям
- Обновление до более высокого уровня
- Процесс продления
- Реферальная программа
3. Тур достопримечательностей
Тестируйте самые заметные, видимые или рекламируемые функции.
Цель: Проверить работу главных функций
Фокус на:
- Функции в маркетинговых материалах
- Элементы основной навигации
- Рекламируемые возможности
- Демо-сценарии
Пример: Инструмент управления проектами
- Вид доски (если это флагманская функция)
- Совместная работа в реальном времени
- Синхронизация мобильного приложения
- Интеграции с популярными инструментами
4. Тур FedEx
Следуйте за данными через систему—от входа до выхода, через все
этапы обработки.
Цель: Тестировать поток и целостность данных
Отслеживать:
- Создание данных
- Трансформацию данных
- Хранение данных
- Извлечение данных
- Экспорт данных
Пример: CRM система
- Создать контакт → Назначить торговому представителю → Добавить в кампанию →
Отследить взаимодействия → Сгенерировать отчёт → Экспортировать данные
Туры развлекательного района (пользовательский опыт)
5. Тур супермодели
Фокус на пользовательском интерфейсе и визуальном представлении.
Цель: Оценить эстетику и визуальный дизайн
Искать:
- Визуальную консистентность
- Выравнивание и пространство
- Цветовую схему
- Типографику
- Адаптивный дизайн
- Доступность
Пример:
- Проверить, что все кнопки имеют консистентный стиль
- Проверить адаптивное поведение при разных размерах экрана
- Протестировать тёмный режим
- Валидировать контраст цвета
- Проверить визуальные баги (наложение текста, обрезанные изображения)
6. Тур шотландского паба
Попробовать каждое меню, кнопку и функцию, которую можете найти.
Цель: Проверить, что все интерактивные элементы работают
Тестировать:
- Каждую кнопку
- Каждую ссылку
- Каждый элемент меню
- Каждое поле формы
- Каждое сокращение клавиатуры
Пример: Страница настроек
- Кликнуть по каждой вкладке
- Переключить каждый переключатель
- Сохранить каждую конфигурацию
- Протестировать каждую опцию выпадающего списка
7. Тур лежебоки
Тестируйте с минимальным усилием—ленивое поведение пользователя.
Цель: Увидеть, что происходит с минимальным вводом
Попробовать:
- Пропустить необязательные поля
- Использовать дефолты везде
- Принять все дефолты
- Взять путь наименьшего сопротивления
Пример: Настройка аккаунта
- Пропустить фото профиля
- Использовать настройки по умолчанию
- Не заполнять необязательные поля
- Принять рекомендованные опции
Туры исторического района (обратная совместимость)
8. Тур по переулкам
Идите к менее видимым, старым или редко используемым функциям.
Цель: Найти заброшенные области
Фокус на:
- Legacy функциях
- Админ-панелях
- Страницах настроек
- Страницах ошибок
- Справочной документации
- Устаревших функциях, всё ещё доступных
Пример:
- Старая функциональность импорта/экспорта
- Legacy генераторы отчётов
- Режимы совместимости
- Админские инструменты отладки
9. Тур музея
Тестировать со старыми данными, старыми форматами, старыми браузерами, старыми устройствами.
Цель: Проверить обратную совместимость
Тестировать с:
- Старыми форматами файлов
- Данными из предыдущих версий
- Старыми браузерами
- Legacy устройствами
- Историческими данными
Пример:
- Импортировать файлы, созданные годы назад
- Использовать IE11 или более старый браузер
- Тестировать на iPhone 6
- Загрузить аккаунт с 10-летней историей
Туры сомнительного района (негативное тестирование)
10. Тур саботажника
Пытайтесь ломать вещи намеренно.
Цель: Найти проблемы безопасности и стабильности
Попробовать:
- Попытки SQL-инъекции
- Попытки XSS
- Переполнения буфера
- Невалидные входы
- Обходы аутентификации
Пример:
- Ввести JavaScript в текстовые поля
- Использовать ' OR '1'='1 во входах
- Загрузить исполняемый файл как изображение
- Манипулировать URL
- Изменять cookies
11. Обсессивно-компульсивный тур
Повторять одно и то же действие много раз.
Цель: Найти проблемы с повторением
Тестировать:
- Быстрые клики
- Множественные отправки
- Много товаров в корзине
- Тысячи записей
- Очень длинный текст
Пример:
- Кликать кнопку сохранения 100 раз быстро
- Добавить 1000 элементов в список
- Ввести текст из 10,000 символов
- Создать 50 вкладок браузера
12. Тур неправильного поворота
Взять каждый неправильный путь, возможный.
Цель: Тестировать обработку ошибок
Попробовать:
- Неправильные учётные данные
- Невалидные входы
- Истёкшие сессии
- Отсутствующие параметры
- Сломанные ссылки
- 404 страницы
Пример:
- Войти с неправильным паролем
- Отправить форму со всеми невалидными данными
- Навигировать к несуществующим URL
- Дать сессии истечь mid-workflow
- Удалить необходимые URL параметры
Туры экстремального тестирования
13. Тур всю ночь
Запустить длительные тесты.
Цель: Найти проблемы, зависящие от времени
Тестировать:
- Оставить приложение открытым на часы
- Запустить ночные процессы
- Тестировать ровно в полночь
- Пересечь часовые пояса
- Переходы на летнее время
Пример:
- Оставить сессию активной на 24 часа
- Запланировать отчёты на полночь
- Тестировать изменения часового пояса
- Запустить пакетные процессы overnight
14. Тур сборщика мусора
Заполнить систему мусором и посмотреть, что ломается.
Цель: Тестировать управление ресурсами
Создать:
- Dummy аккаунты
- Мусорные данные
- Большие файлы
- Много записей
- Полное хранилище
Пример:
- Загрузить максимальный размер файла
- Создать тысячи тестовых записей
- Заполнить разрешённое хранилище
- Максимизировать все лимиты
Эффективное использование туров
Комбинирование туров:
Сессия 1: Денежный тур + Тур FedEx
→ Тестировать критический бизнес-поток и целостность данных
Сессия 2: Тур супермодели + Тур музея
→ Тестировать консистентность UI в старых браузерах
Сессия 3: Тур саботажника + Тур неправильного поворота
→ Глубокое погружение в безопасность и обработку ошибок
Адаптация туров:
Настроить туры для вашего приложения:
- Мобильное приложение? Добавить "Тур одной рукой" (только досягаемость большого пальца)
- API? Добавить "Тур контракта" (тестировать API контракты)
- Dashboard? Добавить "Тур Data Viz" (тестировать все графики)
- Тяжёлые формы? Добавить "Тур клавиши Tab" (навигация только по клавиатуре)
Эвристики для Exploratory Testing
Что такое эвристики?
Эвристики—это правила большого пальца, сокращения или мыслительные помощники, которые помогают тестировщикам знать, где искать и что тестировать. Они не гарантии—они образованные догадки, основанные на опыте.
Эвристики тестирования
Эвристика CRUD
Тестировать операции Create, Read, Update, Delete для всех сущностей.
Для каждого объекта данных тестировать:
✓ Создание новых экземпляров
✓ Чтение/просмотр экземпляров
✓ Обновление/модификация экземпляров
✓ Удаление/устранение экземпляров
Также тестировать:
- Создать без обязательных полей
- Создать дубликат
- Прочитать несуществующий
- Обновить с невалидными данными
- Обновить несуществующий
- Удалить и попытаться получить доступ
- Удалить и пересоздать с тем же ID
Эвристика Златовласки
Тестировать слишком мало, слишком много и в самый раз.
Для каждого количества или значения:
- Слишком маленькое: 0, 1, минимум
- Слишком большое: максимум, максимум+1, бесконечность
- В самый раз: типичное значение
Примеры:
- Загрузка файла: 0 байт, 1 байт, макс размер, макс+1
- Текстовое поле: пусто, 1 символ, макс длина, макс+1
- Список: 0 элементов, 1 элемент, много элементов, макс элементов
- Цена: $0, $0.01, $9999.99, отрицательная, не числовая
Эвристика SFDIPOT
Structure, Function, Data, Interfaces, Platform, Operations, Time
Structure: Архитектура, организация кода
Function: Что делают функции
Data: Поток информации и хранение
Interfaces: UI, API, интеграции
Platform: ОС, браузер, устройство
Operations: Установить, обновить, настроить
Time: Тайминг, последовательности, планирование
Эвристика границ
Ошибки любят границы—тестируйте на краях.
Общие границы:
- Мин/макс значения
- Первый/последний элементы
- Начало/конец временных периодов
- Пустой/полный
- Вошёл/вышел
- Подключён/отключён
Примеры:
- Первый день месяца/года
- Последняя запись в базе данных
- Ровно в полночь
- Максимальный размер файла
- Пустая корзина vs полная корзина
Эвристика консистентности
Вещи, которые должны совпадать, должны совпадать.
Проверить консистентность в:
- Разных страницах/экранах
- Разных браузерах/устройствах
- Разных ролях пользователей
- Разных языках
- Разных состояниях
Примеры:
- Кнопка "Submit" всегда "Submit" или иногда "Send"?
- Все поля даты используют один формат?
- Сообщения об ошибках консистентны по стилю?
- Мобильное приложение соответствует веб-приложению?
Эвристика CRUD + SCAN
За пределами базового CRUD, также тестировать:
Search
Copy
Archive
Navigate
Для каждой сущности:
- Искать её
- Копировать/дублировать её
- Архивировать/мягко удалять её
- Навигировать к/от неё
Оракулы: как узнать, что что-то неправильно
Оракул—это принцип или механизм для распознавания проблемы.
Общие оракулы:
1. Оракул спецификации:
Сравнить поведение с задокументированными требованиями.
Проблема: Спецификации могут быть неправильными или неполными.
2. Оракул сравнимого продукта:
Сравнить с конкурентом или предыдущей версией.
Пример: "Gmail разрешает вложения 25MB, мы тоже должны"
3. Оракул консистентности:
Ожидать, что похожие вещи ведут себя одинаково.
Пример: Если Сохранить это Ctrl+S в одном диалоге, это должно быть везде.
4. Оракул истории:
Это работало раньше, так что должно продолжать работать.
Пример: Регрессионное тестирование использует этот оракул.
5. Оракул пользовательских ожиданий:
Что ожидал бы разумный пользователь?
Пример: Клик по X должен закрыть окно.
6. Оракул уставов и стандартов:
Юридические требования, отраслевые стандарты (WCAG, GDPR и т.д.)
Пример: Должно соответствовать стандартам доступности.
Документирование Exploratory Testing
Почему документировать?
Преимущества:
- Позволяет делиться знаниями
- Предоставляет доказательства тестирования
- Поддерживает воспроизведение багов
- Идентифицирует пробелы в покрытии
- Облегчает передачу
- Создаёт репозиторий обучения
Что документировать
Минимально жизнеспособная документация:
1. Чартер/Цель
2. Что было протестировано
3. Что было найдено
4. Что не было протестировано
5. Поднятые вопросы
Всесторонняя документация:
1. Детали сессии (дата, время, продолжительность, тестировщик)
2. Чартер
3. Тестовые области и покрытие
4. Использованные тестовые данные
5. Детали окружения
6. Наблюдения и заметки
7. Найденные баги (с ID)
8. Вопросы и идеи
9. Идентифицированные риски
10. Последующие чартеры
Форматы документации
1. Ментальные карты
Визуализировать пути исследования и находки.
Центральный узел: Функция/область, тестируемая
Ветви: Различные протестированные аспекты
Листья: Конкретные тесты и находки
Инструменты: XMind, MindMeister, FreeMind
Пример структуры:
Обработка платежей
/ | \
Валидно Невалидно Граничные случаи
/ | \
Visa,MC,Amex Формат $0, Отрицательное
| | |
Работает! Хорошие ошибки БАГ!
2. Листы сессии
Структурированный шаблон для заметок.
МИССИЯ: [Чартер]
ВРЕМЯ НАЧАЛА: [Время]
ПРОДОЛЖИТЕЛЬНОСТЬ: [Минуты]
ТЕСТИРОВЩИК: [Имя]
ЗАМЕТКИ:
[Время] - [Выполненное действие]
[Время] - [Наблюдение]
[Время] - [Найденный баг]
БАГИ: [Список с ID]
ВОПРОСЫ: [Открытые элементы]
ПОКРЫТИЕ: [Что было/не было протестировано]
3. Экранные записи
Записывать исследовательские сессии.
Преимущества:
- Полная запись
- Воспроизведение багов
- Обучающий материал
- Обзор и обучение
Инструменты: OBS, Loom, SnagIt, Camtasia
Когда записывать:
✓ Security testing
✓ Сложное воспроизведение багов
✓ Обучение новых тестировщиков
✓ Когда стейкхолдеры хотят видеть тестирование
✗ Каждую сессию (слишком много данных)
4. Аннотированные скриншоты
Визуальные отчёты о багах и заметки.
Инструменты: Snagit, Skitch, Annotate, CloudApp
Включать:
- Стрелки, указывающие на проблемы
- Текстовые аннотации
- Красные коробки вокруг проблем
- Шаги для воспроизведения
- Ожидаемое vs фактическое
5. Тестовые заметки в коде
Для технического тестирования, документировать в комментариях или docs.
Пример:
/*
* СЕССИЯ ИССЛЕДОВАТЕЛЬСКОГО ТЕСТИРОВАНИЯ: API Аутентификация
* Дата: 2025-09-30
* Чартер: Протестировать граничные случаи JWT токена
*
* Находки:
* - Истёкшие токены правильно отклонены
* - Искажённые токены обработаны gracefully
* - БАГ: Токен с модифицированным payload принят (BUG-456)
*
* Не протестировано:
* - Поток обновления токена
* - Конкурентные сессии
*/
Чек-листы Exploratory Testing
Чек-лист перед сессией
Окружение:
- [ ] Тестовое окружение доступно
- [ ] Тестовые данные доступны
- [ ] Инструменты готовы (браузер, debugger и т.д.)
- [ ] Чистое состояние (или известное состояние)
Подготовка:
- [ ] Чартер определён
- [ ] Время выделено
- [ ] Прерывания минимизированы
- [ ] Шаблон документации готов
Знание:
- [ ] Последние изменения поняты
- [ ] Требования пересмотрены
- [ ] Предыдущие баги пересмотрены
- [ ] Пользовательские персоны в уме
Чек-лист во время сессии
Тестирование:
- [ ] Свободно следовать чартеру
- [ ] Делать заметки по ходу
- [ ] Замечать паттерны
- [ ] Следовать догадкам
- [ ] Ставить под вопрос предположения
- [ ] Немедленно логировать баги
- [ ] Делать скриншоты проблем
Мышление:
- [ ] Оставаться любопытным
- [ ] Спрашивать "что если?"
- [ ] Быть скептичным
- [ ] Думать как пользователь
- [ ] Думать как атакующий
- [ ] Замечать несоответствия
Чек-лист после сессии
Документация:
- [ ] Заметки сессии завершены
- [ ] Баги зарегистрированы с деталями
- [ ] Скриншоты прикреплены
- [ ] Вопросы задокументированы
- [ ] Покрытие отмечено
Последующие действия:
- [ ] Новые чартеры идентифицированы
- [ ] Стейкхолдеры информированы
- [ ] Критические баги эскалированы
- [ ] Извлечённые уроки зафиксированы
Хозяйство:
- [ ] Тестовые данные очищены (если нужно)
- [ ] Окружение сброшено (если нужно)
- [ ] Инструменты закрыты
- [ ] Метрики обновлены
Общий чек-лист эвристик тестирования
Вариации:
- [ ] Протестировано с различными данными
- [ ] Протестировано с различными пользователями
- [ ] Протестировано в различных состояниях
- [ ] Протестировано на различных платформах
Границы:
- [ ] Минимальные значения
- [ ] Максимальные значения
- [ ] Пустой/null
- [ ] Первый/последний
Ошибки:
- [ ] Невалидные входы
- [ ] Отсутствующие входы
- [ ] Неправильная последовательность
- [ ] Прерывания
Производительность:
- [ ] Большие наборы данных
- [ ] Медленные соединения
- [ ] Длительные операции
- [ ] Конкурентные пользователи
Безопасность:
- [ ] Попытки обхода аутентификации
- [ ] Нарушения авторизации
- [ ] Инъекция ввода
- [ ] Раскрытие данных
Лучшие практики для Exploratory Testing
1. Балансировать структуру и свободу
✓ Иметь чартер, но не быть жёстким
✓ Делать заметки, но не останавливать исследование
✓ Следовать догадкам, но отслеживать покрытие
✓ Быть креативным, но оставаться сфокусированным
2. Думать как множество персон
Тестировать как:
- Новый пользователь (запутанный, следующий учебникам)
- Опытный пользователь (горячие клавиши, продвинутые функции)
- Злонамеренный пользователь (пытающийся сломать безопасность)
- Небрежный пользователь (кликающий без чтения)
- Бизнес-стейкхолдер (доставлена ли ценность?)
3. Парное exploratory testing
Преимущества:
- Две перспективы
- Обсуждение в реальном времени
- Один тестирует, другой документирует
- Обмен знаниями
- Больше найденных багов
Роли:
- Водитель: Управляет клавиатурой/мышью, выполняет тесты
- Навигатор: Предлагает идеи, делает заметки, задаёт вопросы
Менять роли каждые 20-30 минут
4. Использовать инструменты для усиления тестирования
Основные инструменты:
- Developer tools (Chrome DevTools, Firefox Dev Tools)
- Proxy tools (Charles, Fiddler, Burp Suite)
- Screenshot tools (Snagit, ShareX)
- Note-taking (Evernote, Notion, markdown редакторы)
- Screen recording (OBS, Loom)
- Генераторы тестовых данных
- Инструменты ментальных карт
5. Непрерывно учиться
После каждой сессии:
✓ Что вы узнали о продукте?
✓ Что вы узнали о тестировании?
✓ Что бы вы сделали по-другому?
✓ Какие новые вопросы возникли?
✓ Какие паттерны вы заметили?
6. Отслеживать и отчитываться о ценности
Метрики, которые важны:
- Найденные баги (особенно критические)
- Отвеченные вопросы
- Идентифицированные риски
- Достигнутое покрытие
- Инвестированное время
Коммуницировать:
- Делиться интересными находками
- Немедленно выделять критические баги
- Предлагать новые чартеры на основе открытий
- Обучать команду тому, что вы узнали
7. Чередовать подходы
Варьировать ваш подход к тестированию:
- Понедельник: На основе туров
- Вторник: Сфокусировано на эвристиках
- Среда: Управляемо персонами
- Четверг: Сфокусировано на интеграции
- Пятница: Креативно/экспериментально
Предотвращает:
- Туннельное зрение тестирования
- Скуку
- Убывающую отдачу
Распространённые ошибки и как их избежать
Ошибка 1: бесцельное блуждание
Проблема: “Я просто кликаю без цели.”
Решение:
- Всегда начинать с чартера
- Установить таймер
- Иметь вопрос фокуса
- Использовать туры как структуру
Ошибка 2: не документировать
Проблема: “Я нашёл баги, но не записал их.”
Решение:
- Документировать по ходу, не в конце
- Использовать шаблоны для быстроты
- Немедленно делать скриншоты
- Записывать заметки голосом, если набор медленный
Ошибка 3: поверхностное тестирование
Проблема: “Я тестировал только счастливые пути.”
Решение:
- Использовать эвристики для направления более глубокого тестирования
- Спрашивать “что может пойти не так?”
- Явно тестировать случаи ошибок
- Следовать туру саботажника
Ошибка 4: игнорирование контекста
Проблема: “Я нашёл баг, который на самом деле ожидаемое поведение.”
Решение:
- Сначала понять требования
- Задавать вопросы перед отчётом
- Знать свои оракулы
- Учитывать намерение пользователя
Ошибка 5: не отслеживать время
Проблема: “Я потратил 4 часа на одну вещь.”
Решение:
- Использовать time-boxes
- Устанавливать будильники
- Отслеживать потраченное время
- Двигаться дальше при убывающей отдаче
Ошибка 6: тестирование в изоляции
Проблема: “Никто не знает, что я тестирую.”
Решение:
- Делиться планами сессий
- Регулярно проводить дебрифинг
- Быстро отчитываться о находках
- Сотрудничать с разработчиками
Заключение
Exploratory testing—это и искусство, и навык. Оно требует:
- Любопытства для задавания вопросов
- Скептицизма для опровержения предположений
- Креативности для воображения сценариев
- Дисциплины для документирования находок
- Адаптивности для изменения направления
- Интуиции, развитой через опыт
Красота exploratory testing в том, что оно масштабируется с вашим навыком—младший тестировщик, следующий турам и эвристикам, будет находить баги, в то время как опытный тестировщик с глубоким знанием продукта будет находить критические, тонкие проблемы, которые скриптованные тесты никогда не поймают.
Начните с малого:
- Запустите 60-минутную сессию с чётким чартером
- Используйте один тур или эвристику как руководство
- Документируйте то, что найдёте
- Учитесь на опыте
- Повторяйте, улучшайте, совершенствуйте
Со временем вы разовьёте инстинкт того, где скрываются баги, какие вопросы задавать и как заставить каждую минуту тестирования считаться.
Помните: Exploratory testing не заменяет скриптованное тестирование—оно дополняет его. Используйте оба подхода стратегически для построения всестороннего покрытия тестирования, которое является и систематическим, и проницательным.
Дополнительное чтение
- “Explore It!” Элизабет Хендриксон
- “Lessons Learned in Software Testing” Цема Канера, Джеймса Баха, Брета Петтихорда
- “Testing Computer Software” Цема Канера
- Блог Джеймса Баха: satisfice.com
- Блог Майкла Болтона: developsense.com
- Методология Rapid Software Testing