仕様書の読み方がわからない！

テストにおける仕様書の読み方を教わりましたか？

テストの仕事を任されたとき、先輩から仕様書の読み方を教わりましたか？ 残念ながら読み方を教わることはほとんどないでしょう。

この仕様書、プログラムを書くときと同じように読んでいると、テストケースを書くのに苦労するかもしれません。なぜならば、

からです。

また、仕様書を読んでからいきなりテストケースを書いていませんか？ 先輩が過去に書いたテスト仕様書を参考に（コピー＆ペーストともいいます）書いたりしていませんか？

過去の成果物を活用して仕事を早く終わらせることは大切です。しかし、新人の皆さんにとって、今は基礎を固めるという大事な時期でもあります。基礎固めをおろそかにしてしまうと後々つらい目に遭ってしまいます。テストにおける基礎固めとはテスト設計です。

テストにも「設計」があります。新人の皆さんが第一に覚えて、身に付けなければならないことは、テスト設計なのです。

第3回は、仕様書の読み解き方と、テスト設計の初歩について説明します。

新人によくある光景

仕様書の読み解き方に入る前に、もう少し考えてみましょう。新人さんの作ったテストケースを見ると、次のようなものを作ってくるケースが多いようです。

一見よさそうに見えますが、このテストケースは使い物になりません。単に仕様書に書かれた文章をそのまま書き写しただけで、語尾を「～することを確認」と書き換えた代物です。これは有効なテストケースとはいえないでしょう。

この例は極端にわかりやすく書いたので、「⁠そんなことはしないよ」と思う方もいるかもしれません。しかし、実際にこのようなテストケースを作ってくる新人さんは後を絶ちません。

テストケースを作るという作業は、仕様書からの文章の転記作業ではありません。新人の皆さんはこれを肝に銘じてください。テストにおいて非常に基本的かつ重要なことなので、ここでしっかりと理解しましょう。

仕様書をどのように読むか

仕様書は、最初から最後までを流し読みしても意味がありません。いくつかの視点を意識して読み解いていく必要があります。

テストの立場から仕様書を読み解くとき、まずは、以下を意識すると良いでしょう。

疑ってかかる

新人のうちは、仕様書に書かれていることは正しいと思いがちですが、なにぶん人間が作成するものですから、間違いを完全に排除することはできません。仕様書に書かれていることは必ずしも正しいとは限らないと思うことから始めます。

間違った仕様をベースにして作成したものは、間違ったテストケースしかできあがらないのです。仕様書を読み解く作業は、仕様書の間違いを見つけるというテストを行っているという意識で取り組むと良いでしょう。

仕様書をラインマーカーやボールペンで汚すことが可能であれば、疑問点は必ずチェックを付けて、心のつぶやきを余白に書いておいてください。後でまとめて書こうと思っても忘れてしまうことの方が多いのです。頭の中にふっと浮かんだ言葉にならないような疑問を言葉で捕捉して、書き残してください。

書かれていることの厳密性を確認する

仕様が書かれていたとしても、それがあやふやに書かれていたら、テストを行うことはできません。文章が厳密にかかれているかを注視する必要があります。もしあいまいな文章であるならば、それは必ず厳密な文章に直しましょう。

また、仕様書全体にあいまいな記述が散見される場合、その仕様書は検討がされていない可能性が高いです。この場合、設計者に再検討を要請する等の手を打つ必要があります。

書かれていないことを明らかにする

本来書かれるべきであることが、書かれていない場合があります。書かれていないことを認識するのは非常に難しいことですが、ヒントはあります。それは、ある仕様が書かれているとして、近くにその検証方法などが書かれていない場合です。そんなときは要注意です。

行間を読む、関連性を意識する

「書かれていないことを明らかにする」と似ていますが、ちょっと違います。

書かれるべきことは書かれていても、「⁠これは常識だ」と思って書かれないことはたくさんあります。エンジニア間、あるいはお客様とのつきあいの中で常識と思われているようなことは、暗黙のこととして仕様書に取り上げられていないケースがあります。

大抵の場合、仕様書を自分なりに解釈して読んでしまうため、暗黙的なことがちゃんと仕様として書かれていないことに気が付きません。

また、仕様はほかの仕様との関連性を持つことがほとんどです。その仕様が別のどの仕様と関連しているのかをしっかりと抑える必要があります。

最初はおしりから読む

仕様書ではは、重要なことが文書の最後に書かれているケースが多いです。慣れないうちは、頭から仕様書を読んでいくと最後には疲れてしまい、重要なことが書かれているのにもかかわらず、集中力が続かずにちゃんと読み解けないというケースがあります。

最初に結論がわかっていると、それにたどり着く前段の文章の理解が進むという効果があります。

