効果的なテストケースの書き方（テンプレート付き）

Hannah Son著

テストケースはソフトウェアテストの基本的な要素であり、特定の機能やソフトウェアアプリケーションの要件が期待どおり動作していることを検証するための一連の手順を文書化したものです。

テストケースは、テストが始まる前に各テストシナリオの対象、方法、期待される結果の概要を説明する設計図として機能します。

効果的なテストケースの書き方
- テストケース作成時に考慮すべき要素
テストケースのキー要素
テストケースのテンプレート
テストケース作成のベストプラクティス
テストケース: FAQ
関連する製品
- テスト管理ツール TestRail
  - ■ TestRailの特長 ■

効果的なテストケースの書き方

効果的なテストケースは、漏れがなく効果的なソフトウェアテストプロセスの根幹です。適切にテストケースを作成できれば、以下が可能になります。

テストをする前に、何をテストするべきかを戦略的に計画し、テスト方法の概略を作成できます。
テストの前に満たす必要がある事前条件などの重要な詳細を提示し、正確なテスト実行のためのサンプルデータを用意することで、テストをより効率的にします。
テストカバレッジの正確な計測とモニタリングを行い、アプリケーションの必要な側面がすべて徹底的に検証されるようにします。
テストの期待される結果との実際の結果を比較し、ソフトウェアが意図されたとおり動作しているかを検証します。
過去のテストの信頼できる記録を維持し、レグレッション/欠陥を捕捉したり、ソフトウェアのアップデートが予期しない問題を入り込ませていないことを確認したりできるようにします。

テストケース作成時に考慮すべき要素

効果的なテストケースを作成するには、以下の４つの必須要素を考慮します。

1.テスト対象の機能を特定する

ソフトウェアのどの機能をテストする必要があるかを決定します。たとえば、Webサイトの検索機能をテストする場合、重点的なテスト対象領域として検索機能を指定します。機能を明確に定義することで、テストケースがソフトウェアの適切な側面をターゲットとしていることを保証できます。

2.テストシナリオを抽出する

テストによって機能のあらゆる側面を検証できるシナリオの概略を作成します。たとえば、Webサイトのログイン機能をテストする場合、考えられるテストシナリオには以下のようなものがあります。

有効な認証情報または無効な認証情報でログインする。
ロックされたアカウントでログインを試みる。
有効期限切れの認証情報を使用する。

ポジティブシナリオおよびネガティブシナリオの両方について期待される結果を確定します。たとえば、有効な認証情報を使用してログインが成功した場合、ユーザーは自身のアカウントページにリダイレクトされるいっぽう、無効な認証情報を使用した場合はエラーメッセージが表示され、アクセスが拒否されるなどです。

3.テストデータの抽出

各テストシナリオを実行し、評価するために必要なデータを特定します。たとえば、無効な認証情報を使用したログインをテストするシナリオでは、テストデータには誤ったユーザー名およびパスワードの組み合わせなどがあるでしょう。適切なテストデータは、シナリオが現実的で再現可能であることを保証します。

4.テストアプローチを決定する

機能、シナリオ、データを定義したら、テストの戦略的アプローチを策定します。以下の点を考慮します。

新機能であれば、特定の機能を確認する詳細なテスト手順を記述する必要があるかもしれません。たとえば、E-コマースサイトでの新しいチェックアウトプロセスをテストする場合、アイテムをカートに追加する、届け先情報および請求情報を入力する、注文を確定するなどの手順が必要です。
テストが探索的テストまたはユーザーの受け入れにフォーカスしたテストであれば、テストチャーターまたはミッションステートメントで十分な場合もあります。たとえば、新規モバイルアプリ機能のユーザー受け入れテストでは、ログインプロセスがユーザーフレンドリーでエンドユーザーのニーズを満たしているかを検証することなどがミッションになります。

テストケースのキー要素

テストケースを作成する際、特にアジャイル手法では、テストケースは厳密な手順の指示というよりは、概要説明として機能します。すべてのテストケースには、テストプロセスを明確かつ構造化されたものにするためのキー要素が含まれるべきです。以下はテストケースの7つの必須要素です。

1.タイトル

タイトルはテスト対象機能を明確に示すべきです。具体的かつ簡潔なタイトルは、テストケースの目的をすばやく判別するのに役立ちます。

