効果的なテストケースの作成方法（例付き）

ほとんどのテストケースは、バグを1つも発見する前に失敗してしまいます。それらは曖昧なチェックリストとして記述されていたり、前提条件が欠けていたり、複数のアクションが1つのステップにまとめられていたり、期待される結果の記述があまりにも大まかであるため、同じテストケースを読んだ2人のテスターが「合格」の意味について意見が分かれてしまうようなケースです。その結果、バグが見逃され、テストの実行結果が再現できず、QAはセーフティネットではなくボトルネックとなってしまいます。

優れたテストケースの作成は、テストスキルというよりも、検証設計に重きが置かれます。金融サービス業界ではこれを「メイカー・チェッカー・プロセス」と呼び、核指揮システムでは「2人制ルール」と呼んでいます。その原則は同じです。重要な仕事は、検証されていない単一の行動に決して依存してはなりません。適切に作成されたテストケースは、ソフトウェアに同様の厳格さを組み込みます。テストケースは、期待される結果と実際に観察された結果を明確に分離するため、両者の間の乖離を無視することはできなくなります。

ここでは、テストケースの作成方法、その重要性、そして長期的にテストケースの品質を向上させる方法について解説します。

テストケースとは？

テストケースとは、特定のソフトウェアが正しく動作するかどうかを検証するために必要な、具体的なステップ、入力、前提条件、および期待される結果を定義した構造化された文書です。これは、テスト戦略を概説する「テストプラン」や、ステップをプログラム的に実行する自動化されたコードである「テストスクリプト」とは異なります。テストケースは、これら両方が構築される基盤となる仕様書です。

例： Webアプリケーションのログイン機能をテストしているとします。この機能のテストケースでは、以下の要素を定義することになります：

手動テストケースと自動化テストケースの比較

現在、AIはほとんどのテストワークフローに組み込まれています。PractiTestの「2026年テスト業界動向レポート」によると、テスト専門家の76.8%がQA業務でAIを活用しており、最も一般的な用途はテストケースの作成（69.6%）とスクリプトのメンテナンス（59.6%）です。この変化が最も顕著に表れているのが自動化されたテストケースであるため、手動のテストケースとの違いを理解しておく価値があります。

適切に作成されたテストケースが重要な理由

ユーザーがチケットを発行する前に、回帰バグを検出できます。 コードの変更には、すでに正常に動作している機能を壊してしまうリスクが常に伴います。適切に作成されたテストケースは、デプロイのたびに実行される恒常的なチェックポイントとなります。1年後に開発者がログインコードをリファクタリングし、うっかりセッション処理を壊してしまった場合でも、そのテストケースがステージング環境で問題を検知してくれるのです。

合格／不合格を「意見」ではなく「事実」にしましょう。 「システムが適切に応答する」といった曖昧な結果は、各テスターに「適切」の意味を解釈することを強いることになります。同じテストケースを実行した2人のテスターのうち、一人は合格と判定し、もう一人は不具合として報告した場合、チームはソフトウェアのデバッグではなく、この意見の相違の解決に時間を費やすことになってしまいます。 期待される結果が「システムが『パスワードが無効です』というエラーメッセージを表示し、ユーザーをログインページに留める」と明記されていれば、解釈の余地はありません。結果が一致するか、一致しないかのどちらかです。これこそが「2人ルール」の実践です。テストケースが「作成者」、テスターが「確認者」であり、両者は同じ言語でコミュニケーションをとる必要があります。

暗黙知を再利用可能な資産に変えることができます。 多くのチームでは、シニアQAエンジニアが、あらゆるエッジケース、回避策、そして「あ、Xも忘れずに確認してね」といった細かな注意点を、目に見えないマップとして頭の中に抱えています。その人が休暇を取ったり、チームを異動したりすると、そのマップも一緒に消えてしまいます。明確な前提条件と境界値が記載されたテストケースを文書化することで、その知識を体系的に保存することができます。 チームに新しく加わったテスターは、TC_LOGIN_005を参照するだけで、閾値が何であるかやタイマーがどのようにリセットされるかを誰にも尋ねることなく、初日から「5回ログイン失敗後のアカウントロックアウト」フローをテストすることができます。

