QAデバッグのチェックリストの作り方・書き方｜テストケースのテンプレート(テンプレ)と作成手順

チェックリスト（テストケース）を初めて作るとき、
「どこから手を付ければいいんだろう」「項目に漏れがあったらどうしよう」
と不安になり、手が止まってしまうことがありますよね。

私も昔、適当に作ったチェックリストでテストを進めた結果、後から重大なバグがポロポロと見つかり、徹夜で再テストをする羽目になった苦い経験があります。

難しそうに感じるかもしれませんが、実は「決まった型（テンプレ）」さえあれば、あとはコピペして中身を埋めるだけで作業は終わります。

この記事では、私が現場で実際に使い倒してきたそのまま使えるテンプレを最初に共有し、その後に具体的な作り方を解説します。 悩む時間をゼロにして、サクッと終わらせてしまいましょう。

時間がない方は、以下のリンクから必要な場所へ飛んでください。

• 🔗テストケースとは？仕様書との違い
• 🔗【コピペ用】今すぐ使えるテンプレートへ
• 🔗チェックリストの作り方（6ステップ）
• 🔗良い書き方・悪い書き方の図解を見る

※表（テーブル）が多いので、スマホの方は見づらいかもしれません。ブックマークして後でPCで見るのがおすすめです。

テストケース（チェックリスト）とは？仕様書との違い

テストケース（チェックリスト）とは、システムが仕様通りに動くかを確認するための手順と期待結果をまとめたものです。

「この画面で」「この操作をしたら」「こうなるはず」という具体的な確認事項をリスト化することで、誰がテストを行っても同じ基準でバグの有無を判定できるようになります。

さらに上流の「テスト仕様書（全体の計画）」との違いや書き方については、以下の記事で解説しています。
▶︎テスト仕様書の書き方

まずこれを使えばOKなチェックリストのテンプレ

とりあえずテンプレだけ埋めればいいや、と思っていませんか？
テンプレを埋めるだけではバグは防げません。後半で解説する『作り方の手順』や『観点の出し方』を知らないと、テストがザルになり痛い目を見ます。

この見出しでわかること：まずはテストケースの「外枠（列の構成）」を固めるテンプレを紹介します。 書き方のルールを統一して形式的な迷いをなくし、後半で解説する「中身（観点）」に集中するための土台を作りましょう。

テンプレに入れるべき必須項目

チェックリストは「項目の一覧」ですが、現場では「テストケース（手順と期待結果がある）」として運用されることが多いです。
なので、最低限この7つは入れておくのが安定します。

• ID：後で「このケースの指摘」と言える番号
• 機能／画面：どこを確認するケースか（例：ログイン画面、設定画面）
• テスト項目：何を確かめるか（例：正しいID/パスでログインできる）
• 手順：実際の操作（再現できる粒度で）
• 期待結果：OKの判断基準（画面表示、遷移、メッセージなど）
• 結果：OK/NG、未実施、保留など
• 備考／証跡：スクショ名、動画URL、端末、ビルド番号など

ここまで入れておくと、次が楽になります。
「別の人が実行しても同じ結論になる」「バグ報告に必要な情報が残る」「更新しても破綻しない」この3つが揃うからです。

コピペ用の列構成サンプル（コピペOK）

以下は、最初の1枚としてそのまま使いやすい列構成です。
現場のルールがある場合は合わせつつ、迷ったらこの形を起点にすると崩れにくいです。

▼ チェックリストテンプレ例

ID	機能/画面	テスト項目	前提条件	手順	期待結果	優先度	担当	結果	実施日	不具合ID	備考/証跡
LOG-001	ログイン	正常ログイン	アカウント作成済	1.ID入力 2.パス入力 3.ログイン押下	マイページへ遷移	P0	佐藤	OK	1/7	–	動画log_001

▼ 列サンプル（左から順に）
ID｜機能/画面｜テスト項目｜前提条件｜手順｜期待結果｜優先度｜担当｜結果｜実施日｜不具合ID｜備考/証跡

• 前提条件：ログイン済み、初回起動、課金履歴あり…など
• 優先度：P0（致命）/P1（高）/P2（中）など、チームの運用に合わせる
• 不具合ID：バグ管理ツールの番号（未起票なら空でOK）

橋渡しとして大事なのは、「列を増やす」より「列の意味を固定する」ことです。
同じ手順でも、人によって粒度がブレるとチェックリストが一気に読みにくくなります。

このテンプレを使えば、とりあえず形にはなります。
…ただ、もしあなたが「毎回これを自作して、項目を考えるところからやっている」なら、それは少し危険かもしれません。
本来、研修やマニュアルが整っている会社なら、この作業は「用意されたものを使うだけ」で済むからです。

