Таблицы решений и переходы состояний

Когда один список не показывает пропуск

Отдельные проверки «автор», «editor», «пустой title» не гарантируют, что сочетания условий обработаны верно. Для публикации в QA-CORE-1 важны принадлежность команде, роль или авторство, текущее состояние и содержимое title. Таблица решений связывает комбинации этих условий с действием. Сначала зафиксируйте область: вошедший участник той же команды и объект существует. Затем рассмотрите оставшиеся условия. Для другой команды нужен отдельный отказ; не прячьте его в строке про обычного пользователя.

Внутри области признак «автор или editor» можно объединить логическим ИЛИ, если не теряется цель проверки обеих ветвей. Для первого исполнения возьмите по примеру автора user и чужого editor. Одной строки с Анной недостаточно, чтобы подтвердить ветвь editor. «Неважно» в ячейке разрешено, когда результат действительно одинаков при всех значениях этого условия, а не когда мы забыли его выяснить.

Модель состояния показывает последовательность

Модель здесь мала: после создания задача draft, успешная публикация переводит её в published. Обратного действия в контракте нет. Повторная публикация отклоняется и сохраняет published. Тест перехода включает подготовку конкретного исходного состояния, событие, ожидаемое новое состояние и проверку отсутствия лишних изменений. Если выполнить публикацию уже опубликованной задачи без указания исходного состояния, коллега не сможет повторить ваш пример.

Покрытие всех двух состояний не равно покрытию переходов. Достаточно прочитать draft и published, чтобы посетить оба состояния, но не проверить ни публикацию, ни повторный отказ. Явно перечислите переходы в выбранной модели: draft→published допустим при условиях, published→published по повторной команде запрещён. Другие отказные переходы из draft различаются причинами: нет права либо заголовок состоит из пробелов. Их тоже нужно связать с таблицей решений.

Право действия не выводится из соседнего права

Вера editor может опубликовать чужой draft по Q5, но не прочитать его содержимое по Q4. Это сознательно необычное учебное правило. Не заменяйте его привычной логикой продукта, где editor видит всё. Матрица «кто читает» и матрица «кто публикует» отвечают на разные вопросы. Такая раздельная модель хорошо находит ошибки, когда разработка использует один общий флаг canAccess для всех операций.

После успеха проверьте идентичность объекта и точное сохранение title. После отказа сверяйте исходное состояние, а при доступном контроле хранилища — отсутствие созданной копии. Сам факт чтения прежнего ID не исключает лишнюю запись под новым ID. В реальной системе эту проверку может выполнять разрешённый API списка или контролируемый снимок данных; не используйте чужие данные без полномочий. Здесь мы проектируем наблюдения, а не обещаем доступ к базе.

Публикация внутри north