失敗の原因を、漠然とした領域ではなく、正確なステップに絞り込むことができます。 テストケースで「ページに移動し、認証情報を入力し、送信をクリックする」という一連の操作を単一のステップにまとめ、テストが失敗した場合、分かるのは「ログインフローのどこかで問題が発生した」ということだけです。 」としか分かりません。各アクションが独自のステップとなり、それぞれに期待される結果が設定されていれば、失敗の原因はステップ4「『リセットリンクを送信』をクリック → 成功メッセージが表示されるはずが、500エラーが発生した」と特定できます。この正確さにより、開発者はどの機能領域を調べればよいかだけでなく、どの操作が不具合のトリガーとなったかを正確に把握できるため、デバッグ時間が劇的に短縮されます。

何がカバーされていて、何が死角なのかが明確になります。 構造化されたテストケースがなければ、テストカバレッジは推測に過ぎません。テストケースがあれば、すべてのケースを要件に紐付け、ギャップを即座に特定できます。 パスワードリセット機能に6つのシナリオ（リセット成功、リンクの有効期限切れ、リンクの再利用、未登録の電子メール、フォーマット不備、複数回のリクエスト）があり、テストケースが3つしか用意されていない場合、そのギャップは目に見えて定量化可能です。この可視性こそが、テストを「テストした」という段階から、「具体的に何をテストし、何をテストしなかったか、そしてどのようなリスクを受け入れているか」という段階へと引き上げるのです。

優れたテストケースの構成要素

有用なテストケースは、単に何をテストするかを記述するだけではありません。コンテキスト、実行ステップ、および期待されるシステムの挙動を明確に記述することで、他のテスター、開発者、またはプロダクトマネージャーがテストを再現し、結果を検証できるようにします。

テストケースの構成要素は以下の通りです：

前述のWebサイトのログイン機能の例について、テストケースには以下の内容を含める必要があります：

テストケースID： すべてのテストケースには一意の識別子が必要です。機能をテストする際、QAチームは類似した条件を検証する複数のテストケースを作成することがよくあります。テストケースIDがあれば、デバッグやレポート作成の際に、それらを簡単に追跡、整理、参照することができます。

例：TC_LOGIN_001

説明： テストケースがどの機能を検証しているかを説明します。テストケースを読む人がその目的をすぐに理解できるよう、簡潔な要約を記載します。

例：登録済みのユーザーが有効な認証情報を使用して、アプリケーションに成功してログインできることを確認する。

前提条件： 前提条件とは、テストケースを実行する前に必要なシステムの状態を指します。前提条件が定義されていないと、テスターが異なる条件下で同じテストを実行し、結果に一貫性がなくなる可能性があります。

例：

ステップ： これらは、ユーザーやテスターがテストケースを実行するために行う操作です。チーム内の誰もがテストを再現できるよう、各ステップは明確かつ順序立てて記述する必要があります。

期待される結果： これは、機能が正しく動作している場合にシステムがどのような動作をするべきかを定義したものです。

認証情報が無効な場合、システムは適切なエラーメッセージを表示する必要があります。

実際の結果： これらは、テストケースを実行した後のテスターの観察結果を記録したものです。観察された挙動が期待される結果と異なる場合、その問題は問題として登録されます。

観察例：

それでは、テストケース作成のスキルを実際に活用してみましょう。

テストケースの作成方法（ステップバイステップの手順）

テストケースの作成には、要件の分析、シナリオのリスト、構造のプラン、期待される結果を含む手順の作成、コンテキストの添付ファイル、レビューの依頼、そして実行と記録という7つのステップがあります。

ステップ1：要件の分析

テストケースを作成する前に、その機能がどのような動作をするべきかを理解しておきましょう。この段階で、利用可能なドキュメント（PRD（製品要件定義書）、ユーザーストーリー、機能仕様書、設計書など）を確認し、検証が必要なすべての機能を特定します。

例： ユーザーが電子メール経由でパスワードをリセットできる機能を開発しているとします。この機能に関するテストケースを作成するには、以下の点を理解する必要があります：

