Самое важное делаем в первую очередь

 В тестировании, как и везде, самое важное надо делать в первую очередь. Сначала важные фичи, потом все остальные. Сначала важные тесты, потом остальные.


Во front-office проектах времени на итерацию иногда бывает очень мало, либо оно внезапно (смена приоритетов, неожиданные другие задачи, проблемы с окружением и пр.) сокращается.

Поэтому целесообразно обращать внимание не только на содержание тестов, но и на порядок их написания. А после написания - на порядок их выполнения.

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

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

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

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

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

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

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

Тест-дизайн: теория vs практика

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

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

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

Где ты, Сканави для тестировщиков?