金融アプリのテストでは、動画や操作ログ、環境情報、端末識別情報などを記録する「証跡管理」が行われます。なぜ、テスト時の証跡を残す必要があるのでしょうか？ そして、証跡を残すためにはどのようなサービスを利用すべきなのでしょうか？本記事では、アプリ開発時において証跡を残す必然性と、証跡を効率的に残すための方法を解説します。

見出し

金融アプリには、テストを継続的に行うことがルール化されている

　銀行などの金融機関は、顧客からお金という貴重品を預かり、それを貸し出すことを業務としています。そのため金融機関には、このお金の「移動」を、エラーやも滞りなく、安定的に実行することが求められます。

　特にサイバー攻撃が多発している現在、悪意のある第三者からの攻撃を防ぐことは、金融機関の使命ともいえるでしょう。

　実際に金融庁では、2024年10月に「金融分野におけるサイバーセキュリティに関するガイドライン」（以下、金融庁ガイドライン）という資料を発表。「サイバー攻撃の脅威は、金融サービス利用者の利益を害し、金融システムの安定に影響を及ぼしかねない」「金融機関等は、各業法において、業務の健全かつ適切な運営等を確保しなければならない」と、金融機関が自らサイバーセキュリティを徹底することを求めています。

　同ガイドラインではさらに、ユーザーが日常的に利用するスマートフォンの金融アプリケーション（以下、金融アプリ）についても、セキュリティ対策を実施することを求めています。

金融アプリのテストに欠かせない「証跡」をどう残すか？

　金融アプリを継続的にシステム改修していく中では、アプリの品質が改修前よりも悪化してしまう「デグレード」（デグレ、先祖返り）が発生する恐れもあります。こうしたデグレードを防ぐためには　過去に正しく動作していた機能に不具合がないかを再検証するテスト「リグレッションテスト」（回帰テスト）を行う必要があります。

　このテストを行う際に鍵となるのが「証跡」です。
　証跡とは、アプリの特定の機能が「動いた/動かなかった」を検証するだけではなく、品質保証・監査・社内説明の観点から「どの端末で」「どのOS」「環境」で「誰が」「いつ」「どの操作を行い」「その結果どうなったか」まで、検証した証明として残すことを指します。

　実際に金融庁ガイドラインの「2.5.2. インシデントへの対応及び復旧」の「分析」の項目には、「対応が必要と判断したインシデントについて、攻撃の手口や原因・経路、システムへの影響、現在発生している業務影響及び今後発生しうる業務影響等について分析すること。特に、分析を行う際は事前にログ等の証跡を保全し、分析は保全したログ等に対して行うこと」という記述があります。つまり、インシデントが発生した時、何がいけなかったのかを分析するために、証跡が求められるというわけです。

　一般的なアプリ開発では、証跡を残すことはテストがNGの場合のみに限られがちです。しかし金融アプリの場合、上記のようなガイドラインが存在するため、OK/NGに関わらず、全手順の証跡が必要になります。

　証跡の具体例としては、以下のようなものが挙げられます。

・画面録画・スクリーンショット（実際の挙動を第三者が確認できる）
・操作ログ（どの操作手順で不具合が発生したかを追跡可能）
・環境情報、OSバージョン、端末機種、WebView／ブラウザ情報、ネットワーク状態
・端末識別情報（特定端末依存の問題切り分けに必須）

　まとめると、金融アプリには「不具合を発生させないこと」と同じくらい、「不具合の理由を説明すること」が重要であり、そのために報告・説明責任を果たすための客観的な資料を残す必要がある、ということがいえます。

手元のスマートフォンやエミュレータの場合、証跡を残すのは難しい？

　ここで注意したいのが、テスト方法によっては証跡の管理が難しくなるケースがあるということです。

　例えば、社内のスマートフォンで検証を行う場合、録画やログ取得が、テスト実行者の人手頼みになりがちです。なぜなら操作タイミングや正確な手順などをメモしながら進めるため、証跡に抜け漏れが発生しやすくなります。たとえ、操作を録画しようとしても、録画し忘れるといったミスも起こり得ます。