この明確さこそが、テストケースの明確な目的を定立するための基盤となります。

目的：登録済みのユーザーが、電子メールを介してパスワードを成功裏にリセットできることを確認する。

ステップ2：さまざまなテストシナリオを特定する

次に、検証が必要なテストシナリオをリストアップします。テストシナリオとは、大まかな状況のことであり、通常はさまざまな入力や結果を網羅する複数のテストケースにブランチするものです。

パスワードリセット機能の場合、シナリオは次のようなものになるでしょう：

ここで紹介する各シナリオは、特定の入力や条件を網羅する1つ以上のテストケースに落とし込まれます。このように機能を細かく分解することで、期待される動作だけでなく、実際のユーザーが必然的に遭遇するエッジケースについても、テストカバレッジを確保することができます。

ステップ3：テストのプランとテストケースの構成を設定する

反復的な回帰テストを行うには、テストケースとその結果を一貫して記録できる仕組みが必要です。明確に定義されたテストケーステンプレートがあれば、その一貫性が確保され、毎回一から作成し直すことなく再利用が可能になります。

以下の要素を明確にして、テスト実行のプランを立てましょう：

テストは誰が実施しますか？

このテストを実施する担当者に求められる役割や資格は何ですか？テストの複雑さや必要な人的介入に応じて、役割を割り当ててください：

テストはどのように実施されるのでしょうか？

前提条件は何ですか？

ステップ1の前に満たされる必要があるすべての条件をリストし、それぞれがテスターによって確認できるようにしてください：

例：

どのようなテストデータを使用しますか？

テストを実行するために必要な正確な入力値（有効なデータ、無効なデータ、境界値）を定義します。

例：

ステップ4：テスト手順と期待される結果を作成する

実行プロセスを順次的なステップに分解してください。用語を統一し、各ステップには1つのアクションのみを含めるようにしてください。ステップを定義する際には、期待される結果や、合格・不合格の判定基準についても明記してください。

パスワードリセットのフローをさらに進めると、テストのステップは以下のようになります：

次に、（前述の）代替シナリオについて、ステップと期待される結果を定義します。ユーザーが無効な電子メールを入力した場合や、パスワードが事前に定められた基準に合致しない場合に、どのような動作になるかを記述してください。

ステップ5：関連する添付ファイルを含める

テスターがテストケースを、完全な文脈を理解した上で、曖昧さなく実行できるよう、関連する文書や添付ファイルを含めてください。これには以下が含まれます：

ステップ6：テストケースのレビューを受ける

作成したテストケースを実行する前に、同僚や上級QAリーダーと共有してください。レビューの際には、以下の点を確認してください：

ステップ 7: テストを実行し、結果を記録する

テストを実施し、各期待結果に対して実際の結果を記録します。各ステップごとに、テストを「合格」または「不合格」としてマーク付けします。不合格となったステップについては、直ちにバグを報告し、そのテストケースにリンクを張ってください。さらに、合格・不合格が明確ではない予期せぬ動作が発生した場合は、今後の検討のためにコメントフィールドにその旨をメモしてください。

テストケース作成の例

以下の3つの例は、同じテストケースの構造が、さまざまな種類のソフトウェアテストにどのように適応するかを示しています。いずれも本ガイドの前半で説明した構成要素とステップフォーマットを使用していますが、検証対象に応じて、複雑さ、テストデータ、および失敗モードは異なります。

例 1：Eコマースのチェックアウトフロー（UI、多ステップワークフロー）

あるオンライン小売業者のQAチームは、ホリデーセールに先立ち、チェックアウトの体験をテストしています。そのフローは、カート → 配送 → 支払い → 確認という複数のページにまたがっています。ここでの大きな課題は、状態依存関係です。各ステップは前のステップが正しく完了していることを前提としており、テストデータ（カートのコンテンツ、配送先住所、支払い方法）はすべてのステップを通じて維持されなければなりません。

テスター： Rahul D.

テスト実施日： 2026年9月3日

テストケースID： TC_CHECKOUT_003

説明： ログイン済みのユーザーが、登録済みのクレジットカードと通常配送を利用して購入を完了できることを確認します。

前提条件：

