「仕様通りだけど使いづらい」を解消する、探索的テストの考え方：アジャイル開発における品質管理（4）

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

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

　前回は、アジャイル開発におけるスプリント内のテストと品質保証について「完成の定義」や「受け入れ条件」の設定、テストの考え方の一つである「V&V」について解説しました。

　前回の内容と重複しますが、V&VとはVerification（検証：以下、ベリフィケーション）とValidation（妥当性確認：以下、バリデーション）の頭文字を取ったものです。ベリフィケーションとは、「仕様通りに作られているのか」という観点です。そして、バリデーションとは、「ユーザーの要求に合致しているか」という観点です。前回は、ベリフィケーションの観点を主に解説しました。今回は、バリデーションの観点から解説していきます。

仕様通りでも使われなければ意味がない

　バリデーションの観点は、ベリフィケーションの観点と違い、明確に「これをテストすればよい」というものが見えづらいという特徴があります。しかし、システムの品質を向上させるためには重要な観点です。筆者にも苦い経験がありますが、仕様通りに作っていたとしても、操作が複雑だったり、順番が分かりづらかったりするとその機能自体が使われなくなってしまいます。

　作っている人間は仕様が分かっているので操作方法に問題が無いと思っていても、それを使用するユーザーにとっては分かりづらいものになることがあります。ソフトウェアの品質をランクアップさせるためには、そういった観点でフィーチャー（機能要件）を捉える必要があります。

　では、バリデーションの内容はどこで考えればよいのでしょうか。最も良いのは実装前に意識しておくことです。スクラムではユーザーストーリーを作成する段階です。ユーザーストーリーの受け入れ条件を考慮する際にバリデーションの観点も押さえるようにします。そうすることにより、実装後に発生する手戻りをなるべく防ぎます。

　ユーザーストーリーは一度作成したら終わりというわけではありません。実装を行うスプリントまでに、どの順番で実装するか、適切な粒度なのかどうかを検証し、ブラッシュアップします。場合によっては内容を分割したり、受け入れ条件を見直したりすることも有用でしょう。そのときに、バリデーションの観点を含めておくことが重要です。

探索的テストで仕様に現れない不具合を捉える

　アジャイル開発に限った話ではありませんが、テストを実施する際に、テストケースとして事前に用意した部分ではないところに違和感があり、結果としてそれが不具合だった、ということはよくあります。そういった不具合ばかり見つかるのも問題ですが、テストケースには収まらない、操作したときの違和感で不具合に気付くこともあります。「探索的テスト」という手法は、そのような人の力を有効に活用する手法です。ここでは、さらなる品質向上を目指すフィーチャーテストの手法として、探索的テストの活用について紹介します。

　探索的テストは、テストケースを作らないテストではありますが、ただむやみやたらにシステムを動かしてみる、という手法でもありません。こういった、事前にテストケースを作成しない手動テストのことを「アドホックテスト」といいます。探索的テストとは、アドホックテストの中でもより効果を発揮しやすいように実施するものです。

　具体的には、そのシステムの仕様や挙動に熟知したテストエンジニアが、テストする範囲を明確にした上で行います。その範囲の中で動作が怪しいところはないか、仕様上でも複雑な部分に考慮漏れが無いかなどを実際に操作しながら、操作結果をフィードバックしながら確認していきます。その際に、仕様上の不具合とは言えないまでも、直しておいた方がよいところを見つけることがあります。そこを改善できれば、短い開発期間でも効率的に品質を向上させられるでしょう。

　自動化テストの場合、事前に設定した検証結果のOK、NGしか判定できません。テストを高速に、正確にこなしてくれるという利点はありますが、それだけでは十分でありません。特に、バリデーションの観点から見た不具合は自動化テストで見つけられません。だからといって全てをアドホックテストだけで行うのも、体系的で網羅的なテストにつながらないため、効果が不安定になります。基本的なフィーチャー検証テストは自動化を含む事前作成のテストでしっかり押さえ、探索的テストも効果的に使用していくことがポイントです。

自動化テストと探索的テストのイメージ

