Тест-дизайн - это удаление тестов

Задача тест-дизайнера - уменьшить множество возможных тестов до их приемлемого количества.

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

"Серебряная пуля" тест-дизайнера

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

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

Некий совершенный метод, позволяющий проектировать самые эффективные тесты, находящие наибольшее количество дефектов с наименьшими усилиями. Наилучшую форму описания и оформления этих тестов, чтобы ими было удобно пользоваться, управлять и составлять отчеты. Ну и так далее.

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

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

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

Доводить действие функции до логического конца

В общем случае проектируя тест, следует не останавливать его шаги на действиях в диалоговом окне, а проследить выполнение функции до её логического конца.
 

Ошибку не доведения действия функции до конца часто совершают начинающие, и я сама не раз на этом попадалась. Тестировщик в первую очередь сосредоточенно тестирует поля ввода в диалоговом окне, например, сохраняются ли галочки на правах у данной группы пользователей. Однако это второстепенно. А первостепенно - отработка этих настроек системой. Действительно ли пользователю доступна запись, если в его настройках прав установлен флаг "Запись"?
Вывод: целесообразно сначала тестировать логику, потом - детали ее реализации в GUI.