結果の要約： チェックアウトフローはカートから配送までの処理を正しく行っていますが、保存済みのクレジットカードでの支払い処理に失敗します。不具合の記録：決済ゲートウェイの応答に3秒以上かかると、トークン化されたカードの照会がタイムアウトします。

例 2: REST API エンドポイント（UI なし、入出力検証）

あるバックエンドエンジニアが、フロントエンドチームが利用する前に「ユーザー作成」APIエンドポイントをテストしています。クリックして操作するインターフェースはありません。このテストケースでは、リクエストのペイロード、レスポンスコード、およびデータの永続化を直接検証します。ここでの課題は、ユーザー体験ではなく、システム間の契約をテストすることにあります。

テスター： サラ・S.

テスト実施日： 2026年9月5日

テストケースID: TC_API_USER_001

説明： /api/v1/users への POST リクエストにより、新しいユーザーが作成され、正しいレスポンスが返されることを検証します。

前提条件：

結果の要約： このエンドポイントはユーザーを正しく作成し、必須フィールドの検証も行いますが、データベースレベルでの電子メールアドレスの一意性の確保には失敗しています。エラーが発生することなく、重複したレコードが作成されました。この不具合は「重大（High）」として登録されました。

例 3: 役割ベースのアクセス制御（セキュリティ、許可の境界）

セキュリティチームは、コンプライアンス監査に先立ち、アプリケーションがユーザーの役割に基づいてアクションを正しく制限しているかどうかをテストしています。ここでの大きな課題は、機能が動作するかどうかをテストしているのではなく、機能が適切に拒否されるかどうかをテストしているという点です。ほとんどのステップで期待される結果は「成功」ではなく「ブロック」です。

テスター： マーカス・L.

テスト実施日： 2026年9月8日

テストケースID： TC_RBAC_002

説明： 「閲覧者」役割のユーザーが、プロジェクトを作成、編集、削除できないことを検証します。

前提条件：

結果の要約： 閲覧者に対する作成および削除の許可は適切に制限されていますが、編集許可はフィールドレベルで適用されていません。閲覧者は、読み取り専用アクセス権しか持たないにもかかわらず、プロジェクトのタイトルを変更することができます。この不具合は、重大度「重大（コンプライアンス上の障害）」として登録されました。

テストケースの管理にはどのようなツールが最適でしょうか？

テストケースの管理には、専用のQAツール（TestRail、Zephyr）、汎用的なPMツール（ClickUp、Jira）、あるいはスプレッドシートなどが利用できます。どのツールを選ぶかは、組み込みの実行機能が必要か、それとも単に追跡機能だけでよいかによって異なります。

ClickUp

「ClickUp for Software Teams」は、テストケースが関連するスプリント、バグ、プルリクエストと並んでタスクとして管理されるプロジェクト管理プラットフォームです。専用のテスト管理ツールではありませんが、その柔軟なタスク構造により、チームは別のツールを用意することなく、カスタムステータス、フィールド、タスクタイプを使用してテストケースのワークフローを構築できます。

ClickUpの主な機能

ClickUpの制限事項

ClickUpの料金体系

ClickUpの評価とレビュー

実際のユーザーはClickUpについてどのような感想を述べているのでしょうか？

G2のレビュー投稿者からは、次のような声が寄せられています：

ClickUpの最大の魅力は、すべてを一か所に集約できる点です。タスク、タイムライン、メモ、更新情報などがすべて同じシステム内に集約されるため、ツール間の行き来が削減されます。また、その柔軟性も高く評価しています。ステータス、フィールド、ビューを、チームの実際の働き方に合わせてカスタマイズできます。これにより、整理整頓が容易になり、誰が何を担当しているか、またプロジェクトがどの段階にあるかを、いつでも明確に把握できるようになります。

TestRail

TestRailは、テストプロセス全体を体系的に管理する必要があるQAチーム向けに構築された、専用のテスト管理プラットフォームです。テストケースの作成、実行、レポート作成の全サイクルを処理し、DevOpsやCI/CDとの連携により結果を取り込むことができます。

TestRailの主な機能

TestRailの制限事項

TestRailの料金体系

