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

チェックリスト（テストケース）を初めて作るとき、手が止まりやすいポイントがあります。
「項目ってどこまで細かくするの？」「観点って何を入れればいい？」「これで漏れてない？」というものです。

先に答えを言うと、迷いはテンプレで8割消せます。
列（基本構造）を固定して、作成手順を6ステップで回す。これだけで、読み手が変わっても再現できるチェックリストになります。

この記事では、まず“そのまま使えるテンプレ”を渡し、次に“作る前に決めること”を整理します。
そのうえで、6ステップの作り方と、実例（ログイン機能／ゲーム画面表示）で「こう書けばテストケースになる」を腹落ちさせます。

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

この見出しでわかること：まず形を固めて、誰でも同じ粒度で書けるテンプレにします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

目的の例：

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

目的が決まると、手順の細かさや、期待結果の書き方も揃います。
逆に目的が曖昧だと、「テスト項目だけ増える」「期待結果が“問題ないこと”で終わる」になりがちです。

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

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

分解の例：

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

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

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

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

完了条件の例：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 正常系：仕様どおりにできる
• 異常系：不正な入力や想定外の操作で破綻しない
• 境界値：上限下限、桁数、文字種などの境目
• 状態：初回、再ログイン、途中離脱、通信断

観点の具体例を増やしたい場合は、ケースごとの考え方がまとまっている記事が役に立ちます。

「テスト観点：導入編」
「テスト観点の洗い出し レギュラー観点編」
「テスト観点の洗い出し イレギュラー観点編」

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

この段階で曖昧さを削るほど、後工程が楽になります。

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

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

手順のポイント：

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

期待結果のポイント：

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

最初は「期待結果が細かすぎる？」と迷うことがあります。
そのときは、他人が実行しても同じ判定になるかで決めるのが安全です。

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

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

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

ここで橋渡しです。
運用を意識すると「完璧に作る」より「回しながら育てる」が現実的になります。

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

最後にレビューです。新人のうちは特に、レビューで伸びます。
レビューでは、次の観点で見てもらうと改善点が見つかりやすいです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この“差分の一言”があるだけで、報告の質が一段上がります。

よくある失敗と直し方

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

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

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

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

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

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

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

時間がないと、正常系で満足してしまいがちです。
ただ、実際に火を吹きやすいのは異常系や境界値です。

全部を網羅しようとせず、最初は“事故りやすいところだけ”でも入れると効果があります。

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

観点の例を増やす場合は、基本の切り口を整理した記事が助けになります。

「テスト観点：導入編」
「テスト観点の洗い出し レギュラー観点編」
「テスト観点の洗い出し イレギュラー観点編」

更新されずに形骸化する

チェックリストは、一度作って終わると古くなります。
仕様変更や改修が入ったのに更新されないと、「やったのに漏れた」が起きます。

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

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

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

次に読むと早い関連記事

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

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

「観点を入れる」は慣れるまで難しいです。
ただ、切り口が増えるほどチェックリストは強くなります。

まずは要点を押さえて、例を見ながら増やすのが早いです。

テスト観点：導入編
テスト観点の洗い出し レギュラー観点編
テスト観点の洗い出し イレギュラー観点編

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

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

デバッグシートをスプレッドシートで運用する基本

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

現場で言葉が混ざると、目的がブレてチェックリストの粒度も揺れます。
「何のための確認か」を揃える意味でも、一度整理しておくと安心です。

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

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

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

QAエンジニアの仕事の全体像を確認する

まとめと次の行動

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

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

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