工数超過の要因、過剰なテストを避けよう 効率的に要件を作成する「V&V」という考え方とは：アジャイル開発における品質管理（3）

少人数、短期間の開発を繰り返すアジャイル開発では、どのようにすれば品質を保つことができるのだろうか。本連載では、アジャイル開発における品質管理の手法を解説する。今回は、スプリント内でのテストと品質保証について、2回に分けて解説する。前編となる今回は要件設定とV&Vについて。

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

　アジャイル開発において、テストをどのように実施するかは難しい問題です。短い開発周期で、設計、実装にしっかり時間をかけようとすると、それに伴ってテストを実施する時間は少なくなります。結果として、テストがスプリント（※）内で収まらず、テストのタスクを次のスプリントに持ち越してしまいます。結果として本来のタスクに着手できず、プロジェクトが停滞してしまうことも考えられます。

（※）アジャイル開発における、機能の設計、実装、テストまでの一連の流れを開発する単位のこと。詳しくは第1回で解説している。

　かといってテストや実装を短時間で済ませようとすると、技術的負債がたまり、先々のスプリントで大きな問題となることが容易に想像できます。今回は、このような負の連鎖を生み出さないようにするために、スプリント内でのテストと、品質保証の考え方について紹介します。

基本はスプリント内で完結、だがいきなり100点を目指さない

　前回、「完成の定義」という考え方を紹介しました。スプリント内でどこまでやれば完成と見なすのか、その達成条件のことです。もちろんテストについても、何を、どこまでやるかを完成の定義に含める必要があります。

　しかし、いきなり全てのテストをスプリント内で完結させることは困難かもしれません。どこまでテストを実施すればよいかの見極めが十分でなく、テストが不足し不具合が残存してしまったり、テストを過剰にやり過ぎることによる工数超過に陥ってしまったりする可能性があるからです。従って、最初はテストを次のスプリントに回す、という方針を取ることも十分に考えられます。

スプリントをまたぐテストからはじめる（出典：https://www.infoq.com/jp/news/2015/04/missing-test-competencies/　出典内の図を元に作成）

　突然、先述したことと真逆のことを言っているように感じるかもしれませんが、改善していくことを前提に、今できることをこなしていくことこそが、アジャイル開発に求められることです。アジャイル開発では、変化に対応することが求められます。それは、行き当たりばったりやなし崩しという意味ではありません。最終的なゴールを見据えて、短い期間で成果を確認しながら、細かく軌道修正しながら近づいていきます。それはテストや品質保証についても例外ではありません。いきなり100点満点の解答を目指そうとせず、できるところからこなしていくことが重要です。

　チームが良いと判断したならば、機能の実装とそのテストを複数のタスクに分け、複数のスプリントに分けて実施するというのも現実的なやり方だと思います。そして、それをコントロールするのが完成の定義です。

　このように改善を継続していくことがアジャイル開発の本質といっても過言ではありません。つまり、アジャイル開発にベストプラクティスは存在しないのです。それを意識することが最も重要です。その時点でできるだけのことを行い、またそれ以上を求めることを仕組みとして備えているのがアジャイル開発だといえるでしょう。

　もちろん、スプリント内で完結させることが基本であることに変わりはありません。そしてそれを実現するためには、第1回で解説した通り、ミニウオーターフォールにならないことが重要です。ここからは、その具体的な方針を解説していきます。

要件をユーザーストーリーとして分割し、ゴールから逆算する

　ここでは、実装すべきフィーチャー（機能要件）について考えていきましょう。アジャイル開発ではシステムのフィーチャーを「ユーザーストーリー」という形で整理することが一般的です。ユーザーストーリーとは、そのシステムを利用して、誰が、何のために、何をしたいのかを簡潔に表現したものです。

　ユーザーストーリーの形で整理すると同時に、そのユーザーストーリーについての「受け入れ条件」を考えます。受け入れ条件はその名の通り、そのユーザーストーリーがちゃんとできているかどうかを確かめるための条件のことです。1つのユーザーストーリーに対して、5個前後の受け入れ条件を定義しているとよいといわれています。

（出典：エッセンシャルスクラム　アジャイル開発にかかわるすべての人のための完全攻略ガイド／翔泳社　※出典元を参考に制作）

　そして、スプリントプランニング（スプリント開始時に行う、何をどのように実装していくかを検討するミーティング）で、実装の方針と同時に受け入れ条件を満たしていることを確認するためには何をすればよいか、すなわちテストの観点についても整理していきます。