アジャイル開発チームを編成することの難しさ

　ここまで、スプリント内で実施するテストのポイントを紹介しました。しかし、テストをうまく進めるためにはさまざまなスキルや経験が必要になります。また、探索的テストは対象のソフトウェアについての深い造詣と、テストで必要な部分を見極める素養の両方が必要となります。残念ながら、これらは一朝一夕で身に付くようなものではありません。ですので、品質やテストに関する知識と、開発するソフトウェアやドメインに関する知識、その両方に通じたスペシャリストがチームメンバーに存在することが望ましいと言えます。

　とはいえ、特定の個人のみがテストの作業を全て担当するような縦割りのやり方は、アジャイル開発には合っていません。クロスファンクショナルチーム（さまざまな職種を集めた機能横断型のチーム）を編成しつつ、テストに関する能力のあるメンバーがチーム全体をリードするという形が理想的です。

　そんな理想的な状態がすぐに作れるか、といえばそれは非常に難しいでしょう。アジャイル開発の問題点として、チームメンバーの構成や調達が困難であるということが挙げられます。テストに関しても例外ではありません。ただ、スキルアップも含めて、チームとしての課題を一つずつクリアしていき理想のチームに近づける、というのもまたアジャイル開発の方法論です。そのために、スキルを持つ人間をスポットでプロジェクトに参画させ、チームとしての経験値を上げていくという方法があります。

　例えば、テスト自動化のスキルに長（た）けたエンジニアに参加してもらい、環境構築やスクリプト作成のトレーニングを担ってもらうという方法は効果的でしょう。その際に、開発プロジェクト内に複数のアジャイルチームが存在するのであれば、チームを横断してアドバイスを得ることによって、チーム間の知識やノウハウの格差を軽減することもできるでしょう。

一つ一つのプロセス改善が品質向上の近道

　ここで、スプリント内のテストについて、品質改善の事例を紹介したいと思います。そのプロジェクトは、社内システムのマイグレーション案件で、現在稼働しているシステムを元に最新の環境へと更新することを目的として開始しました。アジャイル開発をするということのみが決められており、大切なポイントである完成の定義は特に定められていませんでした。また、フィーチャーはユーザーストーリーを採用して検討していたのですが、その受け入れ条件も、従来のシステムの仕様をそのまま条件として起こしただけのものでした。

　結局「何ができればOKか」ということがおざなりな状態でスプリントがスタートしましたが、受け入れ条件は明確だと考えられていたため、それで問題ないと判断されてしまいました。

　その結果、稼働中のシステムにおいて明文化できていなかった部分の仕様を盛り込むことができず、それらの実装がやり直しとなってしまいました。その修正をしようとすると既存の仕様にまで不具合が発生してしまいました。つまりデグレード（新しく実装したコードのパフォーマンスが、以前より悪くなってしまうこと）が多くなり、収拾がつかない状態となってしまったのです。

　そこで、この状態を改善するために、スプリント内で品質を確保するプロセスを構築しました。まずは、完成の定義を整理しました。このプロジェクトでは、ユーザーストーリーの定義はされていましたので、受け入れ条件の検討時に、複数のメンバーで検証可能な形に定義し直しました。

　フィーチャーが完成した際も、テスト結果をレビューすることと、先の現行システムを知っているメンバーで確認することで、大きな手戻りを防げます。その結果、フィーチャー実装に関する品質は格段に向上していきました。

　一つ一つの改善がうまくいき、取り組みが安定して次に進む、という形で徐々にプロセスを改善していきました。スクラムには「スプリントレトロスペクティブ」という、スプリントの振り返りと、次回以降のスプリントで改善するポイントを話し合うイベントが設定されています。それをうまく使うことがより良いプロジェクトのためには重要なポイントとなります。

　前回に引き続き、スプリント内におけるテストのポイントを紹介しました。次回は、スプリントの外側で考慮すべき事項を紹介します。

筆者紹介

江添 智之

バルテス株式会社

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

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

畠田 健一朗

バルテス株式会社

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

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