　さらに、記録の粒度にばらつきが出ることで、属人化につながるという課題もあります。証跡を残す作業が属人化した場合、不具合の再現が他の人が残した証跡では再現できなくなり、証跡が正しく評価できないという、本末転倒な事態に発展することもあります。たとえば証跡が不十分で不具合が再現せず、再テストにさらなる時間を要してしまうケースも起こり得ます。

　エミュレータを使って証跡を残す場合は、ログを自動的に保存する設定にしておくことで、容易に証跡を残すことが可能です。しかし、エミュレータは実機とは異なる挙動を起こす恐れがあるため、エミュレータで残した証跡が、手元のスマートフォンでは再現できない恐れもあります。

　加えてエミュレータで残した証跡は、設定次第で情報を書き換えられる余地もあります。

　信頼性の薄い証跡を残すことは、障害調査の長期化、開発・QA間の認識齟齬、リリース判断の不透明化などのトラブルが発生する恐れがあります。第三者に対する証跡としての客観性と非否認性を考慮するのであれば、改ざんの余地が少ない、実機から出力されるログを利用すべきです。

　以上のことをまとめると、実機を使いながらも、信頼に足る証跡を残すことができるテストツールこそが、金融アプリのテストには求められているといえるでしょう。

＜参考資料＞
【無料DL可能】：金融アプリのテスト実行環境は、 結局どの方法が効率的なのか？手元のスマートフォン・エミュレータ・デバイスクラウドを比較！

デバイスクラウドであれば、証跡が残しやすい！Remote TestKitの場合

　信頼性の高い証跡が残しやすいテスト手法の1つが「デバイスクラウド」です。デバイスクラウドとは、クラウド環境にスマートフォン実機を取り揃え、リモートから実機を操作することでテストを行う方法です。

　デバイスクラウドのメリットは、実機環境での操作をそのまま記録できること、端末・OS・環境情報を自動的に紐づけられることにあります。デバイスクラウドであれば、手持ち端末やエミュレータでの検証で発生する課題を解消し、信頼性の高い証跡を残すことが容易になります。

　具体的なソリューションとしてNTTレゾナントテクノロジーが提供する「Remote TestKit（リモートテストキット）」があります。このツールでは、操作動画と環境情報がセットで証跡として保存できるため、チーム内で再現条件の共有・引き継ぎが容易になり、障害の調査や原因特定のスピードを向上させることができます。

　Remote TestKitを活用することの効果としてあｈ、以下のようなことが期待できます。

・調査工数の削減
不具合報告を受けた開発者が行う再現手順の確認が、操作動画と詳細ログの紐づいた証跡を用いることによって、スムーズに完了することが可能です。金融アプリの修正を含めた開発のライフサイクル全体を迅速化できます。

・品質説明の明確化
金融アプリのリリース判断には多くのステークホルダーの合意が必要であり、そのためにはエビデンスに基づいたテスト結果と説明責任が必要です。Remote TestKitでは動作テストの証跡が詳細に残せるため、高いレベルで説明責任を果たすことができます。

・テストの属人化防止
操作中のようすが動画で証跡として残せるため、「特定のテスト作業者しか不具合のコツを掴めない」という属人的な状況を回避することができ、経験の浅いメンバーでも質の高い検証が可能になります。

　冒頭でも触れたように、金融庁ガイドラインが設けられたことにより、金融アプリにおいて証跡を取得することが業界では求められています。しかし、手元のスマートフォンやエミュレータによる検証では、高品質な証跡を残すことが難しい場合があります。

　しかしRemote TestKitのようなデバイスクラウドであれば、実際の端末を用いたテストの結果を動画として自動で残すことができ、簡単に証跡として残すことが可能です。エミュレータとは異なりスマートフォン実機でのテストのため、証跡としての信頼度も高く、テストの属人化を防ぐことも可能です。

　金融アプリにおいては、証跡の質の高さも、品質の高さを証明する重要な要素となります。証跡を残すことに手間取っていたり、アプリのテスト結果に不安を覚えているのであれば、デバイスクラウドを利用することも、選択肢の一つに入れておくべきでしょう。

＜参考資料＞
【無料DL可能】：金融アプリのテスト実行環境は、 結局どの方法が効率的なのか？手元のスマートフォン・エミュレータ・デバイスクラウドを比較！