アジャイルで開発したシステムをいざテスト→全然使えない！ を防ぐ、テストの考え方総まとめ：アジャイル開発における品質管理（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となる場合があります。きちんと戦略を立てないと、いつの間にか連携が取れなくなりリリース間際に大幅な修正が必要となるでしょう。

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

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

　ここまで、システム全体を考慮する必要のあるテストの観点を整理しました。これらをどのタイミングで実施するかを検討する前に、イテレーション内で実施できるものについては「DONEの定義」に含めて実行することが重要です。例えば、ソースコードの静的解析や脆弱（ぜいじゃく）性検査、性能検証などについてはイテレーションごとにツールで確認すべきです。ただし前述の通り、セキュリティや性能テストとしてはそれだけで十分とはいえないため、脆弱性検証やシステム全体の性能検証については手動での確認も別途スケジュールを立てる必要があります。

　実施するタイミングには2つの考え方があります。

1. イテレーションで実施するバックログアイテムとして設定し、テスト実施および対応するタスクをこなす
2. イテレーションのサイクルとは別のスケジュールや別のチームで実行する

　それぞれ順に見ていきましょう。

1.イテレーションで実施するバックログアイテムとして設定する

　通常のフィーチャーを実装するのと同じように、プロダクトバックログに対してアイテムとして設定し、ストーリーポイントを見積もり、イテレーション内で実施する方法です。例えば「（システム全体の）シナリオテスト」のようにバックログアイテムを設定します。それに対して受け入れ条件を設定し、ゴールを明確にすることも通常のバックログアイテムと同様に重要ですし、それがイテレーションに収まりきらないくらいに大きなサイズであれば、適切に分割することも同様です。プロダクトのサイズにもよりますが「シナリオテスト」のようなアイテムは分割の必要があるでしょう。

　冒頭で説明した通り、これらのタスクは優先度が低く見積もられがちでリリース前に実施されるケースが多く見受けられます。また、開発を進めていくにつれて当初は想定していなかったタスクとして追加されることもあるかもしれません。技術的負債とならないうちに、必要な作業を実行可能な段階でこなすこともポイントです。

　とはいえ、どのプロダクトバックログの中で、どの程度の優先度でタスクを実施すべきか、特にフィーチャーに関するものと混在する場合にどのように考えればよいのか、難しい部分でもあります。

　このときに使える考え方に「リスクベースドテスト」というものがあります。リスクベースドテスト自体はアジャイルの考え方というわけではなく、一般的なテスト戦略として使われているものですが、優先度の高いものからタスクを実施していくアジャイル開発との親和性は高いものとなります。リスクベースドテストでは、プロダクトにおけるリスクを洗い出し、リスクアイテムとして選別します。

　例えば、脆弱性などは分かりやすいリスクでしょう。そして、そのリスクに対して「発生したときの影響度」と「発生する確率」をそれぞれ見積もります。見積もり方法には幾つかありますが、シンプルに「高、中、低」の3段階で分けるのがアジャイル開発には向いています。それらの数値を考慮して、優先度の高い方から対応していく、というのがリスクベースドテストの考え方です。フィーチャーに関するものとの比較については「そのフィーチャーを実装しないでリリースする」という場合のリスクという観点で比較すればよいでしょう。

2.イテレーションのサイクルと別のチームで実行する

　いったんイテレーションでの実施から切り離し、別のスケジュールを立てたり、別チームで実行したりするという形式です。こちらに関しては、アジャイル開発のやり方から外れてしまっていると感じる方もいるかもしれません。

　もちろん、全てのタスクをイテレーション内で収めることがアジャイル開発の理想ではあります。しかし、現実的には期間やスキルの関係で全てを収めることは難しいこともあるでしょう。そのときに「リリースまでに何をすべきか」を押さえて実行していくことも必要となります。あくまで開発はチーム中心アプローチであることを原則として、現実的な開発ステップを経ることこそがアジャイル開発の本質といえるでしょう。

