「何を」「どのように」テストするのか？――アジャイル開発におけるテストの基本戦略：アジャイル開発における品質管理（2）

少人数、短期間の開発を繰り返すアジャイル開発では、どのようにすれば品質を保つことができるのだろうか。本連載では、アジャイル開発における品質管理の手法を解説する。初回は、アジャイルテストの基本的な考え方と戦略について、2回に分けて解説する。後編となる今回は、アジャイル開発における品質に関してどうアプローチするかの戦略について。

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

　アジャイル開発におけるテストは、どのように進めていけばよいのでしょうか。ただ単に、「開発期間を短く回せばよい」「リリース直前に後回しにした作業をこなせばよい」といった場当たり的な対応をしてしまうと、大きな失敗につながります。前編に引き続き後編となる今回は、アジャイル開発では品質に関してどのようにアプローチするのかを解説していきます。

ソフトウェア品質モデルを使って「何を」テストするのかを考える

　テストのアプローチとして、まず「何を」テストする必要があるのかを考えます。言い換えると、テストをすることによって何ができていればOKか、つまりリリースに足る品質と言えるのか、ということです。これは開発プロジェクトを開始する前に、あらかじめ想定しておく必要があります。なぜなら、品質が不足している場合も問題ですが、過剰に品質を追い求めてしまうこともまた問題だからです。私たちはビジネスとしてソフトウェアを開発し、そしてテストしています。求められている以上の品質にするために余計なコストをかけてしまわないようにする必要があります。

　例を挙げると、1年に1度しか使わないようなシステムを、24時間365日フル稼働できるようにする必要はありません。これは極端ですが、ソフトウェアには絶対に満たしておかなければならない品質のラインと、ユーザーがそこまでは求めていない過剰な品質のラインの2つがあります。それを適切に見定めるために、そしてきちんと範囲内に収まっているかどうかを確かめるために、ここでは、まずどのような要素があるのかを整理します。

　「品質の良い」ソフトウェアとは何か、それを整理した国際標準が幾つかあります。代表的なものが「ISO/IEC 25010 ソフトウェア品質モデル」です。この標準は、SQuaREと呼ばれるソフトウェアの品質に関する規格群の一つで、ソフトウェア開発における品質の要素を表しています。この要素のことを品質特性と言い、「機能適合性」「信頼性」「使用性」「資源効率性」「保守性」「移植性」「セキュリティ」「互換性」の8つに分類されます。つまり、これらの特性それぞれに対して必要なレベルを達成していれば、要求される品質を達成している、と言ってもいいでしょう。

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

　非常にシンプルで分かりやすい規格だと思いますが、それらを全てきちんと求められるレベルで充足するためには、いつ、どこで、誰が、どのようにアプローチするのかを整理して実行する必要があります。もちろんこれはアジャイル開発であっても、そうでなくても必要となる考え方です。

　基本的に、スプリントの中で実施する開発およびテストは、機能的な面に対してのものとなり、それ以外の面については別の形での整理が必要となります。つまり、品質モデルで言うところの機能適合性は個々の機能に対してスプリント内で考慮し、それ以外は別の枠組みで検討するということです。検討する、と書いたのは結果としてスプリント内でタスクを実施することになる場合もあるからです。ここは少し分かりにくい部分ですので、次の項目で詳しく解説します。

「どのように」テストするのか、アジャイルテストを進めるための2つの視点

　前述した通り、アジャイル開発におけるテストは、下図の2つに分けて考える必要があります。これを示した図がQA to AQの中で紹介されています。この図は、スクラムでの開発を進めるに当たっての要素を示しています。下段中央辺りの「Plan a Sprint」「Run a Sprint」の部分がスクラムチームによる開発を表しています。その左側にある「Backlog」と呼ばれる実装すべき機能などの一覧から優先順位の高い方を実装していきます。そして、図中で示した2カ所において、テストの考慮が必要となります。

