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

第4回 テストケースを作りっぱなしにしていませんか?

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

テストケースには書き方がある

プログラムはプログラム言語で書かれますが,テストケースは多くの場合,日本語の文章で書かれます。専用の言語を使わずに日常使っている日本語を用いてテストケースを書きます。この⁠日本語の文章で⁠というのが難しいところです。

日本語についての詳しいことは専門の書籍などにおまかせしますが,簡単に書くと「曖昧,かつ,冗長」な表現が得意なのが日本語の特色とすることができます。文学的にはそれがゆえに豊かな表現を可能にし,えもいわれぬ「艶」をかもし出したりします。

しかし,それはソフトウェアプロジェクトにおける成果物の記述に必要でしょうか?

答えは⁠No⁠です。

日本語でテストケースを書くとき,それは曖昧な表現を含みやすいということを意識しなくてはいけません。

では,曖昧さを含まないようにテストケースを書くためにはどのようなことに,注意したら良いでしょうか。いくつかありますが,新人さんはまず次の2点を押さえましょう。

  • 文章は短くする
  • 曖昧な表現は極力数字に置き換える
(1)文章は短くする

文章が長くなると,何をやりたいかがぼけてしまいます。接続詞が使用されている文章は,短文に分割しましょう。

基本的に一文一葉です。

(2)曖昧な表現は極力数字に置き換える

形容詞や副詞はなるべく使用しないようにします。⁠Aボタンを速くたくさん打つ。」という書き方は避けます。⁠速く」とはどれだけ速いのか,たくさんとはどれだけなのかを具体的に書かなければいけません。

また,形容詞や副詞を除いたとしても,あやふやな表現をしてしまうことがあります。たとえば,⁠Aボタンを連打する」という表現です。これは「Aボタンを1秒間当たり16回の速度で連打する」というような表現にします。ただ「連打する」と書いておくだけだと,1秒間に8回の速度でも連打ですし,3秒に1回のペースでも連打とみなすことができます。

曖昧な表現は数値に置き換えるなど,厳密な表現をしましょう。

テストケースは,必ずしも自分が作って自分が実行するとは限りません。プロジェクトの進み方によっては,自分が作成したテストケースを,他の誰かが実行しなければならない局面に遭遇することもあるでしょう。また,誰かが作成したテストケースを実行するという場面も多くあるでしょう。

誰もが解釈のブレがなく理解でき,主観ではなく客観的かつ定量的な基準で合否判断を行うために,文章表現には特に気をつける必要があります。

テストケースそのもののバリエーションはたくさんある

テストケースは多くの場合文章として作成されると解説しました。しかしながら,テストケースの表現は,必ずしも文章だけではありません。

場合によっては,文章ではなく図や表で表現するほうが適する場合があるかもしれません。また,文章であっても,一文で書くのか,手順ベースで箇条書きにするのかといったスタイルもあります。

これらは,どのようなテスト観点からどのようなテスト技法を使ってどのようなテストケース表現をするかといったことに依存します。

「テストケースには,複数の記述スタイルが存在する」ということを覚えておきましょう。

いろいろな方に話を聞きますと,テストの観点と確認事項を列挙するして表にまとめる「テスト項目型」を採用する現場が多いようです。

このほか,同じ表形式をとるものとして,入出力やビジネスロジックの関係を表としてまとめる「デシジョンテーブル型」があります。

また,操作や実行の手順を明確に書く「手続き型⁠⁠,といったものがあります。

今挙げたものは代表的なものですが,これら以外にも,沢山の記述スタイルが存在します。

今から書こうとしているテストケースは,どのようなスタイルで書くともっともわかり易く厳密に表現できるか,よく考えましょう。

テストケースの記述スタイルについての詳しい解説はこの連載の範囲を超えてしまう ため,より詳しく知りたい方は,テスト技法の解説書や『ソフトウェア・テストPRESS Vol.4』の記事「マインドマップから始めるテストケース設計」を参考にしてください。

著者プロフィール

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

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

著書


池田暁(いけだ あきら)

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

著書