もし「独学で頑張るしかない」という状況に限界を感じているなら、一度「環境」を見直してみるのも手です。

テンプレを使い回すための命名とルール

テンプレを“使い捨て”にしないために、命名とルールを最初に軽く決めておくのがおすすめです。 ここを決めておくと、次案件で流用しやすく、レビューも通りやすくなります。

• ファイル名：案件名_対象_期間（例：PJX_Login_2025-01）
• シート名：機能単位（例：Login、Setting、Purchase）
• IDの振り方：機能略称＋連番（例：LOG-001）
• 更新ルール：更新した人・日付・変更理由が追える欄を用意する（変更履歴列でも別シートでもOK）

スプレッドシートでの運用をもう少し楽にしたい場合は、基本の考え方を先に押さえると迷いが減ります。
▶︎デバッグシートをスプレッドシートで運用する基本

ちなみに、ここで紹介した命名ルールやIDの振り方は、デバッグだけでなく「プログラムチェックリスト（単体テスト仕様書）」を作成する際にもそのまま応用できます。

チェックリストを作る前に決めること

この見出しでわかること：書き始める前に“軸”を決めて、項目が迷子にならない状態にします。

目的を決めると項目がブレない

チェックリスト作りで一番ありがちな事故は、「全部やろうとして、結局どれも浅い」状態です。
これを避けるには、目的を一言で置くのが効きます。

目的の例：

• リリース判定のため：致命的な不具合がないことを確認したい
• 回帰テストのため：前回OKだった動作が壊れていないことを確認したい
• 仕様理解のため：新人が仕様をなぞりながら理解を深めたい

目的が決まると、手順の細かさや、期待結果の書き方も揃います。
逆に目的が曖昧だと、「テスト項目だけ増える」「期待結果の内容が薄い（”〇〇が問題ないこと”と言う記載の羅列※何を以てして問題ないのか不明）で終わる項目」になりがちです。

対象を分解して漏れを減らす

チェックリストの漏れは、観点が足りないというより「対象の切り方が荒い」ことが原因のケースも多いです。
まずは対象を“分解”して、項目の置き場所を作ります。

分解の例：

• 機能で分ける：ログイン、プロフィール、課金、フレンド
• 画面で分ける：ログイン画面、入力フォーム、確認画面
• 状態で分ける：未ログイン／ログイン済み、初回／2回目以降
• データで分ける：正常値／境界値（上限下限）／異常値

ここまで分解できると、「どの画面の、どの状態で、何を確認するか」が自然に書けます。 逆に、分解がないまま書き始めると、同じ内容が重複したり、抜けが見えにくくなります。

完了条件を決めると手戻りが減る

チェックリストは作って終わりではなく、実施して初めて価値が出ます。
だから、作る前に「どこまで確認したら完了か」を置いておくと、手戻りが減ります。

完了条件の例：

• 必須（P0/P1）は全件実施し、重大不具合が0件
• 主要端末（例：iOS/Androidの各1台）でスモーク完了
• 修正後の回帰は、影響範囲＋主要導線を実施

完了条件があると、項目の優先度付けがしやすくなり、スケジュールが崩れにくいです。 「どこまでやればいい？」の確認が減るので、結果的にチーム全体が楽になります。

チェックリストの作り方を6ステップで解説

この見出しでわかること：テンプレに実際の中身を入れて、テストケースとして成立させる手順を解説します。

ステップ1 仕様とゴールを確認する

まずやるのは、仕様書や要件の読み込みです。
ただし、全部を完璧に読んでから着手しようとすると止まりやすいので、最初は“ゴール”を抜き出すのがコツです。

• ユーザーが最終的に何を達成したい機能か
• どの画面からどの画面へ遷移するのか
• 入力のルール（文字数、形式、必須任意）
• エラーメッセージの条件

「仕様が曖昧で不安」というときは、チェックリストに確認事項として残しておくのも手です。
質問が整理されるので、最終的なレビューの場で詰めやすくなります。

ステップ2 対象を機能と画面に分ける

次に、対象を「機能」と「画面」で切り分けます。
この段階で、テンプレの「機能/画面」列が活きてきます。

“置き場所”ができると、チェック項目が増えても迷子になりません。
項目レビューなどで後から見返した時に「この画面のケースが薄いね」と指摘しやすくなります。

ステップ3 観点を入れてチェック項目にする

ここで言う観点は、「どんな切り口で確認するか」という意味です。
観点を入れると、同じ機能でも“漏れにくい項目”になります。

まずは基本だけで十分です。たとえば次のような切り口です。

