安全かつ、正確に、RPAツールを、動作させるためには。
テストは、不可欠なものです。
ここでは、RPAの、テスト手法について。いくつかの、観点と、手法を、ご案内します。
1. テストデータの作り方
RPAの、動作を、テストするときは、テストデータを、作ることが、多いと思います。
ここでは、必要なデータの、作り方を、記載します。
データを作る上での、テストの考え方
テストの考え方は、おおまかに、「正常系」と、「異常系」に、わかれます。
正常系は、想定しているデータです。
異常系は、以下のデータが、含まれます。
- RPAのロジック（ワークフロー／シナリオ）が、正常に動作できない
- 期待されている形式ではない（金額のデータに、文字が入っているなど）
- データそのものがない
- データの範囲が異常
「最低限の動作をする」という、観点では、正常系のテストだけでも、良いように見えます。
しかし、RPAの安定動作や、事故防止を考えると、異常系のテストも、可能な範囲で網羅しておくほうが、安全ですし、長期的に、メリットが大きいです。
テストデータの作り方（基本編）
さて、具体的に、テストデータを作るときの、考え方です。
数値（整数）の場合
数値（金額や、個数など）は、比較的、テストデータを作るのが、容易です。
テストすべき値は、
- 許容する値の最小限のギリギリ外側
- 許容する値の最小限
- 許容する値の最大限
- 許容する値の最大限のギリギリ外側
です。言葉で書くと、わかりにくいのですが、たとえば、
経費精算で、自動化で許される最大値は、0円より大きく、1万円とする
という、要件があった場合。
- 0（最小値のギリギリ外側）
- 1（最小値）
- 10000（最大値）
- 10001（最大値のギリギリ外側）
の、4つのパターンを、テストすれば、良いことになります。（もちろん、0円や、10001円の、ケースは、エラーとして、弾かれる必要があります）
但し、上記は、あくまで、「入力値が数値であること」が、前提なので。
自由入力が、可能な場所から、値を取得するなら、
- あいうえお
のような、文字列や、
- 10あいうえお00
のように、文字・数字の混在、
- 100000000000000000000000000000000000000000000000000000000000000000000000000000000000
のように、一般的な、数値型では、処理できない桁数のデータ、
- 10５０
のような全角・半角の混在、
- 10五0
- 5百
のように、漢数字が入った・混在したケースも、実施しておくと、より安全です。
数値（小数を含む）の場合
基本的な、考え方は、数値（整数）の場合と同じです。
ただ、小数点以下、何桁までを想定するのか、検討して、範囲をオーバーする場合の、境界になる値を、設定する必要があります。
自由入力の文字（文字列）の場合
自由入力の場合は、観点として、
- 0文字（入力がない）を、許容するか
- 使用禁止の文字が、あるか
- 最小の文字数
- 最大の文字数
を、確認・規定する必要があります。
**最大文字数は、業務上、特に規定がなくても、RPAのロジックとしての、最大値は、決めておいたほうが、無難です。**たとえば、システムに登録する際、実は文字数に、上限があったとか。ツールが、受け取れる、文字数に、上限があったとか。そういった、トラブルが、発生したとき、原因の、切り分けや、意図しない動作を、防げるからです。
その上で、
- 0文字のデータ
- 最小の文字数より1文字短いデータ（0文字を許容するときは省略可）
- 最大文字数のデータ
- 最大文字数より、1文字多いデータ
を、検証すれば良いでしょう。
文字列（定型）の場合
たとえば、郵便番号であれば、
(数字3桁)-(数字4桁)
のような、固定入力になることがあります。（上記で、ハイフンなしを許容するのか、あるいは全角ハイフンも許可するのか、といったケースは、別途、検討する必要があります）
基本的な、テストの考え方は、「どのように、定型であるかを、チェックするか」に、依存します。
前述の、郵便番号のような、例であれば、「文字数のチェック」と、「前3文字の数値チェック」「4文字目がハイフンかどうかのチェック」「後ろ4文字の数値チェック」に、わけて、実装するケースがあります。
その場合は、それぞれが、条件を満たす・満たさないの、マトリックスを作り、テストデータを作ります。
・・・ただ、これは結構、大変なので。可能であれば、定型の文字列は、正規表現などで、チェックすると。
正規表現の、チェックのみ、別途行えることもあり、比較的、テストケースが少なくて、済みます。
たとえば、さきの、郵便番号でしたら、
^\d{3}[\-－]?\d{4}$
のような、感じでしょうか？
RPAの、ロジック上、このような、チェックであれば、
- 入力値が正しい・ハイフンなし（1234567）
- 入力値が正しい・ハイフンあり（123-4567）
- 入力値が0文字
- 文字数が足りない（123456）
- 文字数が多い（12345678）
- 文字数は正しいけれども、形式がおかしい（1234-567）
ぐらいのテストで、現実的には、問題ないでしょう。
テストデータの作り方（応用編）
たとえば、本番データで、個人情報を含む場合の、テストは、[ユーザーローカルさん](ユーザーローカル https://www.userlocal.jp/)の、[個人情報テストデータジェネレーター](個人情報テストデータジェネレーター https://testdata.userlocal.jp/)などで、ダミーデータを作成できます。
（他にも、似たようなサービスは、いくつかあるので、検索してみてください）
これらのデータを、そのまま使うだけでなく、前述のような、異常系のデータを、一部混ぜて、動作を見るのも、最終的なテストには、良いかもしれません。
2. 部品単位でのテスト
RPAの、ツールによって、実施できたり、できなかったりしますが。
1つの、ロジック（ワークフロー／シナリオ／ロボット）を、作る上で、機能・操作を、分割できるツールも、多くあります。
この、機能を使うことで、テストをより、容易にできます。
たとえば、Excelから、データの読み取りを、行い、基幹システムに、書き出す、実装を、考えてみてください。
入力値の、チェックは、データを読み取る部分だけ、切り出して、作れば、そこのみのチェックで、行えます。
（言い換えれば、後続のロジックは、受け取るデータが、正しいものとして、処理を進められます。これは、不要な例外系を、実装するコストや、テストするコストを、軽減できるので、開発効率に、寄与します）
基幹システムに、登録する処理は、別途、最低限のデータ量で、試してみるしか、ないでしょう。（基幹システムの、テスト用環境が、あれば、そちらでガンガン登録するのが、最善ですが）
入力と、出力の、テストが終わったら。それらを、制御する、全体の、テストです。
このとき、基幹システムへの、登録は行わず、書き込んだことにして、ログに残す、テスト用のロジック を作る手法が、あります。いわば、登録部分の、身代わりです。
全体を、制御する部分の、試験のときは、そちらを使うことで。実際に、大量のダミーデータを、システムに登録することなく、他の部分の、テストができます。
応用として、上記の例で、基幹システムに、登録したことにする、テスト用の、ダミーロジックに。一定のタイミング（たとえば、10件目など）で、登録エラーと、同じことを、擬似的に、発生させる、ロジックを付け加えると。
実際に、データの登録作業を、せずとも、「正しいデータなのに、登録に失敗したときの、動作（リカバリーや、ログ・状況の保全）が、正しく、できるかどうか」のテストも、可能になります。