Набор из 60 сценариев UAT для доступа к заработанной зарплате перед запуском

Набор из 60 сценариев UAT для доступа к заработанной зарплате перед запуском: от учёта рабочего времени до сверки зарплаты

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

> Кратко: Следует запускать систему только тогда, когда тестирование доказывает правильного человека – правильное рабочее время – правильную сумму – правильный счёт – нет дублирования – возможна сверка – в правильный период зарплаты. Все ошибки, связанные с деньгами, распределением прав или личными данными, должны иметь чёткие критерии блокировки.

> Предупреждение: Это библиотека сценариев для справки, она не заменяет тестовый план системы. Не пытайтесь совершать разрушительные транзакции или использовать реальные данные без разрешения. Суммы, счета и тестовая среда должны быть одобрены всеми сторонами.

1. Чем UAT отличается от демонстрации?

(Подробнее: Что нужно подготовить компании для внедрения доступа к заработанной зарплате и Архитектура интеграции доступа к заработанной зарплате.)

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

Каждый тест-кейс должен содержать:

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

2. Подготовка данных для UAT

Создайте контролируемый набор симулированных пользователей:

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

Не используйте реальные идентификационные номера или счета сотрудников за пределами одобренного объёма.

3. Шкала уровней ошибок и условия блокировки

Уровень	Пример	Решение
P1 Критический	Дублирование, неверный человек, утечка ключей/данных	Блокировка запуска
P2 Высокий	Неверная доступная сумма, ошибка в зарплате, превышение прав	Блокировка до исправления и повторного тестирования
P3 Средний	Неверные уведомления, сложные исключительные потоки	Оценка риска и план исправления
P4 Низкий	Ошибки оформления, не влияющие на бизнес	Можно добавить в backlog, если одобрено

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

4. Группа A — Профили и условия использования (UAT 01–06)

UAT 01 — Активный пользователь с полным профилем

Ожидается: вход в систему и отображение правильного клиента/функций.

UAT 02 — Уволенный пользователь

Ожидается: блокировка прав по cut-off; невозможность создания новых запросов.

UAT 03 — Пользователи с одинаковыми именами

Ожидается: система различает по идентификационному ключу, не смешивает рабочее время/транзакции.

UAT 04 — Отсутствующий идентификационный номер или несоответствие OCR

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

UAT 05 — Перевод пользователя к другому клиенту

Ожидается: правильная активация до/после перевода; отсутствие доступа к данным другого клиента.

UAT 06 — Один пользователь работает в нескольких местах

Ожидается: рабочее время и доступная сумма правильно разделены по местам; общая сумма не дублируется.

5. Группа B — Учёт рабочего времени и синхронизация (07–14)

UAT 07 — Учёт времени в реальном времени через приложение

Ожидается: запись появляется в соответствии с SLA, изначально в правильном состоянии.

UAT 08 — Синхронизация с допустимым Google Sheet

Ожидается: правильное сопоставление пользователя/дня/смены; отчёт о количестве успешных строк.

UAT 09 — Ошибочная строка в Sheet с неверным кодом пользователя

Ожидается: добавление в список ошибок, без догадок о привязке к другому пользователю.

UAT 10 — Повторный ввод одного и того же файла/записи

Ожидается: отсутствие дублирования рабочего времени.

UAT 11 — Ночная смена, переходящая через полночь

Ожидается: правильное назначение смены/дня в соответствии с правилами клиента.

UAT 12 — Различные форматы времени/даты

Ожидается: поддерживаемые форматы читаются правильно; неподдерживаемые форматы вызывают чёткие ошибки.

UAT 13 — Два источника с разными данными

Ожидается: применение правильного источника истины/приоритетных правил и выдача предупреждения.

UAT 14 — Прерывание синхронизации и последующее восстановление

Ожидается: отсутствие потерь/дублирования записей; правильные контрольные точки и предупреждения.

6. Группа C — Утверждение и исправление рабочего времени (15–20)

UAT 15 — Утверждение надзором

Ожидается: изменение состояния, сохранение информации о пользователе/времени утверждения.

UAT 16 — Утверждение клиентом

Ожидается: воздействие только на пользователей в пределах клиента.

UAT 17 — Пользователь без прав на утверждение

Ожидается: отказ на сервере и запись в лог.

UAT 18 — Два утверждения почти одновременно

Ожидается: единый согласованный результат, без дублирования событий.

UAT 19 — Исправление утверждённого рабочего времени

Ожидается: возврат в ожидание утверждения, сохранение до/после и обновление доступной суммы по правилам.