TestRailの評価とレビュー

TestRailについて、実際のユーザーからはどのような声が寄せられているのでしょうか？

G2のレビューアは次のように述べています：

TestRailの最大の価値は、QAチームにテストプラン、テストケース、テスト実行を管理するための、安全で整理された環境を提供してくれる点です。 テストスイートの構築や実装が非常に簡単で、以前に作成したテストケースを再利用できる点も高く評価しています。JiraやCI/CDツールとの連携により、ワークフローの一体感が向上し、進捗の追跡も容易になりました。テストの進捗状況やカバレッジをリアルタイムで監視できる機能は、スプリント計画やレポート作成において非常に役立っています。QAエンジニアとしての日々の業務においても、TestRailを活用することで大幅な時間の節約につながっています。

Zephyr

Zephyrは、SmartBearが提供するJira用テスト管理プラグインであり、Jiraのインターフェース内からテストケースを管理できるように設計されています。手動テストと自動化テストの両方をサポートし、アジャイルチームや企業チーム向けに強力なレポート作成機能とトレーサビリティ機能を備えています。

Zephyrの主な機能

Zephyrのリミット

Zephyrの料金体系

Zephyrの評価とレビュー

実際のユーザーはZephyrについてどのような感想を述べているのでしょうか？

G2のレビューアは次のように述べています：

これは、Excelシートからテストケースを直接インポートするのに最適なツールです。このツールを使用することで、Jiraにテストケースをインポートする場合に比べて、テスターの仕事量が軽減されます。また、テストケースの合否判定や添付ファイルの追加ができる点も、このツールの優れた機能です。

Jira

JiraはAtlassianのプロジェクト管理および課題追跡プラットフォームであり、エンジニアリングチームやQAチームがスプリント、バグ、開発ワークフローを管理するために広く利用されています。専用のテスト管理ツールではありませんが、多くのチームがZephyr ScaleやXrayなどのソリューションと併用し、既存のJiraセットアップ内でテストケースの管理を行っています。

Jiraの主な機能

Jiraの制限事項

Jiraの料金体系

Jiraの評価とレビュー

実際のユーザーはJiraについてどのような感想を述べているのでしょうか？

G2のレビューアは次のように述べています：

Jiraは、私の仕事チームの全メンバーと協力して、すべての業務プロジェクトの進捗状況を追跡・可視化するために私が愛用しているデジタルツールの一つです。同クラスで最高の仮想パフォーマンス機能を備えているため、私のあらゆる業務上の目標を容易に達成できるからです。

テストケース作成時に避けるべきよくある間違い

テストケースの全体的な有効性を低下させる可能性のある、以下の作成上のミスを避けましょう。

テストケースを長期にわたって有用なものに保つ方法

テストスイートが信頼性を維持するには、各テストケースが独立しており、不具合が発生しやすい入力をターゲットとし、信頼できる判定結果が出せなくなった瞬間に廃止されることが重要です。以下の6つの実践方法こそが、何年にもわたってバグを検出できるテストスイートと、2回目のスプリントが終わる頃には無視されてしまうテストスイートとを分ける鍵となります。

独立したアトミックなテストを作成する

テストケースは、それ自体が独自の状態を設定すべきであり、他のケースが先に実行されたことに依存関係はないべきです。TC_CHECKOUT_003 が、TC_CHECKOUT_002 によってカートにアイテムが1つ残されていることを前提としている場合、1つの失敗が5つの失敗へと連鎖し、どの失敗が本物だったのかを特定するために午前中を費やすことになってしまいます。テストタイトルに「および」という単語が含まれる場合は、2つのケースに分割してください。

境界条件でのテスト

バグは、許容される入力の範囲の中央ではなく、その境界付近に集中します。 パスワード入力フィールドが8～128文字を受け付ける場合、単に扱いやすい12文字のパスワードだけでなく、7文字、8文字、128文字、129文字もテストする必要があります。境界値解析がISO/IEC/IEEE 29119-4テスト設計規格における正式な手法として定められているのは、まさにこの理由からです。つまり、ランダムな入力では見逃されてしまう「オフ・バイ・ワン」エラーを発見できるからです。

