レガシーアプリケーションの自動回帰テストを書くのは、いつでも非常に困難なタスクだ。どこから始めるのか、どのくらい自動化するのか、自動化の最良の戦略の決め方は何かなど様々な疑問がある。
アジャイルソフトウェアテストグループにおいてMark Levison氏が始めたスレッドに応えて、Hubert Matthews氏はリスクをベースにしたアプローチを推薦すると述べた。
全てをテストすることは決してできません。だから、時間とお金を費やしたいところを選択しなければなりません。私にとってテストは主に情報とリスクであり、網羅率や完全性ではありません。
Hubert氏は、注目すべき分野の評価を手助けする質問について言及した。以下に、提案した質問の一部を示す。
- 現在、顧客が最低の品質を経験しているところはどこか?
- 機能の主要な分野は何か (例えば、何によってお金をもうけているか)?
- 顧客はより良い品質よりも、より多くの機能を好むだろうか?
- システムにとって、最大のリスクは何か?
- 顧客がある1つのことを改善できるとしたら、それは何か?
- 予備的な手動テストは、より重要な不具合を見つけられるか?
Rakesh Patel氏が同様のアプローチを提案し、以下のように述べた。
- アプリの中で最も重要なパスだけGUIを通して自動化します。多くのアプリは80%のケースで使われるいくつかの共通のパスがあります。この部分が動かなければ、ビジネスは困った状態になります!!
- GUIを使わずに、ビジネスの機能をテストするためにバックエンドにまっすぐ進めるならば、そうしましょう。つまり、GUI特定の統合テストでは、フロントエンドからのデータがバックエンドに届くのを確認するのです。
Mark Fink氏の提案によると、レガシープロジェクトの自動化を始める前に、プロジェクトの全体像をつかみ、注意が必要な特定の部分を識別するのがよい。そして、さらに全体像をつかむのに役立つツールの一覧を提案した。 同様に、Nat氏は、重要な点は集中したい分野でエンドツーエンドのテストを構築することだと述べた。また、レガシーシステムにおいて手動テストがある場合、通常、それらのテストは十分に書かれているので、自動化では簡単に達成できる目標になることに言及した。
Ralph Bohnet氏とGerard Meszaros氏は、テスト駆動の移植について話し、出した結論の1つは、どのようなレガシーアプリケーションであっても、移植に成功しなければならない場合、最も重要なビジネスシナリオは自動化された回帰テストを持つことだ。
Lisa Crispin氏は、一気にレガシーアプリケーション全体を自動化する機会はほとんどないことに同意した。Lisa氏がうまくいったのは、様々な要素の組み合わせだった。以下に例を挙げよう。
- アプリの重要な分野の優先順位を決めるように顧客に頼む
- 各分野で手動回帰テストの手順を書く
- それらの分野でGUIのスモークテストを書くための時間を各スプリントで計画する
- CIフレームワークを用いて、少なくとも1日に1回はテストスイートを実行する
- 新しい開発はすべて、適切なテストがあるようにする
Lisa氏によると、このアプローチで8ヶ月という期間内にレガシーアプリケーションを適切に自動化できたそうだ。
このように、レガシーアプリケーション全体を自動回帰テストでカバーするのはかなりの要求と時間を必要とするかもしれない。提案されたアプローチは、ビジネスの重要な機能に適用される十分な範囲を構築し、次第にシステムの周りにハーネスを付けていくためのものだ。
InfoQの関連する記事を読もう:テストの無いアプリケーションをテストする