　テストの主体が開発ベンダーではなくユーザー企業となるUAT（ユーザー受け入れテスト）や、仮リリースした後に発生したインシデントに対応するα／βテストなどもこちらのタイプとなります。迅速に対応することが迫られるため、場合によっては「UAT対応期間は依頼された修正タスクに迅速に対応する」など、通常のイテレーションのサイクルとは違ったやり方が必要となるでしょう。

アジャイルテストを適切に実施する――バルテスの事例

　最後に弊社で実施している、アジャイル開発チームへのシステムテスト支援の事例を紹介します。ここでは、バルテスはテストベンダーとしてプロジェクトに参画しています。

　このプロジェクトではWeb上でのサービスを提供しており、複数のスクラムチームによって開発が進められています。サービスは頻繁にリリースが行われていますが、文言の変更などの小規模な内容から、キャンペーン企画に伴う改修など大規模なリリースもあります。こういった状況では、システムテストの作業ボリュームが時期によって変動するため、柔軟なテスト体制を整えることが必要となります。

　そこで、バルテスのテストチームの体制を2つに分けて構築しました。まず、開発チームと同フロアに少人数のオンサイトのテストチームを配置し、小規模な案件はそちらのチームのみで対応します。そして、中〜大規模な内容であれば、弊社のテストルームにいるオフサイトのテストチームとともにテストを実施するという体制です。

　オンサイトチームは開発チームと密に連携し、案件規模を見積もり、必要に応じてオフサイトチームへと業務を割り振ります。オフサイトチームは、コアメンバー数名と案件規模によって増員するメンバーで構成されており、流動的な作業ボリュームに対して柔軟に対応します。これにより、開発チームとの密接な連携が取りにくい、ノウハウの蓄積が困難、リリース規模に応じたリソースを確保しにくい、といったアジャイル開発における分散テストの問題点を解消することができます。

柔軟なアジャイルテストチームの構築

終わりに

　ここまで、アジャイルテストで一番難しい部分といっても過言ではない、システム全体を考慮するテストについてポイントを紹介しました。アジャイル開発においてもシステム開発である以上、品質を向上させるために必要な要素は従来の開発手法と大きく変わりません。アジャイルならではの工夫を凝らしつつ、高品質なシステムを作るためのプロセスを推し進めていきましょう。

参考文献

• ソフトウェア・テストPRESS Vol.1／技術評論社／2005
• テスターとアジャイルチームのための実践ガイド 実践アジャイルテスト／翔泳社／リサ・クリスピン、ジャネット・グレゴリー 著／榊原彰 監訳・訳／2009

筆者紹介

江添 智之

バルテス株式会社

クロス・ファンクショナル事業部 R&C部 マネージャー

Web系、エンタープライズ系、医療系などさまざまな開発業務にプログラマー、システムエンジニア、プロジェクトリーダーとして携わった後、バルテスにてテストエンジニア、コンサルタント業務に従事。現在は、主にテスト業務に関する研究開発および人材育成を担当。Scrum Alliance認定スクラムマスター、ディープラーニング検定（G資格）、ネットワークスペシャリスト、データベーススペシャリスト、JSTQB Advanced Level（テストマネージャ、テストアナリスト）など、ソフトウェアの開発およびテストに関する資格を多数取得。JaSST Kansai 実行委員。同社が運営するソフトウェア品質向上プラットフォーム「Qbook」の執筆を担当するなど、ソフトウェア開発に携わるエンジニアに対しての情報発信を積極的に行う。

畠田 健一朗

バルテス株式会社

エンタープライズ品質サービス事業部 東日本ソリューション部 リーダー

前職では大手ERPベンダーの新規事業製品開発でアジャイル品質保証、テストの自動化業務などに数年間従事。2018年よりバルテスに参画。入社後は、エンタープライズシステムを中心に、アジャイル開発をはじめとする複数プロジェクトの品質マネジメント推進を担当。江添氏と同様、同社運営の「Qbook」で執筆を担当している。