2.説明（テストシナリオを含む）

説明は、テストの目的を簡潔に記述するべきです。説明は、検証するソフトウェアの側面の概要を示し、ひと目でテストケースの目的を把握できるようにします。

3.テストスクリプト（自動化される場合）

自動テストのコンテキストでは、テストスクリプトは各機能テストを実行するのに必要な一連の詳細なアクションおよびデータを提供します。スクリプトは、複数の実行にわたってテストが一貫して行われることを保証します。

4.テストID

すべてのテストケースには標準化された命名規約に従った固有の識別子、つまりテストIDが必要です。テストIDは、特に大量のテストケースを管理する場合に、テストケースの参照、整理、追跡を容易にします。

5.テスト環境の詳細

テスト環境は、その中でソフトウェアがテストされる一定のセットアップまたはインフラを記述します。環境には、ハードウェア、ソフトウェア、ネットワーク構成、テストの結果に影響を与える可能性があるその他の条件が含まれます。

6.期待される結果

このセクションは、テストにどのような結果が期待されるかの概要を明確に記述します。期待される結果を文書化することで、テスターは実際の結果と比較し、ソフトウェアが意図のとおり動作しているかを容易に判断できます。

7.注釈

注釈セクションには、他のカテゴリには当てはまらないが、テストケースを理解または実行するうえで重要な付加的コメントや関連情報を記載します。特別な指示、注意事項、以前のテストで得られた洞察などが該当します。

テストケースのテンプレート

テストケースのテンプレートは、テストケースを体系的に文書化、管理、実行することを可能にします。テンプレートは一貫性を保証し、効率を改善し、テスト作業と組織の標準や要件との整合性を確保します。

TestRailはさまざまなプロジェクトやテストスイートで再利用可能な柔軟なテストケーステンプレートを備えています。特定のテスト手法やプロジェクト要件に合わせたテンプレートのカスタマイズも可能なTestRailは、テストプロセス全体にわたって組織を維持するための強力で適応性の高いツールです。

以下は、TestRailにデフォルトで用意されているカスタマイズ可能な４つのテストケーステンプレートです。

テストケース(テキスト):

***画像:*** *特定のケースをテストするためにテスターが行う必要がある手順を比較的自由に記述できる柔軟なテンプレートです。*

テストケース(手順):

***画像:*** テストの各手順に個々に結果ステータスを追加したり、手順ごとに欠陥、要件、その他の外部エンティティにリンクしたりできるテンプレートです。この特徴により、可視性、構造、トレーサビリティが強化されます。

探索的セッション

***画像:*** *TestRailの探索的セッションテンプレートは、ミッションおよび目的を定義できるテキストフィールドを使用し、探索的テストセッションのガイドとなります。*

ビヘイビア駆動開発（BDD）

**画像:** TestRail内で直接BDDシナリオを設計し、実行できるテンプレートです。ユーザーはテストをシナリオとして定義することもできます。通常、BDDのシナリオは、Given-When-Then (GWT)フォーマットに従います。

これらのテストケーステンプレートを使用することで、テストケースの作成、実行、分析を容易にする標準化されたフォーマットを作成できます。フォーマットが統一されることで、テストシナリオに必要な情報および手順を確実に文書化できるため、テストプロセスがより効率的で整理されたものになります。

テストケース作成のベストプラクティス

効果的なテストケースを作成することは、品質の高いソフトウェアの維持にとって非常に重要です。以下はテストケース作成時に考慮するべきベストプラクティスです。

1.テストケースに優先順位を付ける

まず、テストケースの重要性およびソフトウェアに与える潜在的影響に基づいてテストケースに優先順位を付けます。ルール化された優先順位付けの方法を利用すると、最初に作成および実行するべきテストケースを判断するのに役立ちます。下記のようなテクニックを検討します。

リスクベースの優先順位付け
履歴ベースの優先順位付け
カバレッジベースの優先順位付け
バージョンベースの優先順位付け
コストベースの優先順位付け

たとえば、E-コマースアプリケーションでは、消費税が正しく計算されることを検証するテストケースは、ボタンの色をチェックするテストケースより重要であり、優先度が高いでしょう。

