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件目など）で、登録エラーと、同じことを、擬似的に、発生させる、ロジックを付け加えると。
実際に、データの登録作業を、せずとも、「正しいデータなのに、登録に失敗したときの、動作（リカバリーや、ログ・状況の保全）が、正しく、できるかどうか」のテストも、可能になります。