Существуют всевозможные способы сделать это, начиная от того, что я считаю «формой искусства» (и не обязательно хорошим искусством), и заканчивая математически полученными тестами из формальных спецификаций. В конце концов, ваша команда разработчиков должна определиться с тем, что они могут сделать, основываясь на графике, с которым они работают. При этом возможность тестирования программного обеспечения на соответствие спецификациям - это хорошо.
Только ваша команда может измерить «глубину» ваших тестов, и это, вероятно, будет зависеть от того, насколько хороши ваши спецификации. Если они скажут что-то вроде «пользовательский интерфейс входа должен предоставить кнопку отмены и кнопку входа, и они должны работать», ваши тесты будут довольно общими. Но имейте в виду, что даже очень общие тесты - это хорошо. Тестирование - это хорошо. Слишком многие разработчики плохо относятся к тестированию, но, в конце концов, вы поставляете программное обеспечение, которое должно работать, и для меня это очень много значит.
Эффективность ваших тестов при обнаружении сбоев программы будет зависеть от того, какие детали вы в них заложили. Что особенно приятно в написании тестовых процедур для спецификаций, так это то, что вы можете тестировать каждую сборку с тем же уровнем детализации, что и предыдущая сборка (обычно называемая регрессионным тестом).