アジャイルで開発したシステムをいざテスト→全然使えない！ を防ぐ、テストの考え方総まとめ：アジャイル開発における品質管理（5）

少人数、短期間の開発を繰り返すアジャイル開発では、どのようにすれば品質を保つことができるのだろうか。本連載では、アジャイル開発における品質管理の手法を解説する。第5回は、システム全体の品質を担保しつつ、想定したリリース時期を守るためのポイントについて。

[江添智之, 畠田健一朗，バルテス株式会社]

　アジャイル開発は「市場リリースのタイミングをいつにするか」を決めづらい開発手法です。基本的にはリリース計画を事前に立てて、リリース時期や、それまでに実装すべきフィーチャー（機能要件）をある程度定めて進めていくことになります。しかし、アジャイル開発の特性上、実装すべきフィーチャーをいつ実装するのかは流動的です。実装内容や順番をイテレーションごとに柔軟に再検討できるのがアジャイル開発の強みではありますが、裏を返せば確固たる基準が定めにくいということでもあります。

　理想は「最適な時期に、必要なフィーチャーがそろったタイミングでリリースする」ことです。リリース時期が早過ぎると、必要な機能が十分に実装されていなかったり、品質が低かったりして、リリース後にトラブルが生じてしまいます。かといって、機能や品質を盛り込み過ぎてリリースが遅くなってしまうのもよくありません。

リリースタイミングの考え方（出典：ソフトウェア・テストPRESS Vol.1／技術評論社　※出典内の図を元に作成）

　実際には、広報活動や環境準備などの開発以外の計画との兼ね合いでリリース時期があらかじめ決まっていることが多いでしょう。リリース時期を固定するとそこまでに必要な機能面の実装が優先されてしまいがちです。つまり、非機能要件の検証や全体のブラッシュアップといった作業が後回しになります。第1回でも説明しましたが、必要な作業は後回しにすればするほど「技術的負債」が蓄積され、オーバーヘッドが発生します。

　今回はシステム全体の品質を担保しつつ、想定したリリース時期を守るために心掛けるポイントを紹介します。

「アジャイルテストの4象限」から見る、プロダクト全体を考慮したテスト

　「非機能面の検証や全体のブラッシュアップ」にあたるテストが何か、整理していきましょう。第2回でも紹介しましたが、「アジャイルテストの4象限」の第3、第4象限（右上、右下）がそれに当たります。

アジャイルテストの4象限（出典：テスターとアジャイルチームのための実践ガイド 実践アジャイルテスト／翔泳社　より一部修正）

　第3象限の部分には、システムの一貫した操作を確認するシナリオテストや、ユーザビリティテストなどが該当します。「一貫した操作になっているか」「使いやすいか」といった妥当性確認の観点は、テストの自動化が難しい部分です。効率的なテストのために、第4回で紹介した探索的テストを導入すると有効ですが、探索的テストのみで全てをカバーすることは難しいでしょう。なぜなら、シナリオテストの場合、業務フローなどから網羅的にシナリオを整理することが必要で、それを探索的テストでやろうとするとかえって非効率だったり、パターン漏れなどが発生したりするからです。つまり、これらの部分については適切なテスト設計と手動によるテストの実施が必要となります。

　第4象限の部分には、性能テストやセキュリティテスト、保守性、移植性、信頼性などの「〜性」テストが該当します。第2回で紹介した「ISO/IEC 25010 ソフトウェア品質モデル」の「機能適合性」「使用性」以外の品質特性が当てはまります。これらについても、個々の機能ではなくシステム全体で考慮する必要があります。テストには専用のツールや専門の知識を持ったエンジニアが必要となることが多く、イテレーション内でのテストが難しい部分でもあります。

ISO/IEC 25010 製品品質モデルにおける品質特性

　ここで1つ注意すべきことがあります。これらの非機能特性についてのテストはシステム全体で実施する必要がありますが、設計や実装の段階から考慮する必要があります。例えば、性能や負荷耐性などはシステムのアーキテクチャや使用するハードウェア、ミドルウェアなどに影響される部分が多いため、全体が出来上がってテストを行い、性能面で実用に耐えるものではなかった、という場合に受けるインパクトは膨大になります。最悪の場合システム構成から考え直し、ということにもつながりかねないため、非機能特性の品質目標は早い段階で明確にして、それらを意識してイテレーションを実施することが重要です。

　イテレーションやアジャイルチームをまたいだ機能間連携のテストなども、実施のタイミングに気を付ける必要があります。こちらは機能の検証なので期待値が明確になります。そのため、テストはやりやすそうに見えます。しかし、チーム間のプロダクトを連携させる場合はそれぞれのプロダクトを更新し続けているため、前のイテレーションでOKだったとしてもすぐにNGとなる場合があります。きちんと戦略を立てないと、いつの間にか連携が取れなくなりリリース間際に大幅な修正が必要となるでしょう。

チーム間の結合テストのタイミング

どのタイミングでテストを実施すべき？