スクラムにおける品質（出典：QA to AQ: Patterns about transitioning from Quality Assurance to Agile Quality、赤枠内は筆者加筆）

　まず、（1）のスプリント内のテストは個々の機能の実装において必要なテストです。スプリント実行中に実施するのが基本となります。

　そして、（2）のプロダクト全体を考慮するテストは、前回解説した、スプリントに収まりきらない部分のテストです。ちなみにその右隣の「Functional Acceptance Testing（機能受入テスト）」も重要ではありますが、基本的には（1）の延長上にあるものなので、ここでは詳述しません。

　アジャイル開発を進めるに当たっては、「個々の機能について、品質目標をクリアするためにどのようなテストを行うのか」という視点と、「製品をリリースするために必要な項目をどのようにテストしていくのか」という視点が必要となります。どの時点でどのように実施するのかという点については、実は模範解答はありません。その時点でのアジャイルチームの成熟度やソフトウェアの特性によってとるべき戦略はさまざまです。ここでは、どのような要素があるのかを整理し、例としてどのように分けていくのかを紹介します。

　まず、どのようなテストが必要になるのか、ということですが、これは「アジャイルテストの4象限」というよく知られている考え方を元に紹介していきます。

（出典：テスターとアジャイルチームのための実践ガイド 実践アジャイルテスト／翔泳社）

　この図は、アジャイル開発においてどのようなテストが必要か、そしてどのようにアプローチするのが適しているのかを示しています。

　例えば第1象限（左下）に当てはまるテストは、チームの開発を支援する、つまりスプリント内で実施するテストとなります。それも開発者の視点に立って「ちゃんと仕様通り作られているのか」という技術寄りの部分をテストします。第2象限（左上）も同様にスプリント内でのテストとなりますが、どちらかというとユーザー視点に立ったテスト、つまりその機能がどのようにユーザーに使われるのか、価値があるのかを確かめるテストといえます。

　そして、第3、第4象限（右上、右下）はシステム全体を考慮するテストとなります。第3象限はシステムがどのように動作し、ユーザーにどのような価値を提供するのかを確かめるテストです。これは手動での実施が必要となり、アジャイル開発での取り扱いには注意が必要です。また、第4象限のテストは技術的な側面を持っていますが、システム全体で実施すべきテストであり、これも計画的に開発の中に取り入れる必要があります。

　前編で解説したバーンスプリントの例では、右側（第3、第4象限）のテストについて、リリース間際に実施することにしていました。そうすることによってかえって生産性を下げてしまったり、品質に問題を抱えたりしてしまいます。従って、これらの部分については実施できるようになった段階で、可能な限りすぐにテストし品質を確かめる必要があります。まとめて実施するのではなく項目ごとに早めに実施しましょう。

「完成の定義」を検討、把握する

　スクラムではスプリントの中でどこまで実施するのかを「完成の定義（Definition of DONE）」という形でコントロールしていきます。完成の定義とはまさしく、「何ができればOKなのか」を決めておくことです。つまり、各機能が「完成」するとはどのようなことを示すのか、スプリントの中でどこまで実施すれば「完成」なのかを定義します。逆に言うと、リリースまでに実施しなければならないことで、かつスプリント内で実施できないものも一緒に決めておくということになります。これを「UNDONE」の項目などと言います。それらの項目をどのように実施するのかもリリース計画を立てる際に検討しておきましょう。

DONEの定義とUNDONEの例

　そして、「UNDONE」の項目は可能な限り早期に実施することが求められます。さらにUNDONEの項目を1つでもDONE側に移動させる、つまりスプリント内で項目を実施し完了させることこそが、スクラムにおける生産性の向上である、と言われています。もちろん、やみくもにスプリント内に取り入れたところで破綻するだけですので、慎重に行う必要があります。簡単なことではありませんが、プロセスを改善し、作業を工夫し、チームメンバーのスキルを向上させ、生産性の高いチームを作り上げることを目指すために日々の改善を続ける、アジャイルで開発を続けることの重要なポイントとも言えます。

