テスト設計技法を活用する

はじめに

テストケースの設計では、「テスト設計技法」が有用です。これは、「テスト対象に対してどのようにテストケースを作っていくか」を技法として具体化したものです。

今回は、このテスト設計技法について、使いどころの見つけ方をテーマに解説します。

テスト設計技法とは

テスト設計技法とは、「テストケースを作成したり選択したりするための技法」(ソフトウェアテスト標準用語集(日本語版))です。さまざまなテスト設計技法があるため一概に断定できませんが、おおよそ次の作業のすべて、または一部で構成されます。

1. モデル化。テストケースを作成できるようにテスト対象をモデル化します。モデルはデシジョンテーブル、状態遷移図、クラシフィケーションツリー、パラメータと値のリストといったものです
2. 網羅基準の設定。モデルをどれぐらい網羅するかの網羅基準を定めます。例えば、状態遷移図に対するnスイッチカバレッジ、制御フローに対するステートメントカバレッジといったものです
3. テストケースの導出。モデルと網羅基準からテストケースを導出します

テスト設計技法には多種多様なものがあります。主要な種類として、仕様からテストケースを作成する仕様ベースの技法、構造からテストケースを作成する構造ベースの技法、知識や経験を活用する経験ベースの技法などがあります。

テスト設計技法を使用するメリットは次のとおりです。

• 曖昧・複雑なものに対して、整理しながらテストケースを作成できる
• 目的に沿ったテストケース（特定の組み合わせをテストで網羅するなど）を作成できる
• テストベース(仕様書などテスト設計のインプット)の抜け漏れ・不整合を見つける。テストベースの理解を助ける
• 議論や教育といったコミュニケーションを支える

テスト設計技法の概要

テスト設計技法として一般的なものを表に示します。なお、今回は紙面の制約上、それぞれの技法の詳細は解説しませんが、各技法の定番と言える入門文献を付記します。

テスト設計技法を選択する

テスト設計技法を活用するには、適材適所での技法の選択が重要となります。

まず、テスト設計技法は、組み合わせ、状態遷移、制御フローなど、特定のモデルに特化してテストケースを作成します。そのため対象と相性の良いモデルの種類に合わせて、技法を選択する必要があります。

次に、テスト設計技法はそれぞれ強み・弱みがあります。効率良く・適切にテストを設計するためには、強みを発揮できるテスト設計技法を選択します。

適切なテスト設計技法の選択は、次の3つのすり合わせを行って判断します。

• テスト対象の情報。組み合わせか、状態遷移かなど
• 「どこまでテストすべきか」の十分性。品質リスクをどこまで抑えたいか、テスト対象をどこまで網羅したいか
• 「どこまでテストを作成・実施できるか」の実現性。チームのスキルレベル、自動化のフィージビリティ、使える時間、テスト対象の情報の誤り・抜けをどこまで補正できるかなど

これらを、テストの要求や制約の分析を通して明らかにしていきます。

また、これらを相互に調整して、望ましいテストを目指していきます。例えば「テストの十分性要求の達成が困難なため、チームのリソース増強やテスト技術向上を行う」「テスト対象の情報が不足してテストの十分性を考えられないので、ドキュメントの補強を働きかける」といったものです。

技法を選択する例として、クラシフィケーションツリー法の採用判断を示します。クラシフィケーションツリー法の強みは次のとおりです。

• 「テスト対象の情報」に関する強み
• 組み合わせの条件を分析できる
• 複雑なテスト入力条件をツリーで分かりやすく分析できる
• 「どこまでテストすべきかの十分性」に関する強み
• テスト条件を漏れなくダブりなく抽出しやすい
• 具体化・抽象化が得意。全体を俯瞰しながらテスト条件を分析できる
• 組み合わせテストのさまざまな網羅基準に対応できる

一方、テストに対し、次のような要求や制約があるとします。

• 環境構成の機能性をテストしたい
• 対象の環境構成は条件が複雑で、組み合わせが多数ある
• ドキュメントは整理されておらずわかりにくい。補完・整理する必要がある

この場合では、組み合わせを扱うほか、クラシフィケーションツリー法の強みを活かせる状況であるため、テスト設計技法として採用可能と判断できます。

適切なテスト設計技法を見定める

適切なテスト設計技法を選択するには、技法の強み弱みに精通しておくこと、技法選択のインプット（テスト対象情報、十分性、実現性）を理解しておくことが重要です。特に後者はテスト設計技法を勉強して現場で活かそうとする際に課題になりがちです。

この技法選択のインプットについて解説する前に、その前提となるテスト設計の全体像を見ていきます。大まかにまとめると、テスト設計は次の流れを取ります。

1. テストの要求（ニーズ・シーズ）を見つける
2. テストの要求に基づいて、テストが達成すべきテスト目標を定める
3. テスト目標を満たす上位テストケースを分析する
4. 上位テストケースからテストケースを作る

※これらはシーケンシャルなウォーターフォールのように順番に実施するものではありません。一般的に相互フィードバックや反復で調整しながら実施します。

技法選択のインプットは、主に3の要求や目標から上位テストケースを導く作業で行います。十分に詳細化された上位テストケースは、テスト対象とテスト十分性基準も詳細化されているため、どのテスト設計技法を選ぶべきかが明らかになります。

