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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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