このテストの立場に立って読み解くという行為は「仕様分析」です。設計を行うためには対象を分析する必要があります。仕様書を読み解くという行為は、テスト設計を行うための分析作業を行うことなのです。

テスト設計を行う

さて、仕様分析が終わったところで、テストケースを作成するための「設計」作業を行いましょう。このテスト設計は、テストの観点を洗い出し、整理し、重み付けといったことを行います。テストケースを行き当たりばったりに作るのではなく、ちゃんと意図を持って作成するための作業です。

テスト観点を洗い出す

仕様書を読んで、プログラムの動作結果に影響を与えるような項目を見つけます。動作条件やパラメータなどです。テキストの入力項目や選択項目のように値が変化するところや、プログラムの起動オプションや設定ファイルに書く設定値のようなものかもしれません。プログラムが動く環境（CPUやOS）がそれに当たるかもしれません。

何をテスト観点とするかは、プログラムやシステムの種類によっても違いますし、テストの範囲によっても違います。プログラムのテストのときと、システムのテストのときでは、テスト観点は変わります。

結果が同じとみなせるものをまとめる

先ほど挙げた仕様は、そのままではテストできませんので、仕様を追加します。

仕様：テキストボックスに文字を入力し、表示ボタンをクリックすると、表示領域に入力した文字が表示される。
テキストボックスは半角8桁の数字を入力できる。←　追加

テキストボックスにどんな値を入れればよいのかを考えます。

このように、仕様書のこの箇所をチェックします。

次に有効なケースと無効なケースを考えます。

	有効なケース	無効なケース
半角	半角	全角
8桁	1～8桁	0桁、9桁以上
数字	数字	英字、制御文字……

「8桁」の有効なケースでは、1～8桁とまとめてあります。これは、1桁でも2桁でも3桁でも…8桁でも期待結果としては同じ種類であると考えたためまとめています（当然、同じ結果にはなりません。同じ種類の結果です⁠）⁠。

このように整理することによって、同じような結果になるテストケースを集約することができます。なおテスト技法の名称としては「同値分割」と呼ばれています。

期待結果を把握する

プログラムに欠陥がなかった場合に、どんな結果が期待できるのかを把握します。よく新人さんにテストケースを書いてもらうと、期待結果が書かれていないことがあります。欄を埋めるように指導すると、「⁠プログラムを動かしてみないとわかりません」という困った新人さんもいます。

期待結果がわからなければ、テストを実施しても不具合かどうか分かりません。期待結果が何かを知った上でテストを行います。

単機能のテストをしてから組合せのテストを考える

複数のテキストボックスがあったとき、1回のテストで消化できるように横着をして複数のテキストボックスのテストをまとめて行ってはいけません。1つ1つのテキストボックスのテストを実行するようにテストケースを書き、次に複数の組合せを考えます。

なぜ、このように面倒なことをしなければならないのでしょうか？

私たちは、不具合を見つけるためにテストを行います。プログラムのどこかに欠陥が潜んでいて、その欠陥を取り除くためにテストを行います。複数の項目をまとめてテストを実行して、その結果が期待結果と異なっているとき、欠陥箇所を見つけるのは非常に大変です。結局、1つ1つの項目を変化させて、欠陥箇所を特定させることになります。

面倒かもしれませんが、単機能のテストを最初に行うことが大切です。

組み合わせのテストは重み付けを考慮する

単機能のテストが終わったら、組合せのテストを行います。しかし、組合せはかけ算になりますので、テストケースが爆発してしまいます。

どのテストケースを優先して行うのか考えて、テストケースに重み付けをします。

テスト設計は、ここに書かれている内容だけでできるものではありません。また、この記事を読んだだけでは、わかりにくいと思います。新人の皆さんは、先輩に教わったり書籍や雑誌の記事を読んだり、このようなWeb記事を読むなどして学習してください。

分析と設計に有効なツール

この分析と設計には、文書を読み解いて整理する力も重要ですが、何より発想力が必要とされる作業です。ですから、この発想を促進するツールを使うことが重要です。

この発想や整理のためのツールとしては、初心者がすぐ取り組めるものとしては、三色ボールペンやマインドマップ、付せん紙を活用すると良いでしょう。

詳しくは『マインドマップから始めるソフトウェアテスト』や『ソフトウェアテスト入門』をご覧になってください。

終わりに

テストケースはいきなり作ってはいけません。テストケースをいきなり書くという行為は、プログラムコードをUMLやフローチャートを作成せずにいきなり書くのと同じことです。テストケースを作成する前に、テストベースを分析し、そしてテスト設計を行うことの大事さを理解しましょう。

次回は、テストケースの書き方と、書きあがったテストケースのレビューについて解説を行います。