RPA品質を効率良く高めるテスト５か条
※ こちらは UiPath Advent Calendar 2020 の 12/29 担当分の記事です。
試験って難しいですよね。完璧にやったつもりでも思わぬ不具合が出てしまう事も珍しくありません。
そもそも試験って何の為にやるのでしょう？専門的な定義は多々ありますが、要は「良い品質のものをリリースする為」にやるのだと思います。
良い品質のものをリリースする為に試験は重要ですが、根性論で試験を頑張っただけではなかなか品質は上がらないものです。
良い試験をする為には試験の専門的な勉強が必要なのですが、この記事では少しアプローチを変えて、少し肩の力を抜きながら様々なアプローチを組合わせて品質を高めていくTipsについて説明して行きます。
第１条 不具合を受け入れよう
■ 完璧なテストは不可能
完璧なテストには無限のテストが必要であり、不可能と言われています。
■ 環境の変化でも問題は起きる
十分試験したコードも、環境変化で動かなくなってしまいます。ＲＰＡは特に環境変化が起きやすい技術ですので、問題を完全に避ける事は出来ません
■ 0点か100点かで考えない
上述の通り完璧は有り得ないので、不具合が無ければ100点、不具合が1つあれば0点と言う考え方だと、だんだん心が疲れてきます。不具合が少しぐらいあっても、ユーザがRPAを使って喜んでいたら、まずは自分を褒めてあげましょう。
第２条 試験以外にも目を向けよう
■ 試験以外の工程も大事
品質を高める為に試験を頑張っている方は多いと思います。間違っていないですが、一度冷静になってみましょう。
不具合は、試験よりも前の工程で混入します。原因は、要件定義漏れ、実装ミス、開発・本番環境の差異、ミスコミュニケーションなど様々です。これらを１つ１つ丁寧に予防していく事で品質は確実に高まります。
■ リスク管理で品質のハードルを下げる
完璧な品質じゃないからと言って、必ずしも問題になる訳ではありません。セキュリティ事故や深刻な業務影響に繋がる個所はしっかりテストして確実にトラブルを予防し、他の部分はほどほどに、メリハリのある試験をしましょう。
異常時の業務影響が小さい場合、思い切って品質を下げて開発スピードを上げる事でユーザにも喜んで貰える事もあります。逆に、絶対に不具合が許容できない様な業務は自動化対象外にすると言うのも１つの選択です。業務ごとに「ちょうど良い品質」を目指す事が大切です。
【補足】
こういった、想定される悪いシナリオを想定して備える事を、プロジェクト管理の分野ではリスク管理と呼びます。リスク管理に興味がある方は、下記の書籍を読んでみて下さい。ブラックジョークの混ざったエッセイ風で頑張らずに読める点がGoodです。熊（リスクの比喩）と華麗に踊ってコントロールしましょうと言う前向きなコンセプトのリスク管理本です。この本に若い頃に出会えてから、色んなチャレンジに踏み出せる様になりました。
■ 複数の手段で品質を高める
何事も、１つの事を極めるには途方もない時間と努力が必要になります。上述の様々な手段を組合わせる事で、がんばり過ぎずに効率よく、ユーザが満足するのに必要十分な品質を目指しましょう。
第３条 試験の計画を立てよう
■ 品質管理のやり方は千差万別
(1) 単体テスト、(2) 結合テスト、(3) 受入れテスト（UAT）の3工程か、それに近い内容でテストをしている開発現場が多いかと思います。一方で「それぞれの工程でどんな不具合を見つけるか？」が曖昧な事も多いです。例えば「5分以内に処理を完了する」「異常発生時にメールを送る」と言った機能が動く事はどこで確認するのが適切でしょう？絶対唯一の正解と言うのは無いので、PRJ毎に決めておく必要があります。
■ やり方を決めて認識をあわせる
上記の通り、各工程でやる事を決めたら、関係者で共有しましょう。認識がずれていると、大事な試験がお見合いで漏れたり、上司への報告が上手く伝わらなかったりします。前提がシェアできていると、仕事がやり易くなってストレスも少なくなります。
【補足】
試験の5W1Hを計画を立てる時は、5W1Hを意識してみましょう。何を（What）、どの工程で（When）、どの環境で（Where）などを気にしておきましょう。
特に漏れてしまいがちな観点が、例外処理、性能要件、開発・開発環境の差異、安定性、などです。どの工程で、どうやってテストするのか事前に決めておきましょう。
第４条 チームワークで乗切ろう
■ ユーザの協力を得る
開発していると必ず直面するのが、ユーザしか知らない隠れ仕様による要件定義漏れです。これは、開発者が見つけるには限界があるので、ユーザに受入れテスト（UAT）で見つけて貰いましょう。
【補足】UATの2つのコツ
(1) 開発者自身がテストシナリオを用意して、全機能を確実にチェックして貰いましょう。
(2) 開発者の思いもよらない様な問題を見つける為に、テストシナリオを使わずに、ユーザ自身に自由に操作して貰いながら「要件定義漏れ」の課題を見つけましょう（専門用語では、これを探索的試験と言います）。
■ キックオフMTG
要件定義・品質管理を進める上でユーザは強力な味方です。逆に、ユーザに当事者意識や参加意欲が無いと、プロジェクトの成功は困難になります。ユーザにはしっかり協力を依頼しましょう。
急に頼んでも対応して貰えないので、プロジェクトのはじめにキックオフMTGをして必要な事を伝える事が重要になります。どんなに小さなプロジェクトでも、プロジェクト体制図を書きましょう。体制図には、開発チームだけでなく業務チームを書き、ユーザの役割を文章で書いて合意しましょう。
特にUATについては丁寧に会話しておきましょう。「ユーザ自身が責任を持って品質の最終チェックを行う事」を明確にして合意をしたり、「UATの時期が繁忙期に被ったりせずに現実的な内容になっているか」など確認しておくと後がスムーズになります。
第５条 不具合が出てからが大事
■ 共通認識が大事 品質が評価されるのはリリース後
品質は、ユーザが実際に使う際に問題が生じるかどうかで判断されます。問題が起きた場合でも、適切な対処で問題を極小化出来れば、ユーザから見た品質を損ねずに済みます。
■ 初動が大事
問題が起きたら、影響を受ける方々へ報告・連絡・相談をした上で、被害拡大が懸念される場合はロボットを止めて、手動運用に切替えるなどの対応を速やかに実施しましょう。不具合があっても、適切な対応によって深刻化を回避できる場合があります。
■ 事前に備えを
問題が起きてから冷静に適切な対応をするのはとても難しいものです。防災マニュアルの様に、有事の対策を事前に作っておきましょう。対処の順序や連絡先の明確化、あるいは業務ごとに障害時の想定影響などが整理されていると対応がスムーズになります。
おわりに
品質と言うのは本当に難しいもので、決して疎かにしてはいけない一方で、気にしすぎると雁字搦めで動けなくなってしまうものだと思います。今回は、筆者のアジャイル、DevOps、プロジェクトマネジメントの経験に基づいて、完璧主義になり過ぎず、様々な手段の組合せで品質を高めたる方法について書かせて頂きました。重要な自動化業務を担う読者の皆様が、品質のプレッシャーを跳ねのけて、RPAをもっと楽しんで開発して行く上でお役に立てば嬉しいです。
なお、品質をもっと頑張りたい！と言う方は、プロジェクト管理資格のPMBOK、品質管理の資格のISTQB等を勉強されると良いと思います。これはこれで、とても面白い分野です。専門資格なので、本気で資格を取ろうとすると相当に大変だと思いますが、個人の記事でポイントを学んだり、関連書籍を流し読みするだけでも得られるものは多いかと思います。
この記事が気に入ったらサポートをしてみませんか？