最近テスト技法について教える機会が多いのですが、その後話を聞くとなかなかテストが改善しないという話を聞きます。
どういったことなのかとよくよく話を聞いてもテスト技法の適用は間違ったことはやっていない。
そこでテストケースを見せてもらうと、これが良くない。そもそもテストケースとしてきちんと書けていないのです。
そういった状況においてはどれだけテスト技法を覚えたとしても実際の業務で使えるもににはなりません。
実行担当者はテストケースを読んで実行します。そのテストケースの理解が難しかったり、そもそも成立していなかったら、テスト実行の品質は期待できないですから、結果としてテストは成立しないでしょう。
例えば制御フローテストという技法を使う場合、フローグラフに線を重ねることでテストケースを表現する場合もあれば、デシジョンテーブルを使って表現する方法や手順ベースで書くこともできます。
どれが表現方法として適切でしょうか？
多くの場合、組織でテストケース(リスト)の標準フォーマットが規定されていますが、それをそのまま何も考えずに使うとテスト技法とマッチせず、結果として非常にわかりにくいテストケースになってしまうということが起こります。
マトリクス表現を前提とするようなテスト技法に対して、手順ベースのフォーマットは適用が難しいかもしれませんよね。
しかし、意外にテストケースの表現方法に関する議論は起こりません。
テスト技法に詳しい人であっても、テストケース表現方法のバリエーションを持ってない場合が多いように思います。
テストケースの表現の形式としてはざっと挙げるだけでも以下のようなものがあります。
・グラフ型
・手順型
・マトリクス型
・決定表型
・スクリプト型
さらにそれぞれにバリエーションが存在しますし、組み合わせる場合もあります。
テスト実装を担当する人はこれをどれだけ知っているかがかなり重要です。
このあたりについてはテストPRESSで「マインドマップからは始めるテストケース設計」という記事で少し紹介していますので参照してもらえるといいかと思います。
テスト設計やテスト観点のモデリング、テスト技法の適用も確かに大切なのですが、最終的なテストケース記述がぐだぐだだったら台無しであるということは意識しておいたほうがいいです。