2.テストケースを明確でわかりやすくする

テストケースは簡潔でわかりやすく、テストチームの誰でも容易に達成すべき目的を理解できなければなりません。

必要に応じて添付ファイル、画面ショット、録画を含めることでより明確にします。たとえば、ログイン機能をテストする場合、テストケースは手順、使用する認証情報、期待される結果(ユーザーダッシュボードが正常に表示されるなど)を明確に記述する必要があります。

また、直感的にわかりやすく、参照しやすいテストケース名を使用します。効果的な命名規約は、特に何千ものテストケースを管理する場合には重要です。

再利用可能なオブジェクトに関するテストケースに名前を付ける際は、再利用可能であるという情報をタイトルに組み込むことを検討します。さらに、事前条件、添付ファイル、テスト環境データに関する詳細をテストケースの説明で文書化します。

3.期待される結果を指定する

期待される結果を明確に定義することは、テストを正しく実行し、ソフトウェアが期待どおり動作していることを確認するうえで重要です。期待される結果は、実際の結果と比較されるベンチマークとして機能します。

たとえば、ショッピングカート機能をテストする場合、期待される結果には、選択されたアイテムがカートに正常に追加されること、またカートが正しい値段を表示することなどが指定されるでしょう。

4.ハッピーパスとアンハッピーパスの両方をカバーする

ソフトウェア要件を最大限にカバーするため、多様なシナリオに対応するテストケースを作成します。

ハッピーパスとは、ユーザーが通常実行する一般的なアクションです。反対に、アンハッピーパスとは、ユーザーが予期しない操作をするシナリオを表します。両方のシナリオをカバーすることで、適切なエラー処理が行われ、ユーザーが誤ってソフトウェアを壊すことがないよう保証できます。

たとえば、E-コマースサイトの検索機能では、特定の製品が見つかるケースなどがハッピーパスになるでしょう。アンハッピーパスは、存在しない製品の検索などであり、適切なエラーメッセージが表示されることを検証します。

5.定期的にテストケースを見直して更新する

チーム内で継続してテストケースを見直して更新します。製品の拡大に伴って、テストケースを更新して要件や機能の変化を反映する必要があります。この作業は、機能追加や機能拡張などの大きな変化の最中にある製品では、特に重要です。

また、ピアレビューはテストケースの不足や矛盾、エラーを検出し、テストケースが要求される基準を満たしていることを保証するのにも有効です。

たとえば、E-コマースサイトの支払いゲートウェイプロバイダーを変える場合、既存のテストケースを見直して更新し、新しいプロバイダーでも必要なすべてのシナリオを確実にカバーしていることを確認する必要があります。

***画像:*** *TestRailの直感的なインターフェイスでは、テストケースの事前条件、テスト手順、期待される結果、優先度、作業見積りを入力するだけで、テストケースを簡単に作成し、整理することができます。*

効果的なテストケースの作成と管理は、ソフトウェアテストを成功させるのに必須です。ベストプラクティスに従い、TestRailのような専用のテストケース管理ツールを使用することで、高品質のソフトウェアをデリバリーするのに必要なレベルの構造と詳細を達成できます。TestRailのカスタマイズと再利用が可能なテストケーステンプレートは、テストケースを文書化するための事前定義済みフォーマットも提供するため、テストの作成、実行、分析が容易になります。

このようなレベルの柔軟性と可視性をテストプロセスにもたらすことによって、TestRailはどのような組織のテスト計画にも容易に組み込むことができます。テスト計画にどのように役立つか、TestRailの無償評価版でご確認ください。

テストケース: FAQ

テストケースの利点

テストケースには、柔軟性、コラボレーション、変化への適応性というアジャイル手法の原則に合致するいくつかの利点があります。以下は主な利点です。

