EWAの本稼働前に実施する60のUATシナリオ

Doanh nghiệp · 18/09/2026 · 著者: Nguyễn Minh Khang (Chuyên viên ban chiến lược)

EWAの本稼働前に実施する60のUATシナリオ：勤怠から給与照合まで

EWAのUATは「ボタンを押してお金が振り込まれる」だけを確認するものではありません。システムが通常の流れでは問題なく動作しても、勤怠が修正された場合や複数の要求が同時に来た場合、銀行のタイムアウト、従業員の退職、または給与の締め切りがある場合には誤動作することがあります。以下の60のシナリオは、企業がデータと結果を照合できる形で全体のプロセスをテストするのに役立ちます。

> 簡単に言えば: 正しい人 - 正しい勤怠 - 正しい金額 - 正しい口座 - 重複支払いなし - 照合可能 - 正しい給与期が証明された場合にのみ本稼働すべきです。お金、権限、または個人データに関連するすべてのエラーには明確なブロック基準が必要です。

> 警告: これは参考用のシナリオライブラリであり、システムのテスト計画の代わりにはなりません。許可されていない場合、破壊的な取引や実データを試すべきではありません。金額、口座、テスト環境は関係者によって承認される必要があります。

1. UATはデモとどう違うのか？

(詳細は、企業が給与前払いを導入するために準備すべきことおよびEWAの統合アーキテクチャを参照してください。)

デモは、製品が準備された状況で動作することを示します。UATは、製品が実際の条件や例外条件で契約された業務要件を満たしているかどうかを確認します。

各テストケースには以下が必要です：

コードと目的;
前提条件;
入力データ;
実行手順;
期待される結果;
実際の結果;
証拠;
実行者/承認者;
エラーの重大度;
テスト再実行の状態と日付。

2. UATデータの準備

管理された模擬ユーザーを作成：

新規、在職中、退職、異動;
同姓同名だが異なるID;
一つまたは複数の顧客で働く;
通常勤務、夜勤、時間不足、残業;
正しい名前、間違った名前、存在しない口座;
制限に近いユーザー;
成功、失敗、保留、返金の取引;
開いている期間、締め切り間近、ロックされた期間。

承認された範囲外で実際のIDまたは従業員の口座を使用しないでください。

3. エラーの重大度とブロック条件

レベル	例	決定
P1 重大	重複支払い、誤った人、キー/大規模データの漏洩	本稼働をブロック
P2 高	利用可能な金額の誤り、給与の誤り、権限超過	修正と再テストまでブロック
P3 中	誤った通知、使いにくい例外フロー	リスク評価と修正計画
P4 低	業務に影響しない表示エラー	承認されればバックログに追加可能

最終基準はテスト計画に記載されるべきであり、本稼働の日に感情的に決定されるべきではありません。

4. グループA — プロファイルと使用条件 (UAT 01–06)

UAT 01 — 現在活動中で、プロファイルが完全

期待される結果: ログインして正しい顧客/機能が有効になっていることを確認。

UAT 02 — 退職済みの人

期待される結果: カットオフに従って権限がロックされ、新しい要求が作成されない。

UAT 03 — 同姓同名の人

期待される結果: システムは識別キーで区別し、勤怠/取引を混同しない。

UAT 04 — IDが不足またはOCRが一致しない

期待される結果: 取引を許可せず、処理手順を表示し、他人のデータを漏らさない。

UAT 05 — 顧客を異動した人

期待される結果: 異動前後の有効性が正しく、顧客データを誤って表示しない。

UAT 06 — 複数の場所で働く人

期待される結果: 勤怠と利用可能な金額が正しく分離され、合計が重複しない。

5. グループB — 勤怠と同期 (07–14)

UAT 07 — リアルタイムの勤怠アプリ

期待される結果: 記録がSLAに従って表示され、初期状態が正しい。

UAT 08 — 有効なGoogle Sheetの同期

期待される結果: 正しい人/日/シフトが結合され、成功した行数が報告される。

UAT 09 — シートの行に誤った人コード

期待される結果: エラーリストに追加され、他の人に誤って割り当てられない。

UAT 10 — 同じファイル/記録を再入力

期待される結果: 勤怠が二重にならない。

