Тест-дизайн сродни математике: как бы хорошо ни знал теорию, все равно сноровка приходит только путем решения десятков и сотен практических примеров.
Во многом это связано с тем, что теория рассматривает каждый метод тест-дизайна на упрощенной модели. Например, метод классов эквивалентности обычно рассматривается на примерах одного или нескольких изолированных числовых полей ввода. В реальном же ПО все намного сложнее. Простенький диалог для задания настроек чего-либо часто содержит целый ряд параметров, которые не только имеют каждый свой набор классов эквивалентности, но еще и взаимно влияют друг на друга. Теория объясняет в какую сторону думать, но умение превращать свое видение функциональности в набор эффективных тестов можно наработать только опытным путем.
Например, сейчас я тестирую диалог настроек объекта, имеющий двадцать четыре параметра, из которых 11 независимы от других, 7 зависимы от одного из параметров, а сочетания еще двух влияют на соотношение друг с другом четырех оставшихся. И это речь идет только о вводе данных в диалог, а ведь еще нужно протестировать отработку этих настроек системой...
Где ты, Сканави для тестировщиков?