認識の共有: テストケースは、ユーザーストーリーまたは機能に関する文書化された明確な要件と受け入れ条件のセットになります。これにより、何をテストする必要があるかについて、開発者、テスター、プロダクトオーナーを含めたチーム全員が共通の認識を持つことができます。
効率性: 事前に定義されたテストケースがあると、テストの効率が向上します。何をどのようにテストするかをテスターが都度判断する必要がありません。確立されたテストケースに従うことで、時間と労力を節約できます。
レグレッションテスト: アジャイル開発ではコードが頻繁に変更されます。テストケースは変更のたびに実行するべき構造化されたテストのセットを提供し、新しいコードの変更がレグレッションを入り込ませていないかを確認するのに役立ちます。
再利用性: テストケースは、特に共通のシナリオを対象としている場合、複数のスプリントまたはプロジェクトで再利用可能です。このような再利用性は、似た機能をテストする際に一貫性を促進し、時間を節約します。
トレーサビリティ: テストケースはユーザーストーリー、要件、テスト実行の間のトレーサビリティを確立します。トレーサビリティは、すべての要件がテストされたことを確認するのに役立ち、レポートに透明性をもたらします。
ドキュメント: テストケースはテスト作業のテスト文書として機能します。テストケースはテストシナリオ、手順、期待される結果を表しているため、進捗の追跡と要件を満たしていることの証明が容易になります。
適応性およびフィードバックの加速: アジャイルは早期の継続的テストを重視します。また、チームは変化する要件や優先順位に対応する必要があるのが普通です。テストケースはソフトウェア開発ライフサイクルの早い段階で問題や欠陥を検出するのに役立つほか、すばやくフィードバックを返し、修正アクションを行うために随時更新または作成できます。
継続的改善: アジャイルは継続的改善のカルチャーを奨励します。テストケースおよびテスト結果は、振り返りに役立つデータを提供し、テストプロセスを拡張するべき領域を判断するのに役立ちます。
顧客満足: 効果的なテストは、ソフトウェア品質とユーザーエクスペリエンスの向上につながります。適切に文書化されたテストケースは、顧客の期待を満たす、あるいは顧客の期待を超える製品のデリバリーに貢献します。

テストケースを適切に作成し使用すると、コラボレーションの促進、テストサイクルの加速、ソフトウェア製品全体の品質向上につながり、結果として、顧客を重視しながら品質の高いソフトウェアを繰り返しデリバリーすることが可能になります。

テスト種類によるテストケースの違い

テストの種類が異なれば、特有のテスト目標に対応するために、異なるタイプのテストケースが必要になる場合もあるでしょう。次の表は、さまざまなソフトウェアテスト手法に対応する一般的なテストケースの分類です。

テストの種類	テストケースの種類	説明
機能テスト	単体テストケース	個々の関数またはメソッドを単体でテストし、期待どおり動作しているかを検証します。
	統合テストケース	さまざまなコンポーネントやモジュールを統合したときに正しく協調動作しているかを検証します。
	システムテストケース	システムまたはアプリケーション全体が特定の機能要件を満たしているかを検証します。
	ユーザー受け入れテスト(UAT)ケース	エンドユーザーまたはステークホルダーが関与して、システムがニーズや期待を満たしていることを確認します。
非機能テスト	パフォーマンステストケース	スピード、応答性、スケーラビリティ、安定性などの側面を評価します。
	負荷テストケース	同時実行ユーザー数やデータ負荷など、特定の負荷状況でのシステムの動作を評価します。
	ストレステストケース	システムを極限状態に置き、障害点やパフォーマンスのボトルネックを検出します。
	セキュリティテストケース	システムのセキュリティ対策および脆弱性を評価します。
	ユーザビリティテストケース	ユーザーフレンドリーかどうか、直感的に操作できるか、全体的なユーザーエクスペリエンスを評価します。
	アクセシビリティテストケース	障害を持つユーザーがソフトウェアを利用できるか、アクセシビリティ標準を満たしているかを確認します。
レグレッションテスト	レグレッションテストケース	新しいコードの変更またはアップデートが既存の機能にマイナスの影響を与えていないかを検証します。
	スモークテストケース	基本的なテストケースのセットを短時間で実行し、ソフトウェアのビルドがさらにテストを行う対象として十分に安定しているかを評価します。
探索的テスト	探索的テストケース	テスターは事前定義されたスクリプトなしにソフトウェアを探索し、直感と経験に基づいて欠陥や問題を検出します。
互換性テスト	ブラウザー互換性テストケース	複数のWebブラウザーおよびバージョンでソフトウェアの互換性をテストします。
	デバイス互換性テストケース	複数のデバイス（デスクトップ、モバイル、タブレット）でソフトウェアのパフォーマンスを評価します。