等価分割を活用して、冗長なテストケースを削減しましょう

システムが同一に扱うべき入力データをグループ化し、各グループから1つの代表的な例をテストしてください。ログインフォームでは、有効な電子メールのフォーマットはすべて同じように動作するため、有効な電子メールは1つで十分です。user@example.com、jane@company.com、bob@domain.orgの3つを別々のテストケースとしてテストすると、カバレッジが向上するわけでもないのに、メンテナンスの負担が3倍になってしまいます。

テストデータとテストステップを分離する

ステップに「enter test@example.com」をハードコーディングすると、テスト環境が変わるたびにそのステップを書き換える必要が生じます。ステップは汎用的な表現（「登録済みの電子メールを入力」）にし、実際の値はテストデータフィールドやファイルに保存しておきましょう。そうすれば、ステージング環境、QA環境、プレプロダクション環境でも編集なしで同じステップを実行でき、ネガティブテスト用の新しいデータセットに切り替えるのも、たった1行の変更で済みます。

不安定なテストや欠陥の見逃し率を追跡する

不安定なテストとは、実際の製品バグがないにもかかわらず、結果が不安定に失敗するテストのことです。このようなテストが繰り返されると、チームは「赤」の結果を無視するようになってしまいます。同一のビルドにおいて、各テストケースが「合格」と「不合格」の間をどれくらいの頻度で揺れ動くかを追跡しましょう。1か月に数回以上結果が不安定になるテストケースがある場合は、書き直すか削除してください。これを「欠陥見逃し率」（テストケースで検出されるべきだったにもかかわらず、本番環境で発見されたバグ）と組み合わせて分析することで、単にノイズが多い箇所だけでなく、カバレッジが不十分な箇所を特定することができます。

頻繁に実行するテストを自動化しましょう

回帰テスト、スモークテスト、および高頻度の機能テストは、ビルドのたびに実行され、変更されることがほとんどないため、自動化に最も適しています。これらをCI/CDパイプライン内のスクリプトに移行し、UI要素の位置が頻繁に変化する箇所では、自己修復型ロケーターを備えたAI支援ツールを活用しましょう。そうすることで、人間のテスターは探索的テストや、ユーザビリティやエッジケースの発見など、判断力を要する種類のソフトウェアテストに注力できるようになります。

ClickUpでのテストケースの作成と実行方法

上記の「ツール」セクションでは、ClickUpの活用場面について解説しました。このセクションでは、本ガイドの前半で説明したステップに沿って、実際のセットアップ方法をご紹介します。

テストケースライブラリを体系的に整理しましょう。 製品用の「スペース」、各機能領域（例：認証、決済、オンボーディング）ごとの「フォルダ」、そして各テストサイクルやスプリントごとの「リスト」を作成します。各タスクは個別のテストケースとなります。ClickUpのカスタムフィールドを使用して、テストケースID、前提条件、テストデータ、優先度、環境などの情報を記録しましょう。

テスト手順はタスク内に直接記述しましょう。 タスクの説明欄を使用して、順次実行されるステップと期待される結果を文書化します。チェックリストは、テスターが各アクションにチェックを入れる必要がある段階的なフローに適しており、一方、説明欄には前提条件やテストデータなどの背景情報を記載します。

実行状況と結果を追跡しましょう。 テストワークフローに合わせたカスタムステータスを作成します：未開始 → 進行中 → 合格 → 不合格 → ブロック中。テストが不合格になった場合は、それをバグタスクに変換するか、優先度、依存関係、期限を設定して開発者に割り当てられたリンクされたタスクを作成します。 GitHubおよびGitLabとの連携機能により、そのバグを原因となったプルリクエスト（PR）に直接リンクさせることができます。根本原因がコードの欠陥である場合は、そのバグタスクをClickUp Codegen Agentに割り当てることができます。このエージェントは、タスクの説明、リンクされている仕様書、コメントを読み取り、修正案を作成し、レビュー用のプルリクエストを開くとともに、進捗状況をタスクにフィードバックします。

