Практические вопросы

Добрый день, коллеги!

У меня есть следующие практические вопросы:
В системе есть 20 статусов документа. (Статусы документа: "утвержден", "одобрен", "на рассмотрении" и тд).
Так же в системе есть 15 ролей ("Администратор", "кассир", "консультант" и тд).
1) Из статуса в статус система может переходить по определенным правилам. Например из статуса "одобрен" в "утвержден" или "отклонен" или и тд.
2) Каждая роль может переводить документа в статусы по определенным правилам. ("Администратор" из любого статуса в любой, "консультант" из статуса "получил" в "Возвращено в отдел продаж" или "передано на согласование"и тд.


Вопросы в следующем -
Следует ли тестировать ограничения по отдельности? Сначало пункт 1, а когда введут "роли", то в купе с пунктом 2?
Или это трата времени и сил и тестировать надо сразу 2 ограничения?

протестировать "в купе" обязательно нужно, но если в данный момент пункт 2 есчё не сделан, то конечно смысл тестировать пункт 1 есть, и в этой логике может быть много багов. Смысла сидеть и ждать пока допишут второй пункт - точно нет! Такое часто бывает, что какая-то функциональность уже написана, а какая-то есчё нет, и когда её допишут - неизвестно.

Добрый день, коллеги!

У меня есть следующие практические вопросы:
В системе есть 20 статусов документа. (Статусы документа: "утвержден", "одобрен", "на рассмотрении" и тд).
Так же в системе есть 15 ролей ("Администратор", "кассир", "консультант" и тд).
1) Из статуса в статус система может переходить по определенным правилам. Например из статуса "одобрен" в "утвержден" или "отклонен" или и тд.
2) Каждая роль может переводить документа в статусы по определенным правилам. ("Администратор" из любого статуса в любой, "консультант" из статуса "получил" в "Возвращено в отдел продаж" или "передано на согласование"и тд.


Вопросы в следующем -
Следует ли тестировать ограничения по отдельности? Сначало пункт 1, а когда введут "роли", то в купе с пунктом 2?
Или это трата времени и сил и тестировать надо сразу 2 ограничения?

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

гыыы.
во-первых вопрос поставлен некорректно.

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


Что касается моих вопросов, то спасибо Вам за разъяснения.

Добрый день, коллеги!

У меня есть следующие практические вопросы:
В системе есть 20 статусов документа. (Статусы документа: "утвержден", "одобрен", "на рассмотрении" и тд).
Так же в системе есть 15 ролей ("Администратор", "кассир", "консультант" и тд).
1) Из статуса в статус система может переходить по определенным правилам. Например из статуса "одобрен" в "утвержден" или "отклонен" или и тд.
2) Каждая роль может переводить документа в статусы по определенным правилам. ("Администратор" из любого статуса в любой, "консультант" из статуса "получил" в "Возвращено в отдел продаж" или "передано на согласование"и тд.


Вопросы в следующем -
Следует ли тестировать ограничения по отдельности? Сначало пункт 1, а когда введут "роли", то в купе с пунктом 2?
Или это трата времени и сил и тестировать надо сразу 2 ограничения?

Добрый день.
Нормально вопрос поставлен - понятно, что у вас есть на данный момент и где сомнения.
Ответ таков:
Да следует, т.к. это две разные функции вашего продукта.
1) Обычно называют жизненым циклом чего-либо (документ, в вашем случае). Иначе - это State машина. Некий объект имеет набор состояний, переход из одного в другое подчиняется определенным правилам. Это вам и надо проверить. Заметьте - никаких пользовательских ролей для этого не надо - они могут быть могут вообще отсутствовать, стэйт машина должна работать независимо от них.
2) Второе обычно называют разграничением полномочий. И тут надо проверять, что персона у которой есть некая определенная роль может сделать только то, что предполагается допустимым для этой роли. Причем, скорее всего у вас в системе роли будут контролировать не только процесс изменения статуса документа, но еще и другие аспекты работы программы. Например Администратор может добавлять\убирать пользователей, менять им роли. "Кассир" может генерить отчеты, которые не может генерить "консультант" итд.

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