Exploratory testing: плюсы и минусы

Исследовательское тестирование как вид не так давно вошло в мою жизнь, однако, это произошло довольно стремительно и неожиданно.
Я работала в условиях постоянного тестирования функционала по тест плану, и тут внезапно стали добавлять время на так называемое "wild testing". В моем понимании суть этого вида тестирования была в том, чтобы просто поклацать, что "ничего не падает", и я не находила никаких багов вне тест плана. Возможно, это было связано с недостатоком опыта на тот момент,а, возможно, неправильным настроем на работу :) Баги имеют интересное свойство: когда ждешь,что их нет - они умело маскируются. Но если подходить к тестированию с мыслью, что "там ТОЧНО что-то есть" - только успевай записывать и фотографировать :)
Но потом условия несколько изменились и на тест планы уже не было времени (хоть я очень скептически отношусь к таким утверждениям). На помощь пришло тестирование методом свободного поиска, благо, к тому времени я уже достаточно прочитала и имела побольше опыта нахождения ошибок. Так я работала примерно с полгода, тестируя все проекты именно методом свободного поиска.

В чем была выгода его использования?
1. Тестирование методом свободного поиска меньше утомляет,чем тестирование по заранее написанному тест плану по всем правилам.
2. Приветствуется полет мысли. В тестировании строго по тест плану нет места возможности применения своего опыта или смекалки. Заранее написано куда ткнуть, сколько раз и в каком порядке. Не будешь следовать инструкциям - не сможешь сказать,что прошел именно этот тест кейс. Исследовательское тестирование, наоборот, позволяет тестировать, используя свой мозг и свой опыт, а не просто читать и повторять сценарий на другом билде. А творческая немонотонная работа, как правило, мотивирует людей. А уж сколько радости приносит обнаружение бага в сложном сценарии, который, вероятнее всего, не был бы внесен в тест план!
3. Время. Написание, поддержание и прохождение тест кейсов по тест плану занимает ощутимо больше времени ввиду понятных факторов - тест план нужно писать, поддерживать и затем читать каждый тест кейс пере прохождением :) Тестирование методом свободного поиска позволяет сэкономить время на тестирование. Однако, есть некоторые риски, с которыми придется мирится, используя этот вид тестирования.

Минусы\риски

1. Отсутствие внятной статистики. Учитывая, что тест плана как такового нет - единственный способ понять состояние продукта - это открытые баги в багтрекере. Возможности просчитать статистику изменения состояния продукта мининмальны. К тому же, можно ли будет верить статистике, основанной на количестве открытых\закрытых багов, если невозможно понять, какие именно тесты проводил тестировщик над продуктом? Все ли необходимые тесты были выполнены? Были ли результаты всех тестов интерпретированы верно, или есть шанс, что часть багов были приняты за нормальное поведение системы?
2. Из первого пункта выходит вывод - исследовательское тестирование следует поручать людям, у которых уже есть опыт тестирования подобных приложений, да и вообще, есть опыт нахождения заковыристых багов. Как правило, тестировщик анализирует найденные когда-либо баги и далее, встречая подобные ситуации и части программы, может предположить, где ему искать баги в новой программе, учитывая старый опыт. То же самое с программистами - некоторые из них делают похожие ошибки довольно часто, и, зная программиста, можно сразу начинать искать в его "зонах невнимательности и безответственности". Так что, по причине разного опыта в случае, если дать двум экспертам тестирование одного и того же модуля, они найдут разные ошибки. То есть мы снова рискуем пропустить какие-то ошибки в программе.
3. Высокие уровень субъективизма при оценке результатов. Все вышесказанное ведет к тому, что нельзя вполне верить отчету тестировщиков, основанному на результатах исследовательского тестирования. :) Такой отчет значит лишь "Мы выполнили все тесты, которые пришли нам в голову, и нашли вот это. Анализируя то, что мы нашли (или не нашли?), мы полагаем, что билд хороший для текущей стадии разработки". Конечно, это мало отличается от тестирования по тест плану - там тоже результаты основаны на наборе тестов, только этот набор может быть дополнен более опытными сотрудниками, к примеру.

У меня вышло одинаковое количество плюсов и минусов, что означает "хорошая практика, если применять в меру".
Иногда я думаю, что в тестирование можно представить в виде равностороннего треугольника со сторонами 1 - время, 2 - количество найденных ошибок, 3 - достоверность и возможность использования результатов. Если пытаешься сделать одну из сторон короче - неизменно уменьшатся и остальные стороны. Пытаешься сэкономить время - теряешь в количестве найденных ошибок и результатах. Хочешь больше статистики - нужно увеличивать время на тестирование, что (возможно) повысит количество найденных ошибок.
Следуя этой, пока не вполне обдуманной, теории, исследовательское тестирование может занять следующее место в тестировании программы вцелом:

Этим рисунком я все же хочу подчеркнуть, что не все области могут быть протестированы с помощью этого метода и не всегда плюсы будут значить для нас больше,чем минусы.