testing - 回帰テストと展開戦略

Question

展開戦略についてアドバイスをお願いします。開発チームが広範なフレームワークを作成し、多く（20〜30）のアプリケーションがそれを使用し、ビジネスが少なくとも30日ごとにアプリケーションの更新を希望する場合、最適な展開戦略は何ですか？

私が尋ねる理由は、アプリケーションの90％が変更されない場合、変更を毎月展開するアジャイルアプローチを使用することには多くの無駄（およびリスク）があるように思われるからです。これが意味するのは、フレームワークはその月の間に変更される可能性があり、いくつかのアプリケーションも変更される可能性があるということです。フレームワークが変更されたため、すべてのアプリケーションを回帰テストする必要があります。たとえば、1年の間に10個のアプリケーションがまったく変更されない場合、機能の変更やホットフィックスがない場合、それらの10個のアプリケーションは毎月回帰テストされます。ビジネスが毎月更新をローリングしているという理由だけで、それらをテストする必要がありました。

そして、それに伴うリスク...ミッションクリティカルなアプリケーションが展開され、テストに数週間かかり、複数の部門がテストする場合、このアプリケーションを常に回帰テストする必要があると予想するのは現実的ですか？

1つのオプションは、フレームワークの更新に下位互換性を持たせることです。これは、アプリケーションがコードを変更する必要がないことを意味しますが、基盤となるフレームワークが変更されたため、アプリケーションをテストする必要があります。そして、それに伴うリスクは大きいです。絶えず変化するフレームワーク（およびこのフレームワークの展開）は、ミッションクリティカルなアプリが同じコードベースを長期間楽しむことができないことを意味します。

これらのアプリケーションは同じデータベースを共有するため、継続的なテストが必要です。私はTDDと自動テストを知っていますが、現時点では存在しません。

何かアドバイス？

Answer 1

フレームワークの背後にある考え方は、それが「動きの遅いコード」であるべきだということです。フレームワークがサポートするアプリケーションほど頻繁にフレームワークを変更するべきではありません。フレームワークをより遅い開発サイクルで取得してみてください。おそらく、リリースの頻度は 3 か月または 6 か月に 1 回程度です。

私の推測では、あなたはまだこのフレームワークのアーキテクチャ上の決定事項のいくつかを検討していると思われます。フレームワークの変更が本当に動的である必要があると思われる場合は、フレームワークのどの部分が頻繁に変更されているかを調べ、それらを必要とするアプリケーションにリファクタリングしてみてください。

アジャイルとは、すべてを無制限に変更することを意味する必要はありません。アーキテクトは、フレームワークを構成するものに境界を設定し、人々がアプリケーションのショートカットと思われるもののために簡単に微調整するのを防ぐことができます. 落ち着くまでに数回の反復が必要になる場合がありますが、その後はより安定するはずです。

Answer 2

（ユニット）テストカバレッジがない限り、これをアジャイルアプローチとは呼びません。アジャイルの重要な信条の1つは、頻繁なリファクタリングと新機能開発のためのセーフティネットを提供する堅牢な単体テストがあることです。シナリオには多くのリスクがあります。1）ほとんどのアプリケーションがユーザーに新しいビジネス価値を追加しない場合、月に20〜30のアプリケーションを展開します。2）私の本では良い考えとは言えないテストが実施されていません。そして、私はアジャイルを強く信じています。しかし、便利な部分だけを選んで選ぶことはできません。

ビジネスアプリケーションが変更されていない場合は、新しいフレームワークでコンパイルするためだけにリリースすることはありません。フレームワークが変更されるたびに再リリースする必要があるすべての.NETアプリケーションを想像してみてください。あなたの質問を読んで、私は共通のデータベースがこれの必要性を推進しているのだろうかと思います。フレームワークがスキーマを分離していて、スキーマが変更されるたびにアプリを再構築する必要がある場合は、最初にその問題に取り組む必要があります。いくつかのヒントについては、ScottAmblerによるRefactoringDatabasesを確認してください。

余談ですが、統合テストと単体テストには大きな違いがあります。回帰テストは統合テストです。そのレベルで自動化することは非常に困難です。テストで起こっているブレークスルーは、コードベースのユニットテストをますます可能にする高度にテスト可能なコードを書くことに関するものだと思います。

Answer 3

回帰テストは生き方です。リリースする前に、すべてのアプリケーションを回帰テストする必要があります。ただし、時間とお金は通常無限ではないため、最も変更が多い領域にテストを集中させる必要があります。これらの領域を識別するための迅速で汚い方法は、特定のビジネス領域で変更されたコードの行を数えることです。「アカウンティング」または「ユーザー管理」と言います。それらは、「ミッションクリティカル」と特定した領域とともに、最初に最も多くのテストを取得する必要があります。

今では、変更されたコード行が必ずしも変更を測定するための最良の方法ではないことがわかりました。変更要求が明確に定義されている場合は、変更要求の数と複雑さを調べて、これらのホットスポットを評価することをお勧めします。しかし、誰もがその贅沢を持っているわけではありません。

フレームワークに変更を加えることについて話しているときは、おそらくそれを使用するすべてのコードをテストする必要はありません。DALのようなものへの変更について話している場合、それは基本的にすべてに相当します。変更が確実であることが合理的に快適になるように、コードの十分な大きさのサンプルをテストする必要があります。繰り返しになりますが、「ミッションクリティカル」な領域と最も影響の大きい領域から始めます。

プロジェクトを3つの異なるコードストリームに分割すると便利だと思います。開発、QA、および生産。開発はすべての変更に対してオープンであり、QAは機能がロックされ、本番はコードがロックされます（とにかくロックされます）。月次サイクルで本番環境にリリースする場合は、リリースの少なくとも1か月前に開発コードからQAビルドを分岐することをお勧めします。次に、その月の受け入れを新しい変更のテストに費やし、回帰テストを他のすべての方法でテストします。アプリをステージングしてインストールを数回ドライランできるように、リリースの約1週間前に変更のテストを完了する必要があります。すべてを回帰テストすることはできないので、本番環境にパッチをリリースするための戦略を用意してください。ドン'

回帰テストを自動化することは本当に素晴らしいことです。理論的には。実際には、テストスクリプトを手動で実行するよりも、テストコードの更新に多くの時間を費やすことになります。さらに、1人の本当に優れたテストスクリプト開発者の価格で、2〜3匹のテストサルを雇うことができます。悲しいですが本当。

Answer 4

1. フレームワークを独立した部分に分割し、1 つの部分を変更するためにテスト ケースのごく一部を実行するだけで済むようにします。2. テスト ケースの優先順位付け手法を採用します。つまり、何らかの戦略で選択されたアプリケーションのテスト プールのごく一部のみを再実行します。追加のブランチと ART は、通常、他のブランチよりも優れたパフォーマンスを発揮します。各テスト ケースのブランチ カバレッジ情報を知る必要があります。3. フレームワークの更新頻度を減らします。アプリケーションを変更する必要がない場合は、変更しなくても問題ないことを意味します。したがって、これらのアプリケーションが古いバージョンのフレームワークを使用しても問題ないと思います。これらのアプリケーションのフレームワークは、たとえば 3 か月ごとに更新できます。