Тест-дизайн. Часть 1

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

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

Первое что пришло мне в голову на поставленный вопрос – это то что тест-дизайн позволяет нам создавать тесты. Логично. Но вот что изменится, если мы его не будем применять? Тут у меня в голове сразу возникла картинка одного из последних спринтов, когда мне необходимо было проверить только что разработанный функционал. По грубым подсчетам мне необходимо было провести что-то около 190 тестов по одному сценарию, т.е. надо 190 раз проделать одно и то же меняя только данные. В среднем на один тест я тратил 4 минуты. У некоторых возникнет вопрос или точнее идея, а почему не использовать методы автоматизации для решения поставленного вопроса? Но не было такой возможности, т.е. автоматизация усложнила бы еще сильнее сам процесс. Надо было сдаваться в релиз и на разработку авто-тестов просто не было времени. Именно в этом спринте я впервые пожалел, что не владею техниками тест-дизайна. В итоге, конечно, я нашел, как сократить 190 тестов до 10 и справиться с тестирование за 40 минут. Но это уже было после того когда на первом прогоне было выполнено 100 тестов и я левой рукой не глядя на клавиатуре умел набирать чужую фамилию. Так вот тест-дизайн позволяет создавать не просто тесты, а рациональные тесты и исключать варианты повторения.
Второй вопрос из выше поднятых – это для чего нужен тест-дизайн? Казалось, я уже ответил на этот вопрос, но нет. Ранее мое мнение на этот вопрос звучало как-то так: «Тест-дизайн позволяет придумать больше тестов, которые помогут нам проверить более детально ПО.» Это было мое заблуждение. Тренер наглядно показал, что это не так и нам не нужно придумывать больше тестов. Нам надо достичь состояния понимания того что мы все протестировали. Некоторые как раз путают наличие большего количества тестов с состоянием максимально протестированного продукта. По факту при тестирование нам необходимо быть уверенным в том, что мы проверили выпускаемый продукт максимально полно. Но все знают, что проверить на все 100% не возможно практически ни один из современных программных продуктов. Тест-дизайн позволяет нам построить как раз такие тесты, которые позволяют нам с достаточной степенью уверенности говорит о том, что мы завершили тестирование.
Логично задаться вопросом, что же нам позволяет так сократить свою работу и увеличить свою уверенность? Ответом на этот вопрос служит термин «Методы тест-дизайна» или  его синоним «Техники тест-дизайна».
Все существующие методики тест-дизайна построены на основе моделей, т.е. при тестирование тестировщик предполагает, что программисты , которые писали программу  достаточно разумные люди и живут они в реальном мире. И как следствие из данного допущения вытекает ряд логичных ограничений.
О существующих моделях и их ограничениях, а так же методов их применения я предлагаю рассказать вам в следующих статьях.