Связка тест-планов для комплекса интерфейс-функциональность.

Название темы мне и самому не нравится, но лучше придумать не вышло.

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

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

Уверен, ситуация не нова, и скорее всего, существуют готовые решения, как из неё выйти. Буду благодарен за любые идеи.

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

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

Тут две проблемы:
1. Усложнение процесса написания тест-плана. Если сейчас тест-план для новой серверной фичи пишется на основании одного документа, то в вашем варианте придётся подключать несколько документов для клиентского. Отследить покрытие, особенно клиентских требований, становится сложно. Если для серверных мы имеем поле с номером требования, которое мы покрываем данным тест-кейсов, то для клиентских нет нумерации требования, а только нумерация скринов.
2. Усложнение апдейта тест-планов, что более серьёзно. При апдейте клиентского воркфлоу надо будет отследить все серверные функциональности, использующие это воркфлоу и проапдейтить их все.

Если не получится писать один раз, тогда хотя бы выполняйте тест один раз, и ставьте галочки в два места.

Так как связь между клиентовским и серверным функционалом many-to-many, это может быть проблемно.

Но спасибо за ответ, попробую продумать оба этих варианта детальнее, тем более похоже других не существует :)