　大切なのは、品質に関する問題をできるだけ早期に発見し、対処することです。そうすることで結果として技術的負債の「利子」が蓄積するのを防ぎ、コストを抑えて品質を上げることができます。

　ここまでをまとめると、アジャイル開発のテストには、イテレーション内で実施すべきものと、そうでないものがあります。そしてそうでないものはタスクとしてイテレーションに取り込まなければならない場合もあります。それを後回しにしてしまうとバーンスプリントになってしまいますので、項目を洗い出し、早めに着手することが肝要です。また、そういったテストを別のチームやタイミングで実施するというのも一つの方策です。そして、イテレーション内で行わないもの（UNDONE）について、イテレーション内でできるように改善を繰り返していくことも、品質を保ちつつ生産性を向上させるという点では大切な方針となります。

実際のアジャイル開発プロジェクトの改善事例

　ここでは、弊社で推進したアジャイル開発プロジェクトの改善事例を通じて、前述の考え方をどのように現場で適用したのか解説します。

　そのプロジェクトでは大規模スクラムでの開発が行われていました。幾つかのスクラムチームが並行して開発を進めているような状況です。実は、アジャイル開発においてチーム間のコラボレーションというのはかなり重要な要素です。スクラムにおいてもLeSS（Large Scale Scrum）やSUCRUM of SUCRUMSなどいろいろな手法が生み出されています。そのような複数のチームでの開発には全体を見通した品質戦略が欠かせません。

　しかし、この時はチームが独立して開発を進めていたため、イテレーション内のテストを個別に推進していましたが、チーム間の開発プロダクト結合テストなどの、イテレーション外のスコープのテストについては方針を立てないまま進めていました。その結果、重要な機能での考慮漏れが発生し、β版のリリース直前に致命的な不具合が判明しました。その不具合は、他の機能との連携に関わる部分のもので、不具合が発生した機能だけではなく、周辺部分のさまざまな機能に対して修正が必要となる、全体への影響度が極めて高い不具合でした。

　そこで、正式リリースに向けて、弊社の品質担当者がプロジェクトに携わりました。前述した品質特性を使いプロダクト全体の品質目標を整理し、そこで分析したテストの要件に対してどのようにアプローチするのか、テスト戦略を立案しました。複数の機能間の連携が極めて多層的になっていたため、その部分を誰が、どのようにテストするかを明確にすることが、特にこのプロジェクトでは重要でした。幸い、個々の機能についてはほぼ目標をクリアする形で品質が確保できていたため、機能単位で段階的に結合テストを行うことでインタフェースの不整合を整理することができました。その際、品質担当者が複数のチームと調整し、テスト実施と不具合の修正を併せて実施することを提案し、推進しました。

　そのような形でプロダクト全体の品質向上施策を進めた結果、正式リリース前のシステムテストでは大きな不具合が検知されることなく、無事リリースにこぎ着けることができました。より具体的なテスト戦略については、次回以降解説します。

　ここまで、アジャイルテストの基本的な考え方と戦略について解説してきました。ウオーターフォール型開発とベースになる部分は共通することも多い一方で、アジャイル開発ならではの注意点についても紹介しました。この内容がアジャイル開発での品質向上の一助となれば幸いです。

　次回は、イテレーション内でのテストを効率化する方法について解説します。

参考文献

• Joseph Yoder, Rebecca Wirfs-Brock, Ademar Aguilar, “QA to AQ: Patterns about transitioning from Quality Assurance to Agile Quality,” 3rd Asian onference on Patterns of Programming Languages (AsianPLoP 2014), Tokyo, Japan, 2014.
• テスターとアジャイルチームのための実践ガイド 実践アジャイルテスト／翔泳社／リサ・クリスピン、ジャネット・グレゴリー 著／榊原彰 監訳・訳／2009

筆者紹介

江添 智之

バルテス株式会社

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

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

畠田 健一朗

バルテス株式会社

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

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