Руководство по исследовательскому тестированию.

Два простых шага для исследовательского тестирования:

1. Используйте свое лучшее суждение.

2. Если вы не знаете, что делать, см. пункт 1.

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

Как можно провести исследовательское тестирование? Это будет зависеть от конкретной тестируемой системы, но все-таки можно наметить некоторые общие руководящие принципы. Первый из них заключается в проверке того, что часто используется, и тех важных задач, которые должны быть выполнены и работать правильно. Не важно, как система обрабатывает странные угловые случаи, если не работает ни один из простых базовых случаев! Проверьте счастливые пути и убедитесь, что они работают правильно, прежде чем сойти с них в заросли сорняков.

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

Посмотрите, что произойдет, когда пересекутся области действия различных функционалов. Если тестируемая система способна прочитать файл, выполните с ним некие действия, запишите результат на диск — и что произойдет, если вы этим файлом перезапишите исходный файл? Что произойдет, если одна часть системы сортирует по возрастанию, а другая по убыванию, — не возникнет ли где-то конфликт сортировок? Если система выполняет сложный рендеринг и одновременно пытается скачать данные из сети, может ли возникнуть "состояние гонки"? Ошибка проектирования многопоточной системы или приложения, при которой работа системы или приложения зависит от того, в каком порядке выполняются части кода.

Попробуйте почувствовать себя разработчиком. Даже если вы не программист, можете представить сценарии, о которых не думал тот, кто концентрировался на какой-то конкретной функции программы или пытался заставить правильно работать какой-то метод, в то время как менеджер проекта постоянно запрашивал у него отчеты о состоянии дел. В такой ситуации несложно что-то упустить из виду. Разработчик мог не проверить все нулевые указатели, целочисленные переполнения или не проконтролировать, что произойдет, если запущенные потоки никогда не закончатся. Используя эти знания, вы можете попытаться воспроизвести такие ситуации с точки зрения пользователя путем ввода пустых строк, чрезвычайно огромных чисел, превышающих максимально возможное в 32-битном диапазоне, или чтения огромных массивов информации из базы данных.

Не бойтесь следовать своей интуиции. Если вы заметили что-то, что кажется странным, забавным или неожиданным, попробуйте добиться этого другими способами и посмотрите, есть ли что-то, что эти способы связывает. Также у вас могут появиться идеи, которые не пришли бы вам в голову, если бы вы занимались только разработкой тест-плана. Теперь самое время попробовать.

В итоге, хотя исследовательское тестирование является гораздо менее формализованным процессом, чем создание и выполнение тест-планов, вам понадобится описать обнаруженные дефекты как можно быстрее и как можно более подробно. Чем дольше вы ждете, тем больше забудете. Более того, чем дольше вы используете систему, тем вероятнее, что окажетесь в ситуации, что не сможете воспроизвести ошибку. Определение вызвавших дефект шагов и их запись должны превалировать над поиском других дефектов. В конце концов, если вы не отметите дефекты и не предоставите разработчику достаточно информации для их исправления, то нет никакого смысла заниматься тестированием. Вы также можете позже использовать шаги воспроизведения, которые вы нашли, для создания более формализованного теста.