UAT 11 — 深夜をまたぐシフト

期待される結果: 顧客のルールに従って正しいシフト/日付が割り当てられる。

UAT 12 — 異なる時間/日付形式

期待される結果: サポートされている形式が正しく読み取られ、サポートされていない形式は明確なエラーを報告する。

UAT 13 — 2つのソースに異なるデータ

期待される結果: 正しいソースの真実/優先ルールが適用され、警告が発せられる。

UAT 14 — 中断後の同期ジョブの再実行

期待される結果: 記録が失われたり二重にならず、チェックポイントと警告が正しい。

6. グループC — 勤怠の承認と修正 (15–20)

UAT 15 — 有効な監督者による承認

期待される結果: 状態が変更され、承認者/時間が記録される。

UAT 16 — 有効な顧客による承認

期待される結果: 顧客の範囲内の人にのみ影響を与える。

UAT 17 — 承認権限のない人

期待される結果: サーバーで拒否され、ログが記録される。

UAT 18 — ほぼ同時に2つの承認

期待される結果: 一貫した結果が得られ、重複イベントが作成されない。

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 — 各命令の上限ちょうど

期待される結果: 受け入れられ、1単位超過で拒否または設計に従って調整される。

UAT 32 — 複数の命令で1日の上限を超える

期待される結果: 1日の命令合計がポリシーを超えない。

UAT 33 — 同時に利用可能な金額で2つの要求

期待される結果: ロックが重複支払いまたは重複支払いを防ぐ。

UAT 34 — 有効な制限変更

期待される結果: 正しい承認者、正しい有効日、監査トレイルがある。

9. グループF — アカウント、デバイス、識別 (35–40)

UAT 35 — 正しい名前のVPBankアカウント

期待される結果: 認証が成功し、適切にマスクされる。

UAT 36 — 間違った名前のアカウント

期待される結果: 使用が許可されず、処理手順が表示される。

UAT 37 — 存在しない/検索できないアカウント

期待される結果: 未確認状態を保持し、支払いを許可しない。

UAT 38 — ロックされたアカウントの変更を試みる

期待される結果: ユーザーはプロセス外で変更できず、すべての例外に承認/ログがある。

UAT 39 — 2台目のデバイスでのログイン

期待される結果: 1人1台のポリシーとデバイス変更プロセスが適用される。

UAT 40 — セッションの期限切れ/乗っ取り

期待される結果: 再認証が要求され、古いトークンが取引を生成しない。

10. グループG — 取引と銀行 (41–48)

UAT 41 — 成功した取引

期待される結果: 1つの命令コード、正しい金額/口座、状態、受領書。

UAT 42 — 銀行による明確な拒否

期待される結果: 失敗状態が正しく、利用可能な金額がルールに従って処理される。

UAT 43 — 命令送信後のタイムアウト

期待される結果: 保留に移行し、新しいコードで再支払いしない。

UAT 44 — タイムアウト後の遅延応答

期待される結果: 同じ取引で更新され、2つ目の金額記録を作成しない。

UAT 45 — 繰り返し送信

期待される結果: 再試行性が1つの財務結果を保証する。

UAT 46 — 誤った署名/ソースの応答

期待される結果: 拒否され、セキュリティ警告が発せられ、支払い済みに変わらない。

UAT 47 — 支払いサービスの接続喪失

期待される結果: fail-closed、設計に従ったキュー/復旧、誤解を招かない通知。

UAT 48 — 緊急停止スイッチ

期待される結果: 新しい命令を防ぎ、保留中の取引が保護され、再開には権限とログが必要。

11. グループH — 照合と給与 (49–55)

(詳細は、EWA取引と給与、会計の照合を参照してください。)

UAT 49 — 完全一致の明細書

期待される結果: すべての取引が正しく結合され、照合済みとしてマークされる。

UAT 50 — システム上にあり、明細書にない

期待される結果: 例外が生成され、証拠なしで自動結論や修正を行わない。

UAT 51 — 明細書にあり、システムにない

期待される結果: 銀行からシステムへの検出が行われ、調査に移行される。

UAT 52 — 金額の誤り/重複コード

期待される結果: 強制的に結合せず、警告が発せられ、必要に応じてロックされる。

