テスト設計の基礎
機能動作確認一覧の作成
本記事では、テスト基本設計3番目の工程である、機能動作確認一覧について解説します。
機能動作確認一覧作成の工程では、テスト設計仕様書にて抽出した観点「機能動作」のテスト内容をまとめていくこととなります。
機能動作確認一覧を作成する目的、役割、作成方法や、次の工程であるテスト明細との繋がりについて、本記事にて詳しく解説していきます。
【目次】
１． 機能動作確認一覧とは
２． 機能動作確認一覧の必要性
３． 機能動作確認一覧の書き方
４． 機能動作確認一覧を書くときのコツ
５． おわりに
1.機能動作確認一覧とは
機能動作確認一覧とは、テスト観点「機能動作」について、実際のテスト対象でどのようにテストするのかを一覧にしたものです。
テストマップにて、機能と観点の組み合わせとテストの重要度を決めて、テストの全体像が見えるようになりました。しかしながら、テスト設計仕様書で抽出した観点の中でまだ定義が十分では無いものがあります。それが「機能動作」の観点です。
「機能動作」の観点でテストする内容を、ユーザー視点の「できなければならないこと（Must）」と、「できてはいけないこと（Never）」という考え方を使ってまとめたもの、これが機能動作確認一覧です。
ではなぜ、「機能動作」の観点のテスト内容はまだ不十分なのか、なぜ、ユーザー視点の「できなければならないこと（Must）」、「できてはいけないこと（Never）」という考え方を使うのか、次の章で解説していきます。
2.機能動作確認一覧の必要性
機能をテストする際、「機能の動作を確認する」と観点を設定しただけでは十分にテストすることはできません。なぜならば、機能動作の観点でテストすべき内容はテスト対象の機能によって大きく変わるからです。また、開発するシステムやソフトウェアは、まだ世の中に広まっていない独自の機能が備わっていることが多いです。そのような機能をテストするためには、そのシステム、ソフトウェア独自の観点でテストする必要があります。
では、そのような機能の動作を確認するテストの内容は、どのように決めていけば良いのでしょうか。多くの場合、開発仕様書に記載されている仕様からまとめているのではないかと思います。しかしながら、この方法では大きな問題が生じます。それは、「記載が抜けている仕様のテスト」と「ユーザー視点のテスト」が漏れてしまうことです。
このような問題が発生するには理由があります。まず、「記載が抜けている仕様のテスト」が漏れてしまう理由についてですが、開発仕様書は、何らかの記載漏れ、記載不備が生じている可能性があるためです。人が作成している以上、開発仕様書の記載漏れ、記載不備を防ぐことは難しく、そのことを考慮せずに、開発仕様書の記載に沿ってテストケースを作成してしまうと、記載が漏れている仕様のテストケースが漏れてしまうというわけです。
それならば、開発仕様書を完璧に作ることさえできれば、テストは抜け漏れなく行える。そう考える方もいらっしゃるかもしれませんが、それでもテストの抜け漏れは発生してしまいます。それが2つ目「ユーザー視点のテスト」の漏れです。
開発仕様書は、開発者の視点で作成されます。つまり、開発仕様書から作成したテストケースでは、テストする内容は開発者視点のみになってしまうということです。テストは開発者の視点だけでは十分とは言えません。システムやソフトウェアを使う人の視点からのテストも必要となります。仮に全ての仕様が完璧に記載された仕様書を作成することができて、記載された仕様を全て正確にテストできたとしても、使う人が望んでいた通りのシステム、ソフトウェアになっていなければ、残念ながら品質が良いとは言えないからです。品質の良いシステム、ソフトウェアにするためには、それを使うユーザーの視点が必要なのです。
「何か抜けている仕様は無いだろうか・・・」と、うんうん唸りながら開発仕様書とにらめっこしても、抜けている仕様を見つけることは難しいでしょう。抜けている仕様を見つけ出すには、開発仕様書に囚われず、ユーザー視点から考えていくことが重要です。ユーザーがその機能を使うとしたら、「何ができなければならないのか（Must）」、「何ができてはいけないのか（Never）」と考えることで、その機能が満たさなければならない要件が明確になります。この、要件が満たされているかを確認するテスト内容が「ユーザー視点のテスト」になると同時に、もし、開発仕様書に記載がなかった場合、「記載が抜けている仕様のテスト」を防止することにもなるのです。
このように、QUINTEEでは、ユーザー視点の「できなければならないこと（Must）」と「できてはいけないこと（Never）」から、機能動作に関するテスト内容をまとめます。これにより、「記載が抜けている仕様のテスト」と「ユーザー視点のテスト」の漏れを防いでいるのです。
3.機能動作確認一覧の書き方
では、実際に機能動作確認一覧を皆さんも作成してみましょう。機能動作確認一覧は、特別なツールを使わないと作成できないということはありませんが、マインドマップツールを使って作成すると便利です。（本記事の解説で使用しているサンプル画像はマインドマップツールを使っています。）
まず、「テスト設計仕様書の作成」で、作成したテスト設計仕様書を用意しましょう。機能動作確認一覧の作成には、テスト設計仕様書の機能一覧を使います。
最初に、機能一覧の大項目と中項目をマインドマップ上にならべます。
次に、各機能の機能要件を記載していきます。機能要件は、前述したようにその機能が「できなければならないこと（Must）」、「できてはいけないこと（Never）」は何なのかを考えて記載します。形式は「○○機能は（が）、～できる」、「○○機能は（が）、～をする（される）」、「○○機能は（が）、～しない（されない）」といった形になるのが望ましいです。
記載した各機能要件に対して必要な確認内容を記載します。確認内容は、「～の時（場合）に、～すると（しても）、～すること（しないこと）」というように、「条件」と「入力」と「出力」の内容が分かるように記載してください。
機能要件と確認内容が記載できたら、表にまとめましょう。
※Qbook アカデミーでは、QUINTEEで使用している各種ドキュメントのテンプレートをダウンロードすることができます。
機能動作確認一覧については、表形式のテンプレートがダウンロードできます。下記リンクからご利用ください。
4.機能動作確認一覧の書き方のコツ
「記載されていない仕様のテスト」、「ユーザー視点のテスト」の漏れを防ぐことができる機能動作確認一覧ですが、作成する上で注意すべきポイントがあります。
それは、作成するときは開発仕様書を意識しすぎないようにするということです。開発仕様書に意識が行き過ぎると、開発仕様書に記載されていることを確認する内容が並んでしまい、開発者視点の確認内容と何ら変わらない一覧となってしまいます。これでは機能動作確認一覧としての効果は発揮されません。
「そうは言っても、ユーザー視点が考えられない・・・」とお悩みの方は、対象の機能が「どうなっていればOKか（要件）」、「どうなっているとNGか（リスク）」というように、機能の要求とリスクを考えるようにしてみてください。
「どうなっていればOKか」と「どうなっていればNGか」は、対の関係にあります。最初に「どうなっていればOKか」を考えた後、そのOKとなる動作がNGとなるには、どのような状態でどのような操作を行ったときか、と考えていくと、うまくまとまっていくかと思います。
5.おわりに
機能動作確認一覧を作成することで、機能特有のテストすべきポイントをまとめることができました。これでテスト基本設計は全て終了となり、テストケースを作成するための基礎ができあがったわけです。
次はいよいよテスト詳細設計となります。テスト詳細設計最初の工程であるテスト明細では、テストマップでまとめた機能と観点の組み合わせと、機能動作確認一覧でまとめた機能動作のテスト内容を使用して、テストするパターンを導き出していきます。
テストを実行する際は、テストする条件（どのような状態の時に）と、行う操作（どのような操作を行うのか）が重要となります。テスト明細では、この条件と操作をどのように抽出して組み合わせいくかを考えていくこととなります。
テスト明細については、「テスト明細の作成」にて解説しています。