テスターとして経験を積んでいくと自然とチェックリストやテストケースの作成を任されるようになると思いますが、誰からも教えられることなく見様見真似で作成していませんか？
このようなケースはかなり多いと思います。
見様見真似で作成したチェックリストやテストケース、一見するとしっかり出来ているように見えてしまいますが、テストすべき内容の抜け漏れは多く、後になってバグが出てきたりして問題となってしまうでしょう。
実はチェックリストやテストケースを作成したことが無い人や作成初心者の人には、共通するやり方があるのです。
この記事では、初心者が陥りがちな作成方法についてお話したいと思います。
初心者がテストケースが作る際に陥るCPM法
以下の記事でゲーム業界にもソフトウェアテストが浸透しつつあるとお話しましたが、テストの現場ではテストケースを作成・活用する機会が増えてきています。
初心者がチェックリストやテストケースを作成する際、仕様書に記述されている内容をそのまま流用していませんか？
実はこの作成手法、CPM（Copy&Paste&Modify）法という名前がついていたりします。
CPM法とは 仕様書の記述内容をコピーしてテストケース（やチェックリスト）のフォーマットに貼り付け、語尾を「～となっていること」といった形に書き換えるテスト手法
名前がつくほどの手法なので、効果的な手法だと思いますよね？
むしろその逆なのです。
このCPM法は推奨された手法ではありません。
この手法はコピー&ペーストが中心で非常に作業的な手法です。作業的ということは、ほとんど思考をしていないのです。
本来テストケース（やチェックリスト）の作成では、『どこに』『どういう』確認をするか思考をめぐらせる必要があります。仕様書に書いてあることだけではなく、仕様書に書いてないことに対してもイメージを膨らませてテストすべき内容を創りこんでいく必要があります。
しかし、CPM法では仕様書に書かれている内容しかテストすることができません。
これでは本来必要なテストが抜けバグが潜んだままリリースされてしまう可能性があり、最悪のケースではユーザーがそのバグに遭遇し炎上や補償対応などとなってしまいます。
なぜコピペになってしまう？
初心者がなぜコピペに走ってしまうのか……について考えてみたいと思います。
ソフトウェアテストの中ではテスト分析、テスト設計、テスト実装に関する情報があるため、ソフトウェアテストを学習していれば少なくともコピペにはならいのではと思います。
そうなると、ソフトウェアテストの学習が進んでいないことがコピペとなってしまう要因のひとつと考えられます。
しかし、テスト設計のプロセスは組織やプロジェクトごとに少しずつ変わってくるでしょう。
ソフトウェアテストを学習していたからといって、初体験の際に知識情報をすぐに実践できるかというと難しい部分もあると思います。
ゲームの品質管理の現場では、『習うより慣れろ』の考え方ややり方がまだまだ残っています。
初めてテストケース（やチェックリスト）を作成する時に、その作成方法を教わったり指導されたりすることが少ないのではと思います。
そうなると我流になり『仕様書に書かれていることを抑えておけば良い』という思考になるのも理解できます。
これがふたつの要因ではないかと思います。
テストケースとチェックリストの違い
ここまでに『テストケース』『チェックリスト』という言葉を使ってきましたが、もしかしたらあまりよく知らないという人がいるかもしれませんので、念のため説明をしておきましょう。
ゲーム業界では『テストケース』と『チェックリスト』が混同されやすいのですが、両者の違いは以下のようになります。
チェックリスト 確認内容の概要やポイントが記述されたもので、その記述粒度は粗め 期待値が記述されていることもあるが、『仕様書と相違ないこと』となっていることがしばしばある テスターによって確認する内容が変わったり、テストするたびに確認する内容が変わる可能性が高い
テストケース テストするための条件や手順が細かく記述されており、基本的にはプロジェクトに関係の無い第三者でもテストが行える内容となっている 指定された通りに確認をすることでどういう挙動となるかの期待値も記述されている テスターによって確認内容は変わらず、何回テストをしても同じ内容のテストが行える
コンシューマーゲームではチェックリスト、モバイルゲームではテストケースが使われる傾向があるように感じています。
なんちゃってテストケース
ここまでお話したように本来のテストケースから考えると、CPM法で作成されたテストケースは『なんちゃってテストケース』とも呼べる内容と言えるかもしれません。
しかし、誰からも教えてもらえず我流でとなると、このようなやり方になるのは致し方ないとも言えます。
CPMはテストすべき対象や観点、条件やパターンなどの検討がまったく出来ていないため、非常にリスクのあるテストケース作成方法になります。
初心者の次のステップとして、仕様書からのコピペをやめてテストすべき機能は何か？、どうテストすべきか？を考えていく部分になるでしょう。
まとめ
ゲーム業界は閉鎖的な傾向があるため、自分たちの取り組みや活動が良いのかどうか客観的に図ることが難しいと思います。
自分たちの組織の外に意識を向けていくことで、自分たちの取り組みや活動の良し悪しがわかってきたり、より良い取り組みや活動へのヒントを得ることができます。
『井の中の蛙(かわず)大海を知らず』とならないように、広い視野をお持ちいただければと思います。
コメント