• 正常系：仕様どおりにできる
• 異常系：不正な入力や想定外の操作で破綻しない
• 境界値分析：上限下限、桁数、文字種などのエラーが起きやすい境目を狙う
• 同値分割：同じ結果になる入力値をグループ化してテストを減らす
• 状態：初回、再ログイン、途中離脱、通信断

観点の具体例を増やしたい場合は、ケースごとの考え方がまとまっている記事が役に立ちます。
▶︎テスト観点：導入編
▶︎テスト観点の洗い出し レギュラー観点編
▶︎テスト観点の洗い出し イレギュラー観点編

また、同値分割や境界値分析といった具体的なテスト設計技法（洗い出しの手法）については、以下の記事で詳しく解説しています。
▶︎テスト設計とは

観点を入れたら、次は“チェック項目”に落とします。
コツは、テスト項目を「1行1メッセージ」にすることです。

• 悪い例：ログインできること
• 良い例：正しいID/パスワードでログインでき、トップ画面に遷移する

この段階で曖昧さを削れると「正解の状態が明確」となり、後工程が楽になります。

ステップ4 手順と期待結果を具体化する

チェック項目ができたら、手順と期待結果をセットにしてテストケースにします。
ここが実際にテストを“実行できるかどうか”の分かれ目です。

手順のポイント：

• 操作は番号で並べる（1→2→3）
• 画面名やボタン名は仕様に合わせる
• 前提条件があるなら、手順の前に明記する

期待結果のポイント：

• 画面遷移、表示文言、入力チェック、保存内容を具体化
• 「問題ないこと」は避ける（判断基準が曖昧になる）
• 可能なら、表示メッセージは仕様の文言に寄せる

最初は「期待結果が細かすぎる？」と迷うことがあります。
そのときは、他人が実行しても同じ判定になるか（”誤解となる表現” や “複数の意味に取れる表現” になっていないか）で決めるのが安全です。

ステップ5 優先度と担当を決めて運用できる形にする

チェックリストは、運用に乗る（使い回しやすく汎用性が高い）と価値が跳ねます。
そのために、優先度と担当を入れて“回せる状態”にします。

• 優先度：問題があると困る導線から高くする（ログイン、購入、データ保存など）
• 担当：人に紐づけるというより「誰が見ても次に動ける」状態にする
• 結果の粒度：OK/NG/未実施/保留など、チームで統一する
• 不具合ID：起票したら必ず紐づける（後で追える）

運用を意識することも重要で「完璧に作る」より「回しながら（運用しながら）育てる」ということが精度を上げる方法として一番現実的になります。

ステップ6 レビューして更新ルールを作る

最後にレビュー（作ったテスト項目を別の人に見てもらう事）です。
新人のうちは特に、レビューでフィードバックを受けることで伸びます。
レビューでは、次の観点で見てもらうと改善点が見つかりやすいです。

• 粒度：手順が飛んでいないか、期待結果が曖昧ではないか
• 漏れ：対象の分解が足りない箇所がないか
• 重複：似た項目が別の場所に散っていないか
• 運用：優先度、結果、証跡の残し方が揃っているか

更新ルールも軽く決めます。

• 変更があったら、該当IDを更新して履歴を残す
• 大きい仕様変更は、新規タブに切り出す（後で比較できる）
• “次回に持ち越す”項目は、保留理由を備考に残す

これで、チェックリストが「作って終わり」になりにくくなります。

例で理解するチェックリストの書き方

この見出しでわかること：実際にどう書くとテストケースになるかを例で掴みます。

例 ログイン機能のチェックリスト例

ログインは、観点の入れ方がわかりやすい題材です。
ここでは、最低限の列（ID／テスト項目／手順／期待結果）に絞って例を出します。

この例のポイントは、期待結果が“判定できる言葉”になっていることです。
「エラーが出る」だけだと、どの表示が正しいかで迷います。
表示場所や文言まで記載すると、テストケースとして強くなります。

例 ゲームの画面表示確認のチェックリスト例

ゲームの表示確認は「スクショは撮ったけど、何がOKかわからない」が起きがちです。
なので、期待結果を“表示要素”で分解すると安定します。

表示確認のときは、「どの要素が対象か」→「どうなっていればOKか」の順で書くと迷いが減ります。
特に「崩れがない」という書き方は抽象的になりやすいので、ボタン位置・文字重なり・切れ・枠外などに言い換えるのがコツです。

例 バグ報告につながる記録の残し方

チェックリストは、バグ報告の入口でもあります。
同じNGでも、記録が薄いと再現に時間がかかり、結局チーム全体が苦しくなります。

備考／証跡に残すと強い情報：