UAT 20 — Рабочее время сегодня/в будущем

Ожидается: не учитывается, если не выполнены правила закрытого дня.

7. Группа D — Формулы и доступные суммы (21–28)

UAT 21 — Базовая формула

Ожидается: утверждённое рабочее время × ставка минус уже полученное и резерв соответствует ручному расчёту.

UAT 22 — Нет утверждённого рабочего времени

Ожидается: доступная сумма равна 0 с понятной причиной.

UAT 23 — Округление вниз до 1.000 рублей

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

UAT 24 — Частичное получение в периоде

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

UAT 25 — Резерв по количеству дней

Ожидается: сохранение последних N дней в соответствии с конфигурацией.

UAT 26 — Резерв по проценту/порогу

Ожидается: применение правильных условий; интерфейс объясняет удержанную часть.

UAT 27 — Изменение ставки в периоде

Ожидается: каждое рабочее время использует правильную версию политики или утверждённых правил.

UAT 28 — Несколько клиентов, несколько ставок

Ожидается: отдельный расчёт для каждого места, без использования неправильной ставки.

8. Группа E — Лимиты и контроль использования (29–34)

UAT 29 — Ниже минимального уровня

Ожидается: система отказывает до отправки команды.

UAT 30 — Ровно минимальный уровень

Ожидается: принятие, если выполнены другие условия.

UAT 31 — Ровно потолок на команду

Ожидается: принятие; превышение на единицу вызывает отказ/корректировку по дизайну.

UAT 32 — Превышение потолка в день через несколько команд

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

UAT 33 — Два запроса одновременно с одной доступной суммой

Ожидается: блокировка предотвращает превышение или дублирование.

UAT 34 — Изменение лимита с вступлением в силу

Ожидается: правильный утверждающий, правильная дата вступления в силу и наличие аудита.

9. Группа F — Счета, устройства и идентификация (35–40)

UAT 35 — Счёт VPBank с правильным именем

Ожидается: успешная аутентификация и соответствующее отображение.

UAT 36 — Счёт с неправильным именем

Ожидается: запрет на использование, инструкции по исправлению.

UAT 37 — Несуществующий/неопределяемый счёт

Ожидается: статус не подтверждён, запрет на транзакции.

UAT 38 — Попытка изменить заблокированный счёт

Ожидается: пользователь не может изменить самостоятельно вне процесса; все исключения требуют утверждения/лога.

UAT 39 — Вход на втором устройстве

Ожидается: применение политики один человек–одно устройство и процесса смены устройства.

UAT 40 — Истечение/захват сессии

Ожидается: повторная аутентификация; старый токен не может создавать транзакции.

10. Группа G — Транзакции и банки (41–48)

UAT 41 — Успешная транзакция

Ожидается: один код команды, правильная сумма/счёт, статус и квитанция.

UAT 42 — Явный отказ банка

Ожидается: правильный статус отказа; доступная сумма обработана по правилам.

UAT 43 — Тайм-аут после отправки команды

Ожидается: перевод в ожидание, без повторного списания с новым кодом.

UAT 44 — Поздний ответ после тайм-аута

Ожидается: обновление в рамках одной транзакции, без создания второй записи о деньгах.

UAT 45 — Повторное нажатие на отправку

Ожидается: идемпотентность гарантирует один финансовый результат.

UAT 46 — Неверная подпись/источник ответа

Ожидается: отказ, предупреждение о безопасности; не переводится в статус "списано".

UAT 47 — Потеря связи с сервисом списания

Ожидается: fail-closed, очередь/восстановление по дизайну, уведомление без недопонимания.

UAT 48 — Аварийный выключатель

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

11. Группа H — Сверка и зарплата (49–55)

(Подробнее: см. Сверка транзакций доступа к заработанной зарплате с зарплатой и бухгалтерией.)

UAT 49 — Полное совпадение выписки

Ожидается: все транзакции правильно сопоставлены и отмечены как сверенные.

UAT 50 — Есть в системе, отсутствует в выписке

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

UAT 51 — Есть в выписке, отсутствует в системе

Ожидается: обнаружение от банка в систему и передача на расследование.

UAT 52 — Неверная сумма/дублирование кода

Ожидается: отсутствие принудительного сопоставления; предупреждение и блокировка, если необходимо.

UAT 53 — Включение транзакции в зарплату

Ожидается: только успешные транзакции, правильный человек/клиент/период.

UAT 54 — Транзакция близка к cut-off

Ожидается: применение правильных правил периода и объяснение в отчёте.

UAT 55 — Рабочие дни покрыты

