ロボットのテスト計画（正常系・異常系・件数のテストの観点）
ロボットを本番で使う前に行うテストの観点を整理します。正常なデータだけでなく、異常なデータ・画面の例外・大量件数・再実行のテストを行うことで、本番での停止を減らします。
テストが不足するとどうなるか
開発者が用意した数件のきれいなデータでしか試していないロボットは、本番の多様なデータに出会うと止まります。RPA のロボットは、プログラムと同じように、事前のテストで品質が決まります。とくに、人が無意識に対応していた例外を、ロボットがどう扱うかを確認することが重要です。
テストの観点
次の観点でテストケースを用意します。開発前に作った業務手順書と例外の一覧が、テストケースの元になります。
- 正常系：普段の典型的なデータで、最初から最後まで処理できるか
- データの異常系：必須項目が空、桁数・形式の違い、存在しないコード、全角と半角の混在
- 画面の例外：確認ダイアログ、お知らせのポップアップ、セッション切れ、システムのエラー画面
- 件数：0件、1件、普段の件数、月末など最大の件数
- 再実行：途中で止めて再実行したとき、二重に処理しないか
- 運用：スケジュール実行、通知のメール、出力ファイルの場所と名前
テスト環境とデータ
本番のシステムにテストのデータを登録してしまうと、取り消しが難しい場合があります。テスト用の環境があれば、そこでテストします。テスト環境がない場合は、登録の直前で止めるテスト用の設定を用意する、登録したテストデータを削除する手順を決めておく、など、本番に影響を与えない方法を業務の担当者と相談して決めます。
テスト結果の記録
テストケースごとに、使ったデータ・期待した結果・実際の結果・確認した人と日付を記録します。記録の例を示します。
［テスト記録の例］
No | 観点 | テストデータ | 期待する結果 | 結果 | 確認日
1 | 正常系 | 普段の10件 | 10件すべて登録、結果に「完了」 | OK | 10/3
2 | データ異常 | 金額が空欄の行を含む | その行だけ「入力エラー」、他は完了 | OK | 10/3
3 | 画面の例外 | 重複登録の確認ダイアログ | ダイアログを閉じて次の件へ | NG→修正→OK | 10/4
4 | 再実行 | 5件目で停止後に再実行 | 1〜4件目は飛ばし、5件目から処理 | OK | 10/4業務の担当者に確認してもらう
最後に、業務の担当者に結果を確認してもらう受け入れテストを行います。ロボットの動きそのものより、「出力の形や通知の内容が、実際の業務で使いやすいか」を見てもらうことが目的です。本番開始後もしばらくは、ロボットの結果を人がチェックする期間を設けると安心です。
※BizRobo! は RPA テクノロジーズ株式会社の製品です。本サイトは同社とは関係のない個人の解説サイトです。画面や機能の名称は、製品のバージョンによって異なる場合があります。
ほかの記事
BizRobo!の基本BizRobo! の構成を理解する（Design Studio・Management Console・RoboServer の役割）BizRobo! を使い始めるときに最初に混乱しやすい、Design Studio・Management Console・RoboServer の役割分担と、ロボットが作られてから実行されるまでの流れを整理します。BizRobo!の基本ロボット開発の進め方（業務の洗い出しから手順書・分割まで）いきなり Design Studio を開くのではなく、業務の手順を書き出し、例外を洗い出し、ロボットを小さく分けてから作る進め方を解説します。手戻りを減らすための準備の型です。BizRobo!の基本タイプと変数の考え方（データ設計でロボットを読みやすくする）BizRobo! の変数とタイプ（.type ファイル）の関係、グローバル変数の使いどころ、変数名の付け方など、ロボットのデータ設計の基本を解説します。BizRobo!の基本DS と DA の使い分け（Web 操作とデスクトップアプリ操作）BizRobo! で Web システムを操作する DS ロボットと、デスクトップアプリを操作する DA（Desktop Automation）の違い、それぞれが向いている業務、組み合わせるときの注意点を解説します。