なお、現場のテスト設計は一般的に大規模で複雑なため、要求からいきなり適したテスト設計技法が明らかになるケースは限られます。そこではソフトウェア開発のアーキテクチャ設計と同じように、関心事の分離を行って大まかにテストを分割し、分割したそれぞれのテストで目標設定とテストケースの分析を実施するアプローチで、規模の大きさや複雑さに対応します。

テスト設計技法の選択の難しさ

テスト設計技法を選択するには、テストの要求とプロジェクトの状況を調べ、原則やグッドプラクティス（複数のテストレベルでテストする、単機能テストをしてから組み合わせテストをする、複数のテストタイプを組み合わせるなど）を適用することで、大まかに方針決めできます。しかし、そこから妥当なテストを目指して、さらに詳細に考えようとすると難しい作業となります。さまざまな制約の中で、正解が見えないまま試行錯誤が求められるためです。

ここでいう「さまざまな制約」とは、具体的に次のようなことです。

• テストはテスト対象のごく一部しか網羅できない
  ソフトウェアが取り得る条件は膨大です。入力の組み合わせ、タイミングのパターン、内部の状態などは認知不能なまでに条件があります。これら膨大な条件にテストで網羅できるのはごく一部のみです。少数をサンプリングして確認する程度しかできません。
• 本質的な妥当性は分からない
  テストの十分性の根拠は、突き詰めるとプロジェクトにとっての妥当性（ビジネスの成否、社会的責務の達成、ユーザにとっての品質リスクなど）です。ただその妥当性は、製品を市場に出して結果を見るまで、たいてい不透明です。かなり努力して品質を保証しても製品が売れない、といった事態は珍しくありません。
• 最後までテストベースは不足している
  テストベースはたいてい最後まで不足しています。フレームワーク、ライブラリ、仕様書の欠落したレガシーコードの引継ぎなどブラックボックスの存在はありふれています。リソースの限界から、要求仕様や設計のドキュメントも完璧に作られることはありません。
• リソースが足りない
  利益を確保するため、テストのリソースはぎりぎりまで最小化されます。また、テストは設計やプログラミングといった上流の人材不足・遅延の影響を受け、そこからさらに工数やリソースが減らされがちです。

まとめると、リソースが不足し、テストの妥当性も全容もわからないまま、サンプリング程度の確認手段でテストを成功させることが求められるということです。

なお、サンプリング程度にしか品質を確保・確認できないのはテストに限りません。コードレビュー、ドキュメントレビュー、静的解析といった他の検証・妥当性確認や、設計の工夫といった、より広い意味での品質エンジニアリング手法も同様です。

適切なテスト設計技法の選択を支える工夫

このような制約に対し、テストを含めた品質を確保・確認する手段はどれも非力です。これに対応するためには、チームで協力して手段の弱みや制約を補い合う、本質的な妥当性を学び続ける、生産性の向上や反復的な改善でゴールに近づく、という3方向の工夫が重要になります。

これはテスト設計技法の選択でも当てはまる話です。具体的に、前提として次のような工夫が重要になるということです。

仲間と協業する

例えば、他のフェーズのテスト（ユニットテストなど）が対応できていない品質リスクについてテストの十分性を上げる、制約が多くテストの費用対効果が悪い場合は他の手段でカバーしてもらう、といったことを行います。

イテレーティブな進化・学習のフィードバックループを回す

学習のフィードバックサイクルを回すことで制約を緩和し、テスト設計を改善していきます。

例えば、イテレーションやプロトタイピングで自分たちの技術力を確認したり、テストの妥当性（欠陥の流出具合など）を評価したりして、テスト対象情報・十分性・実現性のすり合わせを進めていきます。そして、テスト設計技法の適切な活用先を見つけていきます。

技術蓄積で生産性を高める

技術を蓄積し、テストの生産性を高め、使えるテスト設計技法の幅を広げます。

例えば、ツールによるテスト設計のサポートや、テスト実行を自動化して実現性の成約を緩和し、テストの十分性をより高めていくといったことを行います。

品質に精通する

テスト対象の本質的な品質やリスクの理解を深め、限られたテストリソースを妥当な対象に注力できるようにします。

例えば、本質的な品質リスクを理解して、リスクの高い対象のテストの十分性を高める、正しい仕様を把握してテストベースの漏れや誤りを補正する、といったものです。また、探索的テストなどで品質のスペシャリストの能力を活用して、より高度なテスト設計の十分性に対応するといったことを行います。

こうした工夫を実践すると、プロジェクトを成功させるために、テスト設計で本当は何をすべきかという役割が見えてきます。するとプロジェクトにとって必要な上位テストケースが見えてきて、どのようなテスト設計技法を選ぶべきかが分かるようになります。

おわりに

今回は、テスト設計技法の概要と、適切なテスト設計技法を選択するための考え方を解説しました。テスト設計技法の選択は、プロジェクトを成功させるために、テストが果たすべき責務を追及しつづける作業でもあります。そのため仲間との協業や品質への精通を継続して、テストで何をすべきか探し続けてみてください。

そこでテストの責務が見えてくると、導入すべきテスト設計技法が見え、技法の力を引き出せるようになります。