Ожидается: отсутствие накопления в следующем периоде; совпадение ведомости и общей суммы транзакций.

12. Группа I — Распределение прав, данные и операции (56–60)

UAT 56 — Клиент видит данные других

Ожидается: невозможность доступа к пользователям/рабочему времени других клиентов, даже при изменении URL/API.

UAT 57 — Чувствительные права супер-администратора

Ожидается: операции конфигурации/исключений требуют аутентификации, лога и утверждения по правилам.

UAT 58 — Экспорт отчётов и маскировка данных

Ожидается: правильный объём; идентификационные номера/счета замаскированы; экспортируемые файлы контролируются.

UAT 59 — Жалоба "деньги списаны, но не получены"

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

UAT 60 — Восстановление после сбоя

Ожидается: восстановление сервиса в соответствии с целями; отсутствие потерь/дублирования транзакций; сверка подтверждает конечное состояние.

13. Пограничные тесты для конфигурации по умолчанию доступа к заработанной зарплате

Если пилотный клиент использует значения по умолчанию в коде, следует проверить как минимум:

Параметр	Ниже границы	На границе	Выше границы
Минимум/раз	49.000	50.000	51.000
Потолок/команда	2.999.000	3.000.000	3.001.000
Потолок/день	4.999.000	5.000.000	5.001.000
Округление	99.999	100.000	100.001

Эти числа являются техническими значениями по умолчанию и не обязательны для всех клиентов. Тестовый план должен использовать реальные настройки в пилотной среде.

14. Матрица доказательств UAT

Группа	Минимальные доказательства
Профили	Исходные данные, экранные результаты, лог синхронизации
Рабочее время	Записи до/после, утверждающий, аудиторский след
Формулы	Независимые расчёты и результаты системы
Счета	Результаты проверки с замаскированными данными
Транзакции	Код команды, временная шкала состояния, допустимый лог
Банки	Ответы и тестовые выписки
Зарплата	Входные файлы, отчёты, образцы ведомостей
Распределение прав	Матрица прав и попытки заблокированного доступа
Сбои	Временная шкала, предупреждения, runbook и результаты восстановления

Скриншоты в одиночку недостаточны для доказательства полного потока.

15. Рекомендованные условия для запуска

(После запуска: см. Эксплуатация доступа к заработанной зарплате после запуска.)

• 100% сценариев P1/P2 выполнены и достигнуты;
• нет ошибок, которые могут привести к неверному списанию, дублированию или превышению прав;
• рабочее время, транзакции, выписки и зарплата пилотного образца совпадают;
• все ошибки P3 оценены по риску, имеют владельца и срок исправления;
• конфигурация production проверена независимо;
• список пилотных пользователей/клиентов точен;
• лимиты денег и аварийный выключатель утверждены;
• готовность банковских, HR, зарплатных, ИТ и службы поддержки;
• мониторинг/предупреждения активны;
• план отката и коммуникации отработаны.

Не устанавливайте условие "60/60" механически, если некоторые тесты не применимы; необходимо записать причину исключения и утверждающего.

16. Процесс управления ошибками

1. Запись ошибки с данными и доказательствами воспроизведения.
2. Классификация по фактическому воздействию.
3. Назначение ответственного за исправление, без передачи между сторонами.
4. Исправление в контролируемой среде.
5. Повторное тестирование ошибки и связанных регрессионных тестов.
6. Подтверждение результата владельцем бизнеса.
7. Обновление документации, runbook или контроля, если причина не только в коде.

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

17. Часто задаваемые вопросы

Кто должен подписывать протокол UAT?

Должны быть представители владельца бизнеса, владельца продукта/поставщика и представители затронутых областей, таких как HR/зарплата, финансы, ИТ или безопасность в соответствии с RACI.

Нужно ли переводить реальные деньги при UAT?

Предпочтительно использовать песочницу или утверждённые пилотные счета/суммы. Если необходимо тестирование в production, следует ограничить объём, иметь наблюдателя, немедленно сверять и иметь план остановки.

Может ли большое количество unit-тестов заменить UAT?

Нет. Unit-тесты проверяют компоненты; UAT доказывает, что процесс соответствует потребностям пользователей и политике с данными, близкими к реальным.

Может ли небольшая ошибка блокировать запуск?

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

Нужно ли повторно проводить UAT после запуска?

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

---

Автор: Nguyen Minh Khang — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.

Консультации по решениям доступа к заработанной зарплате для бизнеса: Горячая линия 0937.022.655 · Email info@nhankiet.vn · Доступ к заработанной зарплате для бизнеса