統合テスト	トップダウンテストケース	アプリケーション階層の最上位からテストを開始し、徐々に下位レベルのコンポーネントを統合します。
	ボトムアップテストケース	下位レベルのコンポーネントからテストを開始し、徐々に上位レベルのモジュールを統合します。
受け入れテスト	アルファテストケース	社内の開発チームまたはテスト専任のチームで実施します。
	ベータテストケース	外部ユーザーまたは一部の顧客のグループが参加し、現実的なシナリオでソフトウェアをテストします。
負荷テストおよびパフォーマンステスト	負荷テストケース	指定された同時実行ユーザー数またはトランザクション数をシミュレートし、典型的な負荷状況下でのソフトウェアのパフォーマンスを評価します。
	ユーザビリティテストケース	タッチジェスチャー、画面遷移、全体的なユーザーエクスペリエンスを評価します。

テストケース作成時に避けるべきよくある誤り

効果的なテストケースの作成は、ソフトウェアテストの成功に欠かせません。テストケースを効果的で効率的なものにするには、よくある誤りを避けることが重要です。以下は注意するべきよくある誤りの代表例です。

目的が明確ではない: すべてのテストケースに明確で具体的な目的があり、何をテストして何を達成するべきかの概略が示されていることを確認します。
テストのカバー範囲が不完全: 重要なシナリオを取りこぼさないようにします。テストケースが広範囲の入力値、条件、エッジケースをカバーしているかを確認します。
テストケースが複雑すぎる: テストケースをシンプルに保ち、1つの側面またはシナリオだけにフォーカスすることで明確さを維持します。
独立していない: 複数のテストケース間の依存関係を避けます。依存関係があると、問題を個別に分離して特定するのが難しくなります。
事前条件の定義が不十分: テストケースを実行する前に満たす必要がある条件を明確にし、結果の一貫性を確保します。
事前知識を前提にしている: システムに慣れていない新しいチームメンバーを含め、誰でも理解できるようにテストケースを作成します。
ネガティブシナリオを考慮していない: ポジティブケースだけでなく、無効な入力やエラー処理などのネガティブシナリオもテストします。

ベテランテスター向けの上級ヒント

テスト戦略を強化したいと考える経験豊富なテスターは、以下を検討してみてください。

1.データ駆動型テストを取り入れる

データ駆動型テスト(DDT)では、複数のデータセットを使用して1つのテストケースを実行します。この手法は、さまざまな入力値を検証するのに有効であり、特にSeleniumなどの自動化ツールを使用する場合に適しています。複数のデータセットとの統合が容易な構造化されたテストケースフォーマットを作成すると、幅広いカバレッジを実現できます。

2.テストケースの再利用性を高める

再利用性を考慮してテストケースを設計します。一意のテストケースIDで識別可能なモジュール化されたテストケースは、別のテストシナリオでも再利用できます。たとえば、ログイン機能を検証するUIテストケースは、別のユーザーロールやセキュリティシナリオにも流用できるため、手動テストと自動テストの両方の効率を改善します。

3.ビヘイビア駆動型開発(BDD)手法を適用する

ビヘイビア駆動型開発は、エンドユーザーの視点を重視します。Given-When-Thenフォーマットを使用して、現実のユースケースを反映した機能テストケースを作成します。このアプローチは、テストケースとユーザー要件の整合性をとり、ステークホルダー間のコラボレーションを促進します。

4.テストケース管理ツールを効果的に利用する

TestRailなどの高機能なテストケース管理ツールは、基本的な管理以上の機能を備えています。カスタムフィールド、詳細なレポート、Seleniumをはじめとするテスト自動化ツールとの統合などの機能を調査しましょう。これらの機能を利用すると、より深い洞察を得たり、手動テストおよび自動テストの両方の管理を合理化したりできます。

5.テスト自動化戦略を実装する

繰り返し実行され、影響の大きいテストケースを自動化し、効率を改善します。レグレッションテストや重要なユーザーインターフェイス(UI)テストなど、最大の価値が得られるテストケースを重点的に自動化します。自動化されたテストケースが適切にメンテナンスされ、アプリケーションの変更に合わせて確実に更新されるようにします。