Тест-драйв: типовые маршруты

«Посмотрите, вот он без страховки идет.

Чуть правее наклон – упадет, пропадет!

Чуть левее наклон – все равно не спасти!

Но, должно быть, ему очень нужно пройти…»

(фрагмент демонстрации разработанного функционала Заказчику)

Всем привет.

Наш тест-драйв близится к завершению. Мы получили «дорожную карту» тестировщика, узнали всё, или почти всё, о форме и содержании карточек системы DIRECTUM – пора выстраивать маршрут и отправляться в путь!

Немного теории

Объектами тестирования в типовом маршруте могут выступать:

Теперь всё то же самое, но компактной картинкой:

Кратко пробежимся по свойствам тестируемых объектов:

Группа маршрута служит для отображения иерархии «По группам» в справочнике Типовые маршруты, либо группировки записей списка, упрощая поиск нужного типового маршрута в справочнике. Так же может использоваться в качестве критерия для фильтратора.

Признак Показывать пользователям может принимать значения «Да» или «Нет». В случае если запуск типового маршрута осуществляется без участия пользователя, в автоматическом режиме, признак должен быть установлен в «Нет».

Тема, текст и инструкция ЗЗУ формируются либо на основе постоянных наборов символов, указанных явно при настройке ТМа, либо по правилам, заданным ISBL-кодом.

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

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

Запрашиваемые параметры могут обладать следующими свойствами:

• заголовок;
• тип;
• значение;
• значение по умолчанию;
• обязательность заполнения;
• подсказка.

При этом для запрашиваемых параметров типа Справочник в списке значений должны отсутствовать, либо обрабатываться без появления ошибок закрытые и неутверждённые записи.

Тип прав на задачу может принимать значения «Всем участникам» или «Всем». Если тип прав не оговорен, по умолчанию присваивается значение «Всем».

Вложениями в ЗЗУ могут выступать один или несколько любых объектов системы (документ, папка, запись справочника и т.д.), а также объекты сторонних систем. Количество отображаемых вложений регулируется выдачей прав доступа на объект.

В рамках одного блока типового маршрута может формироваться одно или несколько заданий. Рассылка нескольких заданий, формируемых в рамках одного блока, может происходить последовательно или параллельно.

Исполнитель задания может быть задан различными способами – прямым указанием, статической, вычисляемой или специальной ролью, параметром маршрута, прикладным кодом, и т.д.

Срок задания может быть указан в формате «дата» или «дата/время».

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

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

Отработка условия не сопровождается выдачей пользовательских окон или сообщений. Условие определяет логику прохождения типового маршрута иможет быть задано сравнением двух однотипных данных или прикладным вычислением:

• Сравнение – тип условия, при котором сравниваются два операнда через заданную операцию сравнения;
• Вычисление – тип условия, при котором задается ISBL-вычисление для получения результатов условия. Возможный результат вычислений: True / False. Если True, то маршрут выполняется по ветке Да, иначе по ветке Нет.

Отработка логических объединений не сопровождается выдачей пользовательских окон или сообщений. Объединения определяют логику прохождения типового маршрута при наличии условий И/ИЛИ:

• при объединении И типовой маршрут продолжается, если выполнены все предшествующие блоки.
• при объединении ИЛИ типовой маршрут продолжается, если выполнен хотя бы один предшествующий блок.

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

Отработка мониторинга не сопровождается выдачей пользовательских окон или сообщений. Блок предназначен для мониторинга системы в течение некоторого времени с целью контроля наступления определенного события. Мониторинг задается программно. Выполнение осуществляется с некоторым интервалом в течение определенного промежутка времени. Факт наступления или не наступления события влияет на порядок выполнения маршрута: исходящие из блока соединения могут соответствовать факту наступления события или окончанию срока мониторинга.

Отработка сценария не сопровождается выдачей пользовательских окон или сообщений. Сценарий предназначен для выполнения в ходе типового маршрута произвольных действий, задаваемых прикладным кодом. Например, создание записи в справочнике, создание объекта в сторонней системе, и т.д.

Запуск типового маршрута может осуществляться в скрытом для пользователя режиме, без показа карточки задачи.

Входные данные и правила тестирования

В качестве входных данных для тестирования будем рассматривать:

• систему DIRECTUM с доступом к тестируемому типовому маршруту;
• проектную документацию, содержащую описание маршрута;
• достаточное количество тестовых данных, таких как:
  • пользователи;
  • работники;
  • документы;
  • записи справочников;
  • и т.д.
• максимально приближенные к реальному использованию настройки системы, такие как:
  • группы пользователей;
  • права и привилегии пользователей и групп пользователей;
  • перечень и состав наших организаций (орг. структура);
  • состав работников подразделений;
  • и т.д.

В ходе тестирования следует придерживаться следующих правил:

• тестирование типовых маршрутов следует осуществлять исключительно имитацией работы пользователей, посредством подключения к базе под учётными записями участников маршрута. Тестирование с привилегиями администратора, либо в режиме отладки, либо посредством выполнения заданий инициатором за исполнителей категорически не рекомендуется и может быть использовано исключительно на этапе разработки и настройки маршрута;
• в ходе тестирования должна быть пройдена каждая ветка типового маршрута;
• с целью сокращения времени тестирования должны быть указаны минимальные значения для свойств / реквизитов / параметров объектов, работа которых предполагает ожидание наступления того или иного события. Например:
  • для свойства задания «Крайний срок» указать текущую дату и время, с запасом, достаточным для прохождения маршрута до задания;
  • для блока «Ожидание» указание относительного срока в несколько секунд.

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

Этапы проверки типового маршрута

Для тестирования типового маршрута выделим следующие этапы проверки:

• выбор типового маршрута;
• инициализация типового маршрута;
• старт типового маршрута;
• формирование задания / уведомления;
• прохождение типового маршрута.

Рассмотрим проверки для каждого этапа работы с типовым маршрутом.

Этап проверки «Выбор типового маршрута»

1. Проверяем отнесение типового маршрута к определенной группе типовых маршрутов.
2. Проверяем отображение или скрытие типового маршрута при выборе в списке маршрутов, если ТМ предназначен для запуска задачи / подзадачи системой (в рамках другого ТМ, по кнопке из карточки документа / записи справочника и т.д.)
3. Проверяем повторную отправку одного и того же вложения по одному и тому же типовому маршруту: количество отправок может быть не ограничено, либо повторная отправка объекта не допускается и сопровождается выводом предупреждения.
4. Проверяем создание задачи после выбора типового маршрута без запрашиваемых параметров.
5. Проверяем создание задачи после выбора типового маршрута с заполнением запрашиваемых параметров. Для параметров дополнительно проверяем:

• количество запрашиваемых параметров;
• заголовки запрашиваемых параметров;
• значения параметров, установленные по умолчанию;
• типы параметров;
• возможные значения параметров и форматы отображения;
• обязательность заполнения параметров;
• подсказки для запрашиваемых параметров.

Этап проверки «Инициализация типового маршрута»

1. Проверяем заполнение темы задачи.
2. Проверяем заполнение текста задачи.
3. Проверяем заполнение инструкции задачи.
4. Проверяем заполнение инициатора задачи.
5. Проверяем указание важности задачи.
6. Проверяем тип прав, установленный для задачи.
7. Проверяем состав вложений, требуемых при старте задачи.
8. Проверяем прикладную бизнес-логику, требуемую при старте задачи.

Этап проверки «Старт типового маршрута»

1. Проверяем изменения текста задачи, внесённые инициатором до старта: после старта задачи изменения могут быть сохранены и добавлены к изначально установленному тексту, либо затёрты.
2. Проверяем изменения состава вложений, внесённые инициатором до старта: изменение состава вложений может не влиять на возможность старта задачи, либо ограничивать эту возможность и сопровождаться выводом предупреждения.
3. Проверяем повторную отправку одного и того же вложения по одному и тому же типовому маршруту: количество отправок может быть не ограничено, либо повторная отправка объекта не допускается и сопровождается выводом предупреждения. Да, вам не показалось, вы уже видели эту проверку, но на этапе выбора и на этапе старта – это две разные проверки.

Этап проверки «Формирование задания / уведомления»

1. Проверяем порядок рассылки заданий нескольким исполнителям в рамках одного блока: последовательно или параллельно.
2. Проверяем заполнение темы задания / уведомления.
3. Проверяем заполнение текста задания / уведомления.
4. Проверяем заполнение инструкции задания / уведомления.
5. Проверяем расчёт срока задания.
6. Проверяем исполнителя задания / уведомления: не только корректность его определения, но и то, что в случае отсутствия исполнителя блока маршрут не зависает и не падает с ошибкой.
7. Проверяем выдачу прав на вложения в задание / уведомление.
8. Проверяем прочую прикладную бизнес-логику.

Этап проверки «Прохождение типового маршрута»

1. Проверяем корректность работы маршрута после рестарта, для чего проходим его почти до конца и рестартуем: каждая ветка повторно отрабатывает до конца, не закольцовывается, не падает, не зависает, нужные параметры очищены, и т.д.
2. Для каждого задания проверяем количество и наименования доступных результатов выполнения.
3. Проверяем выполнение задания с результатом, предполагающим переход к требуемому пункту описания.
4. Проверяем выполнение задания с результатом, предполагающим запрос параметров. Для запрашиваемых параметров выполняются проверки, описанные выше.
5. Проверяем выполнение задания с результатом, предполагающим прерывание выполнения блока.
6. Проверяем выполнение задания с результатом, предполагающим запрос вложения.
7. Проверяем выполнение задания с результатом, предполагающим подписание вложенного документа.
8. Проверяем выполнение задания с результатом, предполагающим заполнение текста задания.
9. Проверяем возможность выполнения нескольких заданий в рамках одного блока с разными результатами.
10. Проверяем изменения текста задания, внесённые исполнителем до выполнения задания: после выполнения задания изменения могут быть сохранены и добавлены к изначально установленному тексту, либо затёрты.
11. Проверяем обработку крайнего срока задания.
12. Проверяем обработку заблокированных вложений: выполнение задания до освобождения объекта не должно приводить к неконтролируемым зависаниям или падениям маршрута, требуемая логика обработки объекта выполняется сразу после его освобождения.
13. Проверяем автоматический запуск задач / подзадач по другим типовым маршрутам после выполнения задания основного типового маршрута. При этом основной типовой маршрут может завершаться, ожидать выполнение запущенных задач / подзадач, обрабатывать их результаты и т.д.
14. Проверяем корректность работы типового маршрута при повторной отправке на доработку: при отработке двух и более кругов любой ветки маршрута должны корректно вычисляться исполнители, отсутствовать дубли, выполняться все блоки и т.д.
15. Проверяем изменения статусов объектов в зависимости от прохождения маршрута: могут изменяться реквизиты справочников, этапы жизненного цикла документов.
16. Проверяем корректную работу маршрута с вычислениями, использующими заведомо отсутствующую информацию: например во вложениях может содержаться карточка справочника, значения реквизитов которой используются в дальнейшем при вычислениях. Если эти реквизиты очищены, маршрут должен корректно обрабатывать отсутствие требуемых данных.
17. Проверяем прочую прикладную бизнес-логику, предполагающую выполнение задания с определённым результатом.
18. Проверяем условные ветвления, предполагающие переход к требуемому пункту описания.
19. Проверяем логические объединения, предполагающие выполнение требуемых пунктов описания.
20. Проверяем отсрочку выполнения блока, следующего за блоком «Ожидание».
21. Проверяем переход к требуемому блоку при наступлении событий, установленных для мониторинга.
22. Проверяем выполнение произвольных действий, заданных вычислениями в сценариях.

Надеюсь вышеперечисленные проверки помогут вашим маршрутам всегда доходить до цели.