Минусы тестирования по плану

Давайте поразмыслим сегодня о минусах тестирования по плану. Под планом в данном случае подразумевается не план тестирования, который составляется в начале проекта и является стратегическим документом, а набор готовых тестов или тест-кейсов (test case) или тестовых сценариев, сгруппированных  и расположенных в определенном порядке. Одни называют такой набор тестовой процедурой, другие - тестовой спецификацией. Суть его от этого не меняется.

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

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

Когда тестировщик работает по плану, это обычно выглядит так:

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

И далее цикл повторяется, пока не иссякнут тесты или нечто неожиданное не прервет процедуру тестирования (например, внезапный скачок напряжения в сети или охранник, звоном ключей тонко намекающий, что пора идти домой)

Из этого видно, что тестирование по плану имеет два больших минуса. А именно:

1. Оно затормаживает - тестировщик движется по колее плана, делая в точности то, что написано, умственно не утруждаясь. Творческие идеи, свободно реявшие на этапе проектирования тестов, сейчас пребывают в связанном состоянии в виде фиксированного тестового набора. Думать вроде как не нужно, ведь к этому моменту мы уже тщательно все продумали.
2. Оно пропускает неожиданные дефекты - зная, что поле редактирования должно принимать числа от 0 до 20, мы сразу вносим в план тесты, проверяющие реакцию поля на ввод данных из допустимых и недопустимых классов эквивалентности. Но разве может прийти в голову запланировать тест, проверяющий перерисовывается ли поле, на котором устанолен фокус, если меняется одна определенная настройка в окне? Мы можем запланировать проверку только тех ситуаций, которые можем спрогнозировать или заподозрить. Однако практика показывает, что огромное количество дефектов встречаются в неожиданных ситуациях и обнаруживаются случайным образом. Тестирование по плану такие дефекты чаще всего пропускает.

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

Разумеется, тестирование по плану нужно и полезно, однако его нужно дополнять тестированием в более свободном режиме. Например, исследовательским  (exploratory testing).