UAT 53 — 給与に取引を含める

期待される結果: 成功した取引のみが、正しい人/顧客/期間に含まれる。

UAT 54 — 締め切り間近の取引

期待される結果: 期間のルールが正しく適用され、ブリッジレポートが説明可能。

UAT 55 — カバーされた勤怠日

期待される結果: 次の期間に再集計されず、給与明細と取引合計が一致する。

12. グループI — 権限、データ、運用 (56–60)

UAT 56 — 顧客によるデータのクロスビュー

期待される結果: 他の顧客の人/勤怠にアクセスできず、URL/APIを変更してもアクセスできない。

UAT 57 — センシティブなスーパーユーザー権限

期待される結果: 設定/例外操作に認証、ログ、規定に従った承認がある。

UAT 58 — レポートのエクスポートとデータのマスキング

期待される結果: 正しい範囲で、ID/口座がマスクされ、エクスポートされたファイルが管理される。

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証拠マトリックス

グループ	最低限の証拠
プロファイル	ソースデータ、結果画面、同期ログ
勤怠	前後の記録、承認者、監査トレイル
計算式	独立した計算表とシステム結果
アカウント	データがマスクされた検証結果
取引	命令コード、状態タイムライン、有効なログ
銀行	応答とテストステートメント
給与	入力ファイル、ブリッジレポート、サンプル給与明細
権限	権限マトリックスとアクセス拒否テスト
障害	タイムライン、警告、ランブック、復旧結果

単一のスクリーンショットはエンドツーエンドのフローを証明するのに十分ではありません。

15. 本稼働条件の提案

(本稼働後: EWAの本稼働後の運用を参照してください。)

100%のP1/P2シナリオが実行され、達成されている;
誤った支払い、重複支払い、権限超過のエラーがない;
パイロットサンプルの勤怠、取引、ステートメント、給与が一致している;
すべてのP3エラーがリスク評価され、所有者と修正期限がある;
本番設定が独立して検証されている;
パイロットの人/顧客リストが正確である;
金額制限と停止スイッチが承認されている;
銀行、HR、給与、セキュリティ、カスタマーサポートの連絡先が準備されている;
監視/警告が機能している;
ロールバックとコミュニケーション計画がリハーサルされている。

一部のテストが適用されない場合、「60/60を満たす」ことを機械的に条件としないでください。除外理由と承認者を記録する必要があります。

16. エラー管理プロセス

データと再現可能な証拠でエラーを記録する。
実際の影響に基づいてレベルを分類する。
処理担当者を特定し、関係者間での責任転嫁を避ける。
管理された環境で修正する。
エラーテストと関連する回帰テストを再実行する。
業務担当者が結果を確認する。
原因がコードだけでない場合、ドキュメント、ランブック、または制御を更新する。

ログ、データ、時間条件を確認せずに「再現できない」としてエラーを閉じないでください。

17. よくある質問

誰がUATの署名をする必要がありますか？

業務担当者、製品/プロバイダーの責任者、HR/給与、財務、IT、セキュリティなどの影響を受ける領域の代表者がRACIに従って署名することが推奨されます。

UATで実際にお金を送金する必要がありますか？

サンドボックスまたは承認されたパイロットアカウント/金額を優先します。プロダクションでのテストが必要な場合は、範囲を制限し、監督者がいて、即時照合と停止計画が必要です。

ユニットテストが多いとUATの代わりになりますか？

いいえ。ユニットテストはコンポーネントをテストしますが、UATはプロセスがユーザーのニーズとポリシーを実際のデータで満たしていることを証明します。

小さなエラーが本稼働をブロックすることがありますか？

影響によります。表示エラーはブロックしないかもしれませんが、金額の誤解、データ漏洩、権限の誤り、照合に影響を与えるエラーは厳格に評価されるべきです。

本稼働後にUATを再実行する必要がありますか？

計算式、制限、勤怠ソース、銀行、給与、権限、インフラ、またはリリースに大きな影響がある場合、回帰テストが必要です。

---

著者: Nguyen Minh Khang — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.

企業向け給与前払いソリューションの相談: ホットライン 0937.022.655 · メール info@nhankiet.vn · 企業向け給与前払い

← ニュース