Исследовательское Тестирование: констатирование фактов

Общаясь с коллегами тестировщиками, я очень часто слышу такие термины, как "тестирование методом свободного поиска" и "исследовательское тестирование". Под обоими терминами подразумевается Exploratory Testing - термин, который официально ввёл Кейнер (Cem Kaner) в 1983м, а позже стал использоваться основоположниками школы контестного тестирования для замены термина "ad hoc", снискавшего дурную славу в то время.
В русском эквиваленте я предпочитаю называть Exploratory Testing Исследовательским Тестированием (далее ИТ). Определение Кейнера звучит примерно так: ИТ – процесс тестирования заключающий в себе единовременно: разработку тестов (test design), их выполнение (test execution), и получение знаний о тестируемой системе (learning). Процесс тестирования в данном случае выглядит не как создание тестов и их последующее выполнение, а скорее протекает по следующему алгоритму:
1. Тестировщик тестирует систему, тем самым получае некоторые знания о ней.
2. Восполняет пробелы в информации о системе из других источников (документация, команда разработки, менеджер...)
3. На основе собранных знаний, тестировщик разрабатывает новые тесты.
Т.е. получается, что оракул (Oracle – своего рода набор оценочных критериев) эволюционирует каждый раз, когда тестировщик тестирует (часть ИТ, где он получает знания о системе).

Более современное определение (опять же Кейнера), ИТ - стиль тестирования ПО, в котором особо сильное значение имеет личная свобода и ответственность индивидуального тестировщика, направленная на непрерывное повышение качества его работы, и рассматривающий обучение во время тестирования, разработку тестов, их выполнение и интерпретацию результатов как взаимодополняющие активности, которые выполняются параллельно на протяжении всего проекта.

Исследовательское Тестирование – очень распространённый вид тестирования, которым пользуется каждый компетентный тестировщик. Например, после того как разработчик исправил дефект (выставил ему Fixed) и переназначил его обратно на тестировщика, который написал отчёт об этом дефекте – тестировщик не только убеждается, что дефект исправлен, но и проводит тестирование смежных функциональностей (workaround).
Тут имеем:
1. Изначально – заранее запланированный и подготовленный тест, который выявил дефект.
2. Ряд тестов, которые проверяют смежные функциональности (или ту же функциональность в более общем или конкретном виде) - тесты не запланированные и не задокументированные, они разрабатываются, прогоняются и оцениваются в тот конкретный момент, когда тестируются смежные функциональности, а это – ИТ.

Качество такого тестирования будет сильно зависеть от способностей тестировщика создавать тесты и находить дефекты. Однако, такой подход к тестированию обозначает непрерывное совершенствование - чем больше тестировщик знает о системе и методах тестирования, тем лучше будет тестирование.