　何をどうテストするのかという観点を整理できれば、テスト自動化用のスクリプトの作成や、手動で行うテストの設計などを実装の作業と並走させて実施できます。ユーザーストーリーの「何ができればOKか」を、チームメンバー全員の共通認識とすることで「作業の手待ち」を防止できます。

V＆Vの考え方を導入する

　受け入れ条件を定義して整理すると解説しましたが「受け入れ条件をどう考えればいいのか」という相談をよく受けます。これに関してはテストの考え方の一つである「V&V」をうまく使うことで、効率が良く漏れのない受け入れ条件を考えることができます。

　V&Vは、Verification（検証：以下、ベリフィケーション）とValidation（妥当性確認：以下、バリデーション）の頭文字をとったものです。ベリフィケーションとは、「仕様通りに作られているのか」という観点です。事前に定められた機能仕様が満たされているかを確認します。そしてバリデーションとは、「ユーザーの要求に合致しているか」という観点です。たとえ仕様通りにソフトウェアが作られていたとしても、それがユーザーの要求を満たしていないのであれば、品質が良いとはいえません。そのためにはどのような目的で使われるのか、どのようなシチュエーションかを把握しておく必要があります。

テストの2つの視点

　この2つの視点を合わせて確かめることが重要です。アジャイル開発ではフィーチャーのテストでV&Vをどのように活用するのかを見ていきましょう。

フィーチャー検証テストはテスト自動化がカギ

　まずは、ベリフィケーション、つまりフィーチャーが仕様通りにシステムが作られているかどうかを検証するテストです。こちらは、仕様が明確になっていれば受け入れ条件を考えるのもそれほど難しくないでしょう。そして、テスト実施の際は自動化が非常に有効です。なぜなら、期待結果が仕様通りかどうかを確かめるテストは機械による検証を行うことで、正確かつ素早く実施できるからです。さらに、複数回実施するテストに適用することによって、2回目以降のコストを大きく削減できることも魅力です。

　アジャイル開発では少しずつフィーチャーを実装していくため、以前実装したソースコードに手を加えることも多くなります。そのため、回帰テストをしてソースコードの修正によるデグレード（新しく実装したコードのパフォーマンスが、以前より悪くなってしまうこと）を防ぐ必要があります。テスト自動化のメリットはここにも表れます。以前のスプリントのテストを自動化しておくことによって、修正に応じて回帰自動テストを実施し、デグレードがないかどうかを確かめることが可能になりますし、もしもデグレードが発生したとしてもそれを早めに検知できるのです。

　テスト自動化については注意点やポイントなどもたくさんあるのですが、最も重要なところは自動化する対象を見極めることです。テストを自動で実施するため、実施手順や期待結果の検証などをスクリプトという形で記載し、テスト自動化フレームワークを介して実行しましょう。準備に工数が掛かり過ぎてしまって手動でテストをした方が早く済んだ、ということになってしまうと本末転倒です。

　自動化する対象を整理するために考案された「テスト自動化のピラミッド」という考え方があります。これは、自動化の導入のしやすさ、効果の出やすさをイメージ化したものです。この図を見ると、コンポーネントテストの方が他のテストよりも面積が広く、効果が発揮されやすいということになります。

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

　つまり、他の部分の自動化をする前に、コンポーネントテストから進めていく方がより効果的だということです。これは、ベリフィケーションの視点でのテストという意味でも非常に有効です。コンポーネントテストが不十分な場合、より後で行うテストにおいて、ベリフィケーションの観点でつぶしておくべきバグが大量発生し、本来そのレベルでテストしたいことができずに工数がかさんでしまう、ということになりがちです。コンポーネントテストレベルでしっかりとテストを完了することが、後の品質に大きく影響を及ぼします。

　今回はアジャイル開発のテストにおける要件設定とV&Vでのベリフィケーションという観点について解説しました。次回は、V&Vのもう1つの観点であるバリデーションと、探索的テストについて解説します。

参考文献

• アジャイルで欠落するテストの能力-InfoQ
• エッセンシャルスクラム　アジャイル開発にかかわるすべての人のための完全攻略ガイド／翔泳社／ルービン・ケネス 著、和智右桂 訳、郄木正弘 訳、岡澤裕二 訳、角 征典 訳／2014
• テスターとアジャイルチームのための実践ガイド 実践アジャイルテスト／翔泳社／リサ・クリスピン、ジャネット・グレゴリー 著／榊原彰 監訳・訳／2009

筆者紹介

江添 智之

バルテス株式会社

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

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

畠田 健一朗

バルテス株式会社

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

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