Более 20 лет назад, в 1990 году, Борис Бейзер в свое книге «Software Testing Techniques» ввел понятие, известное как «парадокс пестицида» (pesticide paradox), которое формулируется следующим образом:
Каждый метод, который вы используете, чтобы предотвратить или найти ошибки, оставляет часть ошибок, против которых эти методы уже неэффективны.
На простом языке это означает, что если вы будете часто запускать одни и те же тесты, то со временем они перестанут находить ошибки. В своей книге Бейзер привел следующую аналогию между повторным выполнением тестов и обработкой сельскохозяйственных полей химикатом (в частности, пестицидом), который уже был применен ранее. После первой обработки химикатом большая часть вредителей погибает, однако все же некоторая часть из них выживает, потому что их организм оказался устойчив к яду. Те, кто выжил, с большой вероятностью переживут и последующие обработки пестицидом.
По этой причине тестовые наборы всегда требуют своего обновления, независимо от того, запускаются ли они в автоматическом или ручном режиме.
Существует ряд обстоятельств, по которым хороший тестовый набор со временем утрачивает свою эффективность:
1. Невозможно проверить все возможные сценарии
Даже простые приложения требуют большого количества тестов для проверки всех возможных сценариев и комбинаций данных. Вот почему мы прибегаем к помощи различных принципов, таких как классы эквивалентности или тестирование на основе модели, но все же и этого не достаточно. Большинство команд используют тестирование на основе рисков, создавая подмножество сценариев и наборов данных, а затем используют выявленные ошибки, найденные уже после первого релиза, для улучшения (изменения) своих тестовых сценариев. Это означает, что мы тестируем не все.
2. Функциональность приложения изменяется с течением времени
Каждый раз, когда в продукт вносятся изменения, тестовые сценарии также должны обновляться в соответствии с этими изменениями. Нужно всегда помнить, что любое, даже незначительное изменение, может повлиять на работоспособность всей системы, поэтому важно изменять тесты каждый раз, когда такие изменения происходят.
3. Люди осторожничают только там, где чувствуют непосредственную опасность
Это означает, что разработчики всегда будут проявлять гиперосторожность лишь в тех местах, где ранее тестировщики обнаружили проблемы. Однако там, где раньше было «все ОК», их внимательность снижается на порядок. Т.е. другими словами, разработчики учатся избегать ошибок, которые находятся тестами.
Для того, чтобы преодолеть парадокс пестицида, тестировщики должны постоянно писать новые и различные тесты для покрытия разных частей программы для нахождения как можно большего количества ошибок.
Вот несколько рекомендаций на этот счет:
1. Следите за изменениями в продукте и предугадывайте их возможные последствия
Необходимо приложить определенные усилия для того, чтобы понять, какие места в программе могло затронуть даже совсем небольшое изменение. После этого можно приступить к написанию дополнительных тестов, покрывающих эти изменения.
2. Откажитесь от неэффективных тестов
Бесполезно держать большое количество тестов, которые в итоге не помогают вам. К примеру, если у вас есть 10 тестов, которые покрывают одну и ту же область, и ни один из них за все время так и не нашел ошибок, то вполне целесообразно сократить число таких тестов.
3. Постоянно меняйте тестовые данные
Хоть это и кажется очевидным, но мы порой склонны забывать об этом. Многие ошибки в наших продуктах имеют специфический характер (особенно в автотестах), поэтому мы должны постоянно увеличивать / изменять тестовые данные (к примеру, использовать как можно больше тестовых БД).
4. Используйте неформальные средства тестирования
Используйте по крайней мере один вид неформального тестирования за цикл (или за релиз). Допустим, вы можете прибегнуть к исследовательскому виду тестирования.