На исследовательское тестирование часто ссылаются как на тестирование ad hoc (свободное или интуитивное тестирование), но этот термин может означать неаккуратность и небрежную работу. Однако исследовательское тестирование не является небрежным, оно просто менее жесткое. Очень часто много внимания уделяется тому, является ли исследовательское тестирование подходящим, и еще больше внимания на определение того, что необходимо тестировать в дальнейшем.
Исследовательское тестирование зачастую становится первым опытом тестировщика при знакомстве с системой или ее новой функцией. Пошаговые инструкции — добавляемые как шаги выполнения в тест-план — могут быть не определены путем простого чтения проектной документации. Часто проводится некоторое предварительное тестирование для понимания того, как все реализовано. По мере того как тестировщик получает опыт по работе с системой, может потребоваться дополнительное исследовательское тестирование, т. к. теперь тестировщик лучше понимает те закоулки системы, которые не были покрыты предварительным тестпланом. А иногда тестировщику просто нечем заняться, и он начинает охоту на те дефекты, которые остались незамеченными после прохождения тестов, созданных исключительно на основе тест-планов.
Потратив некоторое время на блуждание в сорняках — где еще не побывали косилки тест-планов, — тестировщик может найти странности системы, которые, возможно, никогда не будут обнаружены более формализованным тестированием. Кроме того, исследовательское тестирование часто обнаруживает больше дефектов, и при этом гораздо быстрее. Большее время, потраченное на тестирование, как противоположность мелким заботам, связанным с изучением тест-планов, записью статусов тестов и т. п., означает больше времени, потраченного на поиски дефектов и меньше времени на разработку связанной с этими дефектами документации.
У исследовательского тестирования есть побочное преимущество, заключающееся в том, что тестировщик узнает о системе быстрее, чем при формальном тестировании. Бездумное следование тест-плану тестирования не допускает того обучения, которое характерно для людей. И если вам кажется сложным обучение игре на пианино при помощи чтения книги, то понимание тестируемой системы при помощи чтения и выполнения тест-планов покажется еще более сложным.
Требуется совсем немного усилий для установки ПО или доступа к системе и последующих поисков дефектов, в отличие от шагов, связанных с разработкой и написанием тест-плана и его выполнением. Если у вас есть полчаса на поиск всевозможных дефектов в программе, вам не захочется тратить первые 25 минут на написание предусловий, постусловий, шагов выполнения — и все ради того, чтобы в итоге запустить несколько тестов. Это также означает, что очень легко выполнить обновленный тест, даже если программа существенно изменилась; просто займитесь еще исследовательским тестированием! Не нужно обновлять никакие тестпланы, за исключением тех, что в голове у тестировщика, в то время как для тестплана (или еще хуже, для автоматизированного теста) может потребоваться внесение достаточно серьезных правок в случае изменения исходной программы.
Но у исследовательского тестирования имеются недостатки. В конце концов, существует причина, по которой тест-планы создаются в первую очередь. Первым недостатком является то, что оно нерегулируемое, а это означает отсутствие заранее подготовленного реального плана, определяющего, что именно следует тестировать. Попытки объяснить не тестировщикам, что именно нужно тестировать и почему это может быть сложно, и даже попытки объяснять задним числом могут оказаться непростыми. При погружении в тестирование некой программы у вас может быть прекрасная воображаемая модель того, что вы делаете и по каким причинам, но зачастую это все теряется после завершения работы.
Большая часть ответственности по принятию решения о том, что именно нужно тестировать, лежит на тестировщике во время исследовательского тестирования. Добросовестный и хорошо понимающий систему тестировщик выполнит работу по обнаружению дефектов гораздо лучше, чем не понимающий систему или ленивый тестировщик. Если оба этих тестировщика будут следовать одному тест-плану, тогда при условии того, что второй из них достаточно добросовестный для выполнения тестов и записи правильных результатов, объем покрытия будет известным и примерно одинаковым для них двоих. Таким образом, формализованный тест-план часто мешает опытным тестировщикам, но помогает неопытным, которым нужна помощь в понимании того, что нужно тестировать.
Другой проблемой, которая может возникнуть во время исследовательского тестирования, является возможная невоспроизводимость обнаруженных во время его проведения дефектов. Может оказаться, что причина падения чего-либо через 10 минут после начала исследовательского теста в том, что тестировщик сделал что-то, немного отличающееся от предыдущего раза в первую минуту тестирования. Попытка повторить все шаги без знания этого отличия может привести к полному разочарованию и, скорее всего, окажется невозможной. С формализованным тестированием, при условии, что тестировщик выполнил все шаги, это перестает быть такой проблемой.
Сложно оценить, какое покрытие получила тестируемая система при помощи исследовательского тестирования. Если тестировщик не записывает в точности, что он делает, либо его действия не фиксируются специальными программами по логированию действий или захвату изображения на экране, могут оставаться такие части системы, в качестве тестирования которых вы не можете быть уверены. Сложно что-то анализировать, когда в наличии так мало тестовых артефактов. Если вы работаете в связанной с безопасностью области или в такой, где важно документировать все, что было протестировано, полагаться исключительно на исследовательское тестирование окажется не лучшей идеей.
Тестирование с течением времени все больше и больше полагается на автоматизацию, и нет признаков, что этот процесс замедлится. Однако поскольку исследовательское тестирование во многом базируется на знаниях тестировщика и его знакомстве с тестируемой системой, на данный момент практически невозможно автоматизировать этот вид тестирования. Если не брать в расчет непредвиденные достижения в области искусственного интеллекта, вам всегда будет нужен человек для выполнения исследовательского тестирования.
