Бывают ситуации, когда продукт еще совсем новый, четких требований и документации по нему нет, поэтому помогает исследовательское тестирование (Exploratory testing) - подход, при котором тестировщик одновременно изучает программу, придумывает тесты и сразу же их выполняет
При тестировании важно учитывать, что:
Методы исследовательского тестирования помогают решить эти проблемы, а именно найти новые возможные дефекты и понять, какие лучше проверять первыми
В обычном, скриптовом тестировании (Scripted testing) уже задан план проверок (то есть список тест-кейсов), которые выполняются, и на основе выполнения которых образуется отчет тестирования системы
В исследовательском тестировании цикл проверки состоит из исследований системы:
Ожидаемое поведение определяют бизнес-требования. Но в исследовательском тестировании бизнес-требований зачастую нет, поэтому используют тестовый оракул - источник или принцип, по которому определяют ожидаемое поведение системы
Тестовым оракулом может быть: требование, бизнес-правило, спецификация API, предыдущее поведение, предметная область, согласованность интерфейса или ожидания пользователя
При наблюдении часто нет четкого ответа, является ли поведение системы правильным, вместо этого возникают вопросы (например, “является ли этот пользовательский сценарий логичным”) или подозрение (например, “дизайн интерфейса этого экрана не согласуется с дизайном другого экрана”)
Кроме этого, вывод из наблюдения зависит от контекста, например, из наблюдения “после отмены оплаты промокод больше нельзя использовать” может следовать, что это корректное поведение, если есть правило “промокод списывается после попытки оплаты”, или дефект, если есть правило “промокод списывается после успешной оплаты”
При наблюдениях важно фиксировать цель наблюдения, объяснять выбор проверок и сохранять важные наблюдения
Полный цикл исследования, посвященный одной цели, называют сессией
Чтобы исследование не затягивалось, сессии ограничивают по времени (такое ограничение называют таймбоксом). Также ограничивают область исследования - такая граница называется чартером. Чартер описывает не только функциональную область, но и потенциальный риск. Примером хорошего чартера является “исследовать восстановление оформления заказа после сбоя оплаты, чтобы оценить риск потери заказа или двойного списания”
Для появления идей чаще всего помогают эвристики, которые возникают из понимания предметной области
В качестве инструментов для исследования помимо эвристик и чартера используют тест-кейсы и чек-листы
Для исследования также определяют по мнемонике SFDPOT:
Дополнительно добавляют интерфейсы (то, как продукт взаимодействует с внешним миром), получая SFDIPOT
Также SFDPOT помогает выбрать направления для проверки
По модели покрытия можно понять, какой функционал системы исследован, а какой еще нет. Покрытие можно измерять по 6 аспектам: функции, состояния, риски, ошибки, платформы и данные
Само тестирование гипотезы производится из ранее изученных техник: классы эквивалентности и анализ граничных значений, таблицы решений, переходы состояний и так далее
По результатам исследовательского тестирования можно сохранить журнал действий, например, кликов. Такой журнал представляет собой сырые данные, которые сами по себе малоинформативны. Важно из этого журнала извлечь: цель сессии, ключевое наблюдение, проверенную гипотезу, свидетельство и результат, решение о смене направления, вопросы и новые риски
Свидетельство формируется из наблюдения, контекста, в котором наблюдение было сделано, и интерпретации того, какие риски могут возникнуть
По результатам сессии формируются:
Источниками рисков могут быть, например, данные пользователей, интеграции, необратимые действия, потеря финансов и так далее
При анализе риска формируются ответы на вопросы “насколько вероятно нежелательное событие?” и “насколько серьезным будет влияние?”. Далее риск оценивается по тяжести последствий и вероятности появления. Наибольший приоритет у тех рисков, где высоки и вероятность, и тяжесть последствий
На вероятность влияют сложность логики, большой объем изменений, появление похожих прошлых дефектов, нестабильность тестов, внешние зависимости и слабая наблюдаемость
Тяжесть последствий оценивается по ответам на вопросы:
На основе этого составляется список рисков, которые располагаются на матрице рисков с осями тяжесть-вероятность
Также риски можно поделить на два типа:
Также бывают ситуации, когда нет возможности оценить риск (например, из-за недоступности интеграций), важно зафиксировать такие ситуации как “остаточный риск”, чтобы в последствии уточнить с заказчиком
После исследовательской сессии также возможна повторная оценка риска. Риск с наибольшими тяжестью последствий и вероятностью проверяют не только как можно раньше, но и как можно тщательней
Вечно тестировать и исследовать невозможно, поэтому останавливаться стоит, когда: