Рабочая форма для HR-заказчика, владельца процесса и исполнителя автоматизации. Помогает проверить маршрутизацию заявок, согласования, уведомления и отчёты на понятных рабочих сценариях. Фиксирует ожидаемый и фактический результат, существенные ошибки и условия запуска. Подходит для приёмки изменений в уже выбранной системе; не заменяет техническое обследование.
Протокол проверки автоматизированного HR-процесса
Процесс и границы изменения: ___
Система, версия настройки, дата проверки: ___
Владелец процесса со стороны заказчика: ___
Исполнитель настройки: ___
Представители пользователей: ___
1. Что принимаем
Рабочая проблема до изменения: ___
Операции, которые выполняет система: ___
Решения, которые остаются за человеком: ___
Что не входит в эту проверку: ___
Основание ожидаемого поведения: согласованное требование ___, пункт ___, версия ___.
Например, автоматическая передача заявки согласующему и одобрение самой заявки — разные действия. В протоколе нужно указать, какое из них проверяется. Отсутствие сообщения об ошибке ещё не подтверждает правильность маршрута.
2. Условия проверки
Используем учебные или обезличенные данные: ___
Учётные записи и роли участников проверки: ___
Исходное состояние заявки: ___
Связанные справочники и правила: ___
Кто подготовил данные и проверил исходное состояние: ___
Какие внешние сервисы участвуют: ___
Какие операции проверяем в отдельной тестовой среде: ___
Не создавайте настоящие кадровые события ради проверки. Если проверка возможна только в рабочей системе, заранее согласуйте её с владельцем: какие данные допустимы, кто увидит уведомления и как будут устранены тестовые записи.
3. Карточка одного сценария — копировать для каждой проверки
Номер и название: ___
Какой риск проверяем: ___
Роль пользователя: ___
Начальные данные и состояние: ___
Действие пользователя: ___
Ожидаемый результат: ___
Где проверяем результат: ___
Фактический результат: ___
Подтверждение: номер тестовой записи или снимок без лишних персональных сведений ___.
Статус: пройден / ошибка / не проверен / неприменим.
Причина статуса: ___
Ожидаемый результат заполняют до выполнения. «Работает правильно» заменяют наблюдаемым условием: кому поступила задача, какое значение сохранилось, кто получил уведомление и что отразилось в отчёте.
4. Набор сценариев для отбора
Обычный маршрут: заявка проходит согласованные этапы; итог виден нужному получателю. Наш сценарий: ___.
Неполные данные: пользователь видит, чего не хватает; система не сообщает об успешной передаче незавершённой заявки. Наш сценарий: ___.
Повторное действие: повторное нажатие или отправка не создаёт незаметный дубль либо дубль обрабатывается по согласованному правилу. Наш сценарий: ___.
Возврат на исправление: понятно, кто дорабатывает заявку и какая версия затем согласуется. Наш сценарий: ___.
Изменение после согласования: проверено, какие поля можно менять и когда требуется новое решение. Наш сценарий: ___.
Отсутствие согласующего: задача не остаётся без владельца; предусмотренный заместитель получает её по согласованному правилу. Наш сценарий: ___.
Разграничение доступа: каждая роль видит только согласованные данные и действия. Наш сценарий: ___.
Сбой передачи: участник понимает, завершилась ли операция, кому сообщить об ошибке и безопасно ли повторять действие. Наш сценарий: ___.
Сверка отчёта: итоговые значения совпадают с выбранными тестовыми записями, а отменённые и возвращённые заявки учтены по правилам. Наш сценарий: ___.
Неприменимые сценарии отмечайте с причиной. Добавляйте особенности своего процесса: календарь, разные подразделения, несколько согласующих, изменение руководителя.
5. Реестр ошибок
Номер ошибки: ___
Связанный сценарий: ___
Что произошло и при каких условиях: ___
Последствие для работы или данных: ___
Мешает ли запуску и почему: ___
Есть ли согласованный временный порядок: ___
Ответственный за исправление, срок: ___
Версия исправления: ___
Результат повторной проверки: ___
Закрывать ошибку следует после проверки исправленного сценария. Сообщение исполнителя «исправлено» фиксирует выполненное действие, но не результат приёмки.
6. Решение о запуске
Проверено сценариев: ___ из ___; неприменимо: ___; не проверено: ___.
Открытые ошибки и влияние на запуск: ___
Решение: запуск / ограниченный запуск / доработка.
Границы ограниченного запуска, если выбран: ___
Кто принимает решение: ___
Кто принимает обращения пользователей после запуска: ___
При каком событии работу приостанавливают: ___
Согласованный временный способ выполнения процесса: ___
Дата проверки первых рабочих результатов: ___
Этот протокол подтверждает результат в перечисленных сценариях и условиях. Непроверенные случаи остаются явно отмеченными; их нельзя считать успешно пройденными только потому, что основной маршрут работает.
Отправляя данные вы подтверждаете пользовательское соглашение