テストケースを作ろう

テストケースには書き方があり、レビューされなければならない

テストケースには書き方があり、作成したものは必ずレビューされる必要があります。あたりまえのことなのですが、案外知られていません。中には、テストケースの作成は担当者任せで、レビューを一度も行わないままテストを実行するという現場もあるそうです。これでは、テストケースの品質が確保できまんし、テスト実行でも手戻りが頻発したりして、うまくいかないでしょう。

「品質の低いテストケースからは、品質の低いテスト実行しか生まれない。」

新人さんはこれをしっかりと理解してください。 また、ベテランさんは自分の現場がこのような状況である場合、早急になんらかの手を打ちましょう。

新人さんはこの言葉を受けて、具体的な作業として次の2点を最低限押さえる必要があります。

第4回は、この2つについて、新人さんがまず押さえるべき点を解説します。

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

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

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

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

答えは“⁠No⁠”です。

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

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

（1）文章は短くする

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

基本的に一文一葉です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

テストケースは作成後にレビューされなければならない

先ほど解説したように、テスト仕様書に従ってテストケースを作成します。 作成が終了するとすぐに実行したくなるのが人情というものですが、まだやるべきことが残っています。

それはレビューです。

レビューとは、開発成果物に含まれる不具合や誤り、不備な点を見つけるための作業です。人間はどんなに気をつけていてもミスを犯してしまうものです。

テストケースを作成したとしても、そのテストケースに間違いがあるかもしれません。間違ったテストケースを実行しても正しい結果は得られないでしょうし、もしかすると、本来間違ったことを正しいものと理解して実行してしまうかもしれません。

これではテストとしての質は下がってしまうでしょう。これを防ぐために、作成したテストケースは、もう一度それが本当に正しいかどうか確認する必要があります。

レビューの種類とまず押さえるべきポイント

レビューにはいくつかのレベルや手法がありますが、ここでは話をわかりやすくするために次のように分けることにします。

個人レビュー

自分の作ったものを自分で見直します。一番手軽ですが、自分の思い込みが強く影響してしまうため、効果的に間違いを発見することには向いていません。ただし、エンジニアのマナーとして、自分が作ったものは最低限自分で見直すということをしなければなりません。

同僚レビュー

近くの同僚や先輩に見てもらいます。他人の視点からの指摘を獲得することができ、自分の思い込みによる間違いの排除が期待できます。ただし、他人の時間を使うことになるので、時間の調整や多少の事前準備が必要となります。また、同僚に対し説明する必要があるため、レビュー対象物を深く理解しておく必要があります。

組織レビュー

チームやプロジェクト、部門の単位で行うレビューです。事前の資料配布や開催時間の調整、参加者の選定に場所の確保等、計画的に行われる必要があります。参加者はプロジェクトメンバはもとより、関連する他部門の有識者にも参加してもらいます。これにより、より多角的な視点からの指摘を得ることができるようになります。このレベルになると、専門の司会者（モデレータ）を置いて開催することがほとんどです。

この連載のケースのように「新人さんの初めての仕事」という場合は、いきなり新人さんが組織レビューを行うことはありえません。組織レビューは他部門を巻き込んで行いますから、さまざまな調整作業が発生します。社内にまだ人脈がない新人さんには非常にハードルが高いレビューです。個人レビューと同僚レビューが、新人の方でも比較的はやく経験するレビューになります。

では、個人レビューと同僚レビューでは、まずどういったことを抑えたらよいでしょうか。それぞれにいくつかポイントを挙げます。

個人レビュー

• 致命的な間違いがないか、もう一度考える
• くだらない誤字脱字を訂正する
• 他人に見せる資料として体裁など問題ないかをチェックする

同僚レビュー

• 時間と場所の調整をつける
• 事前に資料を用意しておく
• とくに見てほしいポイントや不安な点について書き出しておく
• レビュー議事録を作成する

いきなり、レビューをうまくできるわけはありません。些細なことですが、上記のような点をしっかり押さえることが重要です。先輩に見てもらうということはレビューを行うということです。単に見てもらうという気持ちではなく、レビューを行うんだという気持ちで取り組みましょう。

おわりに

テストケースには、複数の記述の仕方があり、状況によって適切なものを選択する必要があります。また、作成したテストケースは作りっぱなしにせず、レビューを行い、テストケースとしての品質を確保する必要があります。

良いテストケースが作成されなければ、いくらテストを実行しても意味がありません。でたらめなテストケースを作成することで、でたらめなテストが実行され、結果としてでたらめな品質のソフトウェアがお客様の手に渡ってしまいます。

テストケースの品質がテストの品質を決めることを肝に銘じて、慎重に作成してください。

次回は、いよいよテスト実行時のお話となります。テスト実行は単純にテストケースを実行して合格／不合格の二値の判定を下すものではありません。実際にはさまざまな情報を記録する必要があります。このテスト実行時の記録のとり方について解説を行います。