【QA】デバッグ_チェックリスト（テストケース）の作り方| わかりやすい項目の作成手順 ※初めての方向け編

今回はこの点について言及していきます。

「初めての方向け編」ではデバッグ的な観点というよりは比較的どの職種にも当てはまる汎用的な内容が大半となっています。

※デバッグに更に寄った詳細な内容は「テスト観点の洗い出し方編」「テスト観点の書き方編」で段階別に記事を分けてお話しさせていただきます。

デバッグ_チェックリスト（テストケース）とは

チェックリストが必要な理由

まずチェックリスト（テストケース）とは何なのか、なぜ必要なのか、
この辺りについて言及していきます。

例えばですが、日常生活を例に以下のようなことがあったとします。

この場合、
「カレー」という食べ物は当然両者とも知っているので最低限の必要具材は揃いました。

ただ、お互いが思い描くカレーの完成形は違ったので、
必要な物が一部揃いませんでした。

というケースになります。

対して以下の場合はどうでしょうか。

この場合、
細かいオーダーを「メモを通して相手に伝える」ことができているので、
一切問題なく具材が調達できました。

つまるところ、
このメモというのがチェックリスト（テストケース）になります。

上記までのようなケースも踏まえ、
チェックリスト（テストケース）が必要な理由をまとめると以下となります。

上記のようにやるべき事や重要な事など、
全てを項目として書いておくことで業務の精度が上がるということですね。

人間の記憶力には限界がありますし、
理解していてもふと忘れてしまうようなケースもあると思います。

例えば、
「言わずもがな」「お互い理解している」「今まで何度もやったこと」
というようなケースであっても、
このチェックリスト（テストケース）があると、ふとしたケアレスミスも防げると思います。

またカレーのケースで一例を挙げます。

たとえ「理解していること」であっても、ふと忘れてしまうことはよくあるので、
その点を補うツールとして、
チェックリスト（テストケース）を使うことは重要であるという点、ご認識いただけたかと思います。

どんな業種でも、その道の熟練者ほど知識は豊富ですが、
豊富で選択肢が多いが故に忘れてしまうというのは熟練者であってもあることなので、
自分の頭の中だけで事を進めることはリスクであると考えた方が安全に仕事を進められるかと思います。

デバッグ_チェックリスト（テストケース）の作成手順

今回は、どんな職種でも汎用的に使えるようなチェックリスト（テストケース）の内容もかなり含みます。

ですが、もちろんデバッグにおいても当てはまる基本部分となっています。

また、チェックリストのフォーマットは様々だと思いますが、
今回はエクセル及びgoogleスプレッドシートで作成することをメインにお話させていただきます。

チェックリストの基本の構成

チェックリストですが、
まず必ず必要となる要素としては、
「〇〇という点についてチェックをして、結果OKだったかNGだったか」
という点を可視化できることです。

マスト要件は上記の点なのでシンプルですが、
チェックリストとしてより精度を上げるためには、プラスアルファの要素もさらに必要となります。

（その点も併せて、必要な要素とその理由を以下に記載します）

この辺りが基本的なチェックリスト（テストケース）の要素となります。

テンプレートを作る

上記までを踏まえて、まずはテンプレート（雛形）を作っていきます。

いろんな場面やいろんな観点でチェックリストは必要になりますが、
毎回ゼロから作る必要はなく労力の無駄なので、
ある程度汎用性のあるベースとしてテンプレートを作っておくことで、以後の業務を楽にすることが目的です。

一例ですが、以下画像のようなものがテンプレのイメージです。

このテンプレートをベースに、
用途に応じて添削をするイメージになります。

では、
実際にこのテンプレートをベースに、先ほどのカレーの具材調達の件をチェックリスト化してみます。

こちらの例では、
まず「チェック観点の①～③」で、
チェックすべき観点を整理して「チェックする対象が何なのか」を明確化しています。

例えばチェック観点①に「目的、具材、量」を全てまとめて記載することもできますが、
一箇所に観点がまとまると見落としや見辛さが生じるので、
なるべく観点は分散させる事をオススメします。

次に「確認事項」で「チェック対象をどうするのか」を明確化しています。
今回の場合「具材を調達する事」が目的ではありますが、
「調達をどのように行うのか」の指定がない状態で他人にチェックをお願いした場合、
全てスーパーで買ってくるという判断になってしまうことが主だと思います。

「こうしてほしかったのに」というような事がないように「どのように」という点も項目化することが重要です。

最後にチェックした結果を、チェック結果、日付、名前に記載し、備考にメモを残せるようにしています。

これがテンプレートとその使い方のイメージになります。

使っていく内に「もっとこうした方がいいかも」というような考えは浮かんでくると思いますので、テンプレートは都度ブラッシュアップしていきましょう。

観点の入れ方（基本編）

大枠のチェックリストの在り方については先までの内容となりますが、
この「観点」というポイントについてはややデバッグにフォーカスしてお話させていただきます。

デバッグ業務においては、
観点が多岐にわたるという点もありつつ「どうあるべきなのか」という点を明確にする必要があります。

先述のカレーの買い物の例では、
「どのように調達するか」というような点はあれど、
その結果は全て「調達できたらOK」という一点に終着するするため、
「最終的にどうあるべき」という細かい指定は不要でした。

対して、
例えばスマホゲームのデバッグ等ではその点を詳細に記載する必要があるため、
よくある定番の型としては以下のようなものあります。

先ほどまでのテンプレートと比較すると「期待される結果」というものが増えていることがわかると思います。

この欄をどう使うかについては、以下例のようになります。

全体を解説すると、

まず「チェック観点」の欄はおおよそカレーの買い物の例と同じ用途です。
チェック観点①②で「どこを見るのか（場所）」という点を明確化しています。
チェック観点③「何を見るのか（物）」という点を明確化しています。

次いで「確認事項」についても同様に、
「チェック観点①②③」で指定したチェック対象に関して「どのように（チェックの方法）」という点を記載しています。

それらに加えて、
新たに追加された「期待される結果」についてですが、
チェック対象に対して指定の確認方法を行なった結果「どうなっていることが望ましいのか」を記載する欄になります。

デバッグ業務においてはこの点が一番重要であり、
「どういう動作や表示になっていれば良いのか」という点の記載がなければ、
正否の判断は各々に委ねられるということになるので、

「正解は本来〇〇だが確認した結果は△△だった。ただ、テスト実施者的に△△でも違和感がなかったので本人の判断でチェック結果はOKとしてしまった」

というようなケースが生まれる懸念があります。

（画像の例で言うと、ボタンAをタップしたら画面Bに遷移すると言う動作だったが、まあいいかと言う判断をしてしまったと言うケースを指します）

このようなケースが起きないように、
「こうあるべきである」という点を「期待される結果」として明記することが重要です。

上記までを踏まえて、

「どこを」「どのようにして」「どうなっているべきか」

と言う観点を読み手に伝えられる内容にすることを心がけるようにしましょう。

いかがでしたでしょうか。

今回はチェックリスト（テストケース）を初めて作る場合の手順について、
概念を交えつつお話させていただきました。

※こちらの記事では本記事の続きとして、テスト観点の考え方を記載しています。

【QA】デバッグ_チェックリスト（テストケース）の作り方 ※テスト観点の洗い出し①_導入編デバッグ業務の中でチェックリストを作るというのは一つの壁で難しいですよね。 その壁＝テスト観点という概念がよくわからないという方も多いと思いますので、そのあたりのお話の導入部をお話させていただきます。...