（この記事は、開発元Parasoft社 Blog 「Put the Agility Back into Agile Development with Change-Based Testing」2017年11月15日の翻訳記事です。）
アジャイル開発の誰にも言えない秘密
アジャイルは、より速く市場に投入するための方法という誤った触れ込みで経営上層部に売り込まれることが多々ありますが、本当の目的は、市場へのより正確なデリバリーです。誰もあえて口にしない秘密は、正確なデリバリーを実現するには、実はコストかかるということです……つまり、市場投入までの時間が遅くなるのです！そうです、より頻繁に（すなわち、より早く）リリースすると、最終的には、完全な機能を市場に出すまでの時間は長くなります。問題をより小さなピースに分割しているだけなのに、なぜ余計に時間がかかるのでしょうか？それは……一番の原因は、欠陥が遅い段階で検出されることと、リスク低減のための対策がもたらすボトルネックのせいです。
アジャイル開発は「速さ」を期待させますが、少しずつ重なるコード変更、具体的には変更がテストやシステム全体の安定性に与える影響によって、その速度は大幅に減速されます。QA /テストは実装された新しい機能の検証に集中するため、スプリントの最後はいつも、ゴールラインに駆け込むように終わります。そして、コード変更の間接的な影響が分からないため、リリースが近づくと、完全な回帰テストを行わなければなりません。そのため、サイクルの終わりのほうで多数の問題が見つかり、残業と難しいビジネス上の決定を強いられます。
もっと良い方法があるはずです！
リスクにフォーカスする
今日のコードベースは複雑であるため、どんなに害のなさそうなコードの変更でも、アプリケーションの安定性に微妙な影響を与え、最終的にはシステムを破壊する可能性があります。このような意図しない結果は、目視による検査では発見できないため、リスクを軽減するためにはテストが重要ですが、再テストする必要があるものを判別できない限り、効率的なテストを行うことはできません。スプリントごとにあまりに過剰にテストしている場合、アジャイル開発によって得た利益の大半が失われてしまいます。反対にテストが少なすぎる場合、サイクルの終わりのほうで問題が見つかる危険性があります。
必要なのは、どのテストを再実行する必要があるかを特定し、直近の変更の影響を受ける機能や関連するコードの検証にテスト作業（単体テスト、自動機能テスト、および手動テスト）を集中させる方法です。Parasoftのコード解析エンジン（Jtest、C / C ++test、dotTEST）とParasoft DTPのProcess Intellligence Engine（PIE）を組み合わせて利用すると、開発者やテスターはビルドごとのコードの変更を把握し、アジャイルの約束するメリットを実現できます。この方法は、 変更ベースのテストと呼ばれます。
スプリントの進行を妨げない変更ベースのテスト（Change-Based Testing : CBT）
重要な鍵は、コードの変更を検証するのにどのテストが利用できるかを知ることであり、それにはParasoftの関連付けされたカバレッジが役に立ちます。DTPの分析エンジン（PIE）は、どのファイルが変更されたか、およびどのテストがそれらのファイルにアクセスしたかを把握することで、2つのビルド間の差分を分析し、再実行が必要なテストのサブセットを特定できます。下の画像は、CBT分析の結果を円グラフで表すDTPダッシュボードのウィジェットを示しています。このグラフには、コード変更を検証するために使用できるテストのサブセットが表示されています。テストは、ステータス（合格、不合格、未完了、再テストが必要）によって分類されています。
この上位レベルのビューは、コードの変更によって失敗したテストがあるほか、まだ実行されていないが変更をさらに検証するために使用できるテストがあることを示しています。
合格 、不合格、または 未完了 のステータスは、これらのテストが、完全に自動化されたテストプロセスの一部として（継続的インテグレーションのビルドステップとして）、または新しい機能をテストした際に、既に実行済みであることを示します。いっぽう、 再テストのステータスを持つテストは、まだ実行されていない手動テストか、現在のスプリント中に実行がスケジュールされていない自動実行テストです。
この円グラフを深く掘り下げていくことで、コード内のどこで変更が発生したか、既存のテストとそれらの変更がどのように関係しているか、テストリソースを集中させるべき場所はどこかをすぐに把握できます。
ここの情報から、テストプランを作成し、失敗したテストケースと未完了のテストケースに最優先で対処し、推奨された再テストの候補を参考にして、追加の自動実行をスケジューリングする範囲を限定し、手動によるテスト作業に優先順位を付けることができます。
DTPの違反エクスプローラーは、テストプランを定義および管理するためのインターフェイスになります。テストおよび結果をたどっていくと、各テストケースの詳細が表示されます。優先順位 ビューを 使用し てテストメタデータを設定すると、ユーザーは各テストケースにオーナー、アクション、および優先順位を割り当てることができます。
CBTワークフローを適用する方法
ところで、これはアジャイルプロセスにどのように役立つのでしょう？簡単に言えば、テストリソースをどこに適用すべきかを素早く簡潔に特定できるということです。本当に必要なものだけをテストすることで、テスト時間を大幅に短縮できます。品質は向上し、スプリントは計画どおりに完了します。
具体的には、どう活用すればよいのでしょうか？変更ベースのテスト（CBT）分析の結果を活用する方法はいくつかありますが、以下のワークフローは、スプリントベースのテスト作業の範囲を絞るのに最も実用的ではないかと思います。
- ベースラインを特定する。これは、範囲を絞った再テストに使用する予定のテストが完了しているビルドです。通常、前のスプリントまたはリリースの終了時点のビルドです。
- 単体テストと利用可能な自動機能テストを実行する。 自動テストをCIプロセスに統合し、最新のビルドに対するCBTの結果を測定/監視します。これにより、作業の進捗を確認し、再テストの作業を計画することができます。
- 再テストのギャップを埋める。 ターゲットビルドに対してテストし、再テストの結果を分析のために送信します。 CBTの結果を再検討します。
- ベースラインをリセットする。 スプリントの終わりに、テストを終了したビルドにベースラインを移動し、次のスプリントのためにリセット/リピートします。
まとめ：
アジャイル開発では、テストの生産性を高める必要があります。テストが継続的デリバリーの大きなボトルネックになるのは、テストの方法が誤っているせいで、リリースサイクルの終わりになって膨大な欠陥が検出されるためです。最良の結果を得るには、変更の影響をテストすることに集中し、アジャイルの妨げを取り除き市場投入を加速します。