プロのヒント：QAリーダーは、ClickUp Brainに未解決のバグタスクの要約を依頼することで、あらゆるタスクの状況を即座に把握できます。これにより、個々のタスクを一つひとつ確認して状況を把握する必要がなく、スプリントレビューに必要なすべての背景情報を手に入れることができます。

ビューを活用してテストサイクルを実行しましょう。 ステータス別にグループ化された「ボードビュー」を使用すれば、テスト実行中の合格・不合格の分布を一目で確認できます。「テーブルビュー」は、数十件のテストケースの結果を一覧で確認したい場合に、従来のテストマトリックスとして機能します。担当者を基準にフィルタリングして作業負荷を分散させたり、優先度を基準にフィルタリングして、クリティカルパスを優先的にスモークテストしたりすることも可能です。

ClickUpの「テスト管理テンプレート」を使えば、複数の機能領域、テストシナリオ、エッジケースにわたるテストワークフロー全体を、1か所で一元的に管理できます。このテンプレートを活用すれば、ツールを切り替えることなく、ユーザーフィードバックの追跡、テストスケジュールの管理、テスト進捗の監視、および合格/不合格結果の評価を行うことができます。

無料テンプレートを入手する

テストワークフローを効果的に管理する

テストケースは、2人の担当者が独立して実行し、同じ「合格」または「不合格」の結果を得られた瞬間に、その価値が認められます。このガイドで解説しているすべての内容（1ステップにつき1つのアクション、明確な前提条件、解釈の余地のない期待される結果）は、この単一の基準を満たすためにあります。すでにClickUpでスプリントをプランしている場合、前述のセットアップを行えば、別のツールを追加することなく、テストケースの作成、実行、追跡を、それによって発見されたバグと併せて行うことができます。

ClickUpに無料で登録する

テストケースに関するよくある質問

1つの要件に対して、テストケースはいくつ用意すべきでしょうか？

1つの要件に対して、含まれるシナリオ、エッジケース、入力のバリエーションの数に応じて、1つのテストケースで済む場合もあれば、10個必要になる場合もあります。重要なのは、現実的なすべての経路を網羅し、冗長性を排除しつつ十分なカバレッジを確保することです。

テストケースとテストスクリプトの違いは何ですか？

テストケースとは、何をテストし、どのような結果が期待されるかを記録したもので、手動で実行するために作成されます。一方、テストスクリプトは、その自動化されたバージョンであり、同じステップをプログラムによって実行するコードのことです。

テストステップはどの程度詳細に記述すべきでしょうか？

テストを、事前の背景知識がなくても容易に追えるような、論理的で順序立ったステップに分割してください。複数のアクションをまとめて処理したり、不必要な複雑さを加えたりしないでください。

テストシナリオは、1行で「何を」テストするかを記述します（「パスワードのリセットを確認する」など）。一方、テストケースは、前提条件、ステップ、テストデータ、期待される結果を用いて、「どのように」テストするかを具体的に指定します。通常、1つのシナリオから、正常な処理、無効な入力、境界条件を網羅する3～10個のテストケースが生成されます。シナリオが先に行われ、カバレッジプランを推進し、テストケースが後に続き、実行を推進します。

肯定的テストケースでは、有効な入力を使用し、成功を期待します。たとえば、正しい電子メールとパスワードを入力すると、ユーザーがログインします。否定的なテストケースでは、無効または予期しない入力を使用し、システムが適切に失敗することを期待します。たとえば、間違ったパスワードを入力すると、セッションが確立されることなく「パスワードが無効です」と表示されます。成熟したテストスイートでは、肯定的テストケースと否定的なテストケースの比率は、おおむね1:3から1:5となります。これは、本番環境のバグのほとんどが「ハッピーパス」ではなく「エラーパス」に存在するためです。

テストプランとは、テスト活動全体の範囲、アプローチ、リソース、スケジュールを定義するものです。テストスイートとは、「リリース 2.1 用の回帰テストスイート」のように、1回の実行のためにグループ化されたテストケースの集合です。テストケースは、これら両方の構成要素となる最小単位であり、1つの文書化されたチェック項目と、合格／不合格の1つの結果で構成されます。プランは戦略を定め、スイートは範囲を定め、ケースは判定を決定します。