新人注目! テストを極める最初の一歩

第3回 コピー&ペーストでテスト仕様書を作っていませんか?

この記事を読むのに必要な時間:およそ 3.5 分

テスト設計を行う

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

  • テスト観点を洗い出す
  • 結果が同じとみなせるものをまとめる
  • 期待結果を把握する
  • 単機能のテストをしてから組み合わせのテストを考える
  • 組み合わせのテストは重み付けを考慮する
テスト観点を洗い出す

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

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

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

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

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

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

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

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

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

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

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

期待結果を把握する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

終わりに

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

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

著者プロフィール

鈴木三紀夫(すずき みきお)

1992年,(株)東洋情報システム(現TIS(株))に入社。複数のエンタープライズ系システムの開発に携わり,現在は社内のソフトウェアテストに関するコンサルタントとして活動中。ASTER理事,JaSST実行委員,JSTQB技術委員,SQiPステアリング委員 他。

著書


池田暁(いけだ あきら)

2002年日立通信システム(現日立情報通信エンジニアリング)に入社。設計,ソフトウェア品質保証業務を経て,現在は開発に関する設計/テストツールの導入や,プロセス改善に関する業務に従事。ASTER理事,JaSST実行委員,品質管理学会・ACM正会員。

著書