最近、業界でもテスト駆動開発を導入しようとする試みが多く見られますね。今回はメンテナンスの観点からテスト方法論についてお話ししようと思います。テストについて語るときに避けて通れないのが、そのオーナーシップに関する議論です。テストのオーナーがシステムなのか、ビジネスユーザーなのかということですね。個人的な意見を述べる前に、テストの本質についてまず触れてみましょう。
システムの新規開発やメンテナンス追加開発、いずれにしてもテストが完全に終了したと言うためには、最終アプリケーションのテストが完了している必要があります。何よりも実際の使用レベルでの動作保証が重要だからです。もちろん、開発者たちも開発しながらテストを行っています。テストをせずに開発を進めるのは、差はあれど言葉にできないほど重要です。その際、どれだけ効果的にテストが行われたかによって、ユーザーテスト段階の苦難が決まります。🌟
TDDは、開発者が行う単体テストをより明確に測定できるように、単位モジュールごとにテストコードを作成することを基本としています。こうすることでテストコードを再利用することができ、テストコードのカバレッジを測定して単体テストのレベルを定量的に確認することも可能です。では、すべてのモジュールにテストコードを作成するだけでアプリケーションの品質は向上するのでしょうか？MSが提案するTDDを使用したプロジェクトとそうでないプロジェクトの出荷後のバグ発生率を見ると、確かに効果があるように見えます。しかし、ここで重要なのは、単なるテストコードのカバレッジではなく、どのようにTDDをそのアプリケーションに適用したかということです。この部分に関する話は、テスト全体に拡張して考えてみることができます。
開発者でもビジネスユーザーでも、テストを適切に実行するために最も重要なのは、テストに関連するさまざまな技法ではなく、テストを行うべきシステム（が含むビジネス）に関する理解です。この話を開発者の単体テストに適用するなら、各ビジネスロジックをどのような構造で設計したかについての理解がまず必要であるということになります。
個人的には、テストを効率的に行うためには、一般化された方法論を適用するよりも、そのビジネスや開発されたシステムの構造に適したテストフレームワークを設計する方がより効果的だと思っています。特に業界のようにメンテナンス要員が限られている場合には、テストに絶対的なルールを適用するよりも、選択と集中で効率的に進める必要があります。TDDを適用する場合でも、開発を進めるのに20〜30％の工数が増加するため、メンテナンス運用に無条件に適用を強制するのも容易ではありません。固定要員の運用コストがそれだけ増加するのは負担が大きいからです。そのため、システムの構造やビジネスに応じて適切にテーラリングされた方法を考案するようになっています。実際、アプリケーションの性格によってはTDDの適用が難しい場合もかなりあります。特定のデータを定期的に変化させながら管理する必要があるシステムの場合、TDDを適用しようとすると、ベよりもコブが大きい場合が多いです。さらに、必要なデータが存在しない場合、テストコードを回すことができない場合もありますが、Industryのシステムはほとんどが管理システムであるため、TDDだけでなく一般的なテストでも常にそれに関連する悩みを抱えることになります。🤔
前述の通り、個人的にはビジネスユーザーレベルでのテストが何よりも重要だと思っているので、- 開発者の単体テストは基本として – この部分で少ない努力で大きな効果を得る方法に興味がある方です。効果を高めるためには必ず注意を払うべき2つのことがあります。1つは – 上でずっと話していた – 効果的なテストフレームワークの構成です。そしてもう1つは新しいことではない自動化です。🌈
関連するプロジェクトまたはメンテナンスに関連するテーラリングされたテストフレームワークを構成するためには、ビジネス全般に関する理解と過去の経験、そしてそれを処理するシステムのアーキテクチャおよびインターフェースされるシステムのメカニズムまでを考慮しなければなりません。この作業を通じて選択と集中を行うためのポイントを見つけ出し、この部分を最も効率的にテストできる方法を考案するのです。もちろん、すべてのシステムに適切なテスト方法論をビルドアップして適用することが必要だとは思っていません。思ったよりもビジネスがシンプルでエラーがなかなか発生しないシステムもあれば、使用頻度も低くビジネス的リスクも少ないシステムもありますから。Industryは一般的なIT関連ビジネス企業とは異なり、運用するシステムが一つや二つではありません。FacebookはFacebookアプリケーションだけをうまく運用すればいいのですが。しかし、Industryでもコアビジネスを扱うシステムの場合には、そのような作業を確実に行っておく必要があると考えています。どのみち、そのビジネスによって企業が永続することになるでしょうからね。🌟
テストフレームワークが定義されると、それに基づいて適切な自動化計画が作成されます。自動化はすべての企業が関心を持っている部分であり、すでにRPAや関連技術を活用したソリューションを使用した適用事例もかなり存在しています。しかし、テストのすべての部分をテストソリューションだけでカバーしようとすると、さまざまな壁にぶつかる場合があります。（特にデータベースと連携する必要があるテストの場合）このような場合には、その部分のテストのために特化されたテストアプリケーションを開発して相互に補完できるようにするのも良い方法です。例えば、生成されたPDFレポートの数値を検証する場合、RPAを使用するとデータベースを連携するのに多くの努力を要し、テスト時間も長くなることがあります。このような場合には、その機能にMVCモデルを確実に適用してUIコントロール部分にロジックがないようにデザインし、サービスレベルでデータを検証するアプリケーションを別に作成する方が効率的であることがあります。逆に、実際のUXおよびアプリケーション動作部分をテストする際にはRPAを使用する方がはるかに効果的です。私も10年ほど前にコアビジネス関連のシステムを効率的にメンテナンスするためにテストアプリケーションを自ら設計して開発したことがありますが、今でもうまく使用しています。🎉
最初に話を始めたときにテストのオーナーについて言及しましたが、開発の領域ではエラーが発生しないシステムを納品することが基本でしょう。提供されたシステムをビジネス側で検証しながらビジネスロジックや動作メカニズムについて開発者が間違って理解していた部分を発見し、修正していくことがビジネスユーザーのテストで行われるべきことだと思います。そのため、最終テスト作業のオーナーはビジネス側にありますが、その段階で行われるべきテストだけを進められるように開発者は開発の品質を確実に確保しなければなりません。🌟
やはりどんなにテストフレームワークがうまく定義されていても、開発がうまくできていなければ道のりは遠いということですね。🚀