• 端末名、OS、アプリバージョン、ビルド番号
• 発生率（毎回／たまに／初回だけ）
• 手順の補足（特定の順番、特定の入力値）
• スクショ名、動画名（ファイル名のルールがあると尚良い）
• 期待結果との差分（何が違うのかを一言で）

この“差分の一言”（期待結果とどのように相違していたのか）があるだけで、報告の質が一段上がります。

よくある失敗と直し方

この見出しでわかること：初回にやりがちな失敗を先回りし、直し方までセットで掴みます。

項目が抽象的で再現できない

あるあるなのが、「確認する」「問題ない」系の言葉で埋まってしまうパターンです。
この状態だと、実行者によって判断が割れます。

直し方はシンプルで、次の2つを足します。

• 条件：どんな入力／どんな状態で
• 観測点：どこを見てOK/NGを決めるか

「保持される」のように時間をまたぐものは、再起動や再ログインの手順を入れると強くなります。

正常系だけで終わってしまう

時間がないと、正常系で満足してしまいがちです。
ただ、実際に火を吹きやすいのは異常系や境界値です。
全部を網羅しようとせず、最初は事故りやすいところだけでも入れると効果があります。

• 必須入力の未入力
• 上限超え（文字数、桁数、枚数）
• 形式違反（メール、電話番号など）
• 通信断、バックグラウンド復帰

観点の例（バリエーション）を増やしたい場合は、基本の切り口を整理した以下の記事を参考にしてください。
▶︎テスト観点：導入編
▶︎テスト観点の洗い出し レギュラー観点編
▶︎テスト観点の洗い出し イレギュラー観点編

更新されずに形骸化する

チェックリストは、一度作って終わる（メンテナンスしない）と古い仕様のままの項目となります。
あたりまえのことですが、仕様変更や改修が入ったのに更新されないと、「やったのに漏れた」という勿体無い自体に発展します。

形骸化を防ぐコツは、更新の“入口”を決めることです。

• 仕様変更のチケットが来たら、関連IDを洗い出して更新する
• バグが出たら、再発防止としてチェック項目を追加する
• レビューで「次回追加」を決めたら、保留理由を残しておく

そして、更新の手間を減らすのがテンプレの役割です。
命名、ID、列の意味が揃っているだけで、更新コストはかなり下がります。

次に読むと理解が早い関連記事

この見出しでわかること：次の一歩として、漏れを減らす・運用を楽にする・考え方を整理する記事へつなげます。

観点を増やして漏れを減らす方法

「観点を入れる」は慣れるまで難しいと感じるでしょう。
ただ、自分の中で切り口（バリエーション）が増えるほどチェックリストは強くなり作成速度も上がります。
まずは要点を押さえて、例を見ながら観点を増やすのが早く確実です。
▶︎テスト観点：導入編
▶︎テスト観点の洗い出し レギュラー観点編
▶︎テスト観点の洗い出し イレギュラー観点編

シート運用を楽にする方法

チェックリストを“回す”段階に入ると、運用のしんどさが出てきます。
列の固定、フィルタ、担当の見える化など、基本だけ押さえるとグッと楽になります。
▶︎デバッグシートをスプレッドシートで運用する基本

デバッグとテストの違いを整理する

現場で言葉が混ざる（人によって言い方や認識が違う）と、目的がブレてチェックリストの粒度も揺れます。
「何のための確認か」認識を揃える意味でも、一度整理しておくと安心です。
▶︎デバッグとテストの違いをやさしく整理する

品質保証のプロフェッショナルについて確認する

品質保証を突き詰めた先にどういうキャリアがあるのか。
QAエンジニアという仕事について内容を確認しておくとビジョンが広がります。
▶︎QAエンジニアの仕事の全体像を確認する

まとめと次の行動

チェックリスト（テストケース）作りで迷ったら、次の順番に戻ると立て直せます。

1. まずテンプレで列（基本構造）を固定する
2. 目的・対象の分解・完了条件を先に決める
3. 6ステップで「観点→手順→期待結果」を具体化する
4. 実例の粒度に寄せて、抽象表現を減らす
5. 更新ルールを軽く決めて、運用で育てる

最後に、行動の方向だけ整理して終わります。 「今できること」を一つづつだけでも確実に進めることで次の一歩の方向性が広がります。

研修や教育体制が整った環境なら、チェックリスト作成も基本から教えてもらえます。「今の環境で独学は限界」と感じるなら、未経験OKのホワイト企業を覗いてみてください。

経験者の方は、より上流の「テスト設計」や「QAマネジメント」に関われる案件を探すのも手です。あなたの経験を高く評価してくれる非公開案件があります。