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

金融サービスでは「メーカー・チェッカー・プロセス」と呼ばれる。リスク管理では、一般に『4つの目の原則』と呼ばれている。米国の核兵器の管理では、『2人コンセプト』と呼ばれている。

要するに、どれもやることは同じである。これらのプロセスには、アウトプットの正確性、品質、または妥当性を保証するために、評価、確認、著者、または承認の追加レベルが含まれる。

ソフトウェア開発では、これをテストまたは品質保証と呼ぶ。簡単に言えば、ソフトウェアテストは、コードが期待通りに仕事をしているかどうかを評価するものである。この活動を効果的に行うために、品質チームはテストケースと呼ばれる強力なツールを使用する。

このブログポストでは、テストケースとは何か、なぜ必要なのか、いつ使うのか、そして最も重要なこととして、テストケースの書き方を探ります。

テストケースとは何か？

テストケースとは、ソフトウェアアプリケーションの品質を評価するために使われる、アクション、設定条件、入力データの設定です。

例えば、ニュースレターのサブスクリプションのために、ユーザーの名前と電子メール ID を取得するフォームを作ったとしましょう。そのテストケースは、次のように指定します：

Actions [both user-facing and internal]：ユーザーまたはソフトウェアが、構築中のソフトウェアでワークフローを完了するためにやることすべて。

• ユーザーが名前を入力する。
• ユーザーが電子メールを入力する。
• ユーザーが'Submit'をクリックする。
• ユーザーに確認電子メールが送信される。
• データが対応するデータベースに保存される
• それぞれのニュースレター電子メールリストにデータが追加されます。

条件：ユーザーまたはシステムがアクションを実行する際に満たすことが期待される要件。

• 名前フィールドのバリデーションが承認されれば保存し、そうでなければエラーメッセージを表示します。
• 電子メール・アドレス・フィールドのバリデーションが承認されれば保存し、そうでなければエラーメッセージを表示する。
• ユーザーが電子メールを確認した場合のみ、ニュースレターリストに追加します。
• ユーザーが既に存在する場合、対応するエラーメッセージを表示する。

入力データ：入力データ：その機能で受け入れられる入力のサンプル。通常、品質保証[QA]チームは、肯定的な結果と否定的な結果をテストできるテストデータを作成する。

例えば、名前フィールドのバリデーションの条件が「アルファベットとスペースのみを含むことができる」である場合、テストデータは次のようになります。

• Jane Doe、これは条件を満たしている。
• Ad@m Sand!

ソフトウェア工学におけるテストケースの役割

テストケース手法は、ソフトウェアテストに対する、包括的で、体系的で、反復可能なアプローチです。その主な目的は、アプリケーションの品質を保証することですが、ソフトウェアエンジニアリングプロセス自体に、複数のレ ベルの堅牢性と信頼性を追加します。

✅ 不具合の特定：テストケースは、ソフトウェアの不具合を特定するのに役立ちます。テストケースは、アプリケーションが生産性へ移行しても安全であるかどうかを決定します。

✅ 要求の検証：テストケースは、あなたが構築したものが、あなたが最初から意図していたものであることを保証します。これは、あなたが、特定の要求事項を持つ外部の利害関係者のためにソフトウェアを構築するサービス組織である場合、特に重要です。

リスクを軽減する：テストケースは、セキュリティ、パフォーマンス、財務リスクについて機能を評価する。品質アナリストは、規制遵守、業界標準などに関する条件も含めて、すべてのベースがカバーされていることを確認する。

✅ 全体像のバランスをとる：新機能は単独ではうまくいくかもしれない。しかし、ソフトウエアの他の部分と統合すると、その機能が壊れたり、他の機能を壊したりする可能性があります。テストケースは、生産性においてユーザーエクスペリエンスに影響を与える前に、これを確実に捕捉します。

つのテストケースで、上記のすべてをやることができるでしょうか？そうではない。機能、ソフトウェア、システム、ニーズ、組織の目標によって、QAチームが書くテストケースにはいくつかの種類がある。

テストケースの種類

テストケースは

/にはそれぞれテストケースがある。 https://clickup.com/ja/blog/197374/types-of-software-testing/ ソフトウェアテストの種類 /テストケース

.よく使われるものをいくつか挙げると、以下のようになる。

機能テストケース：この基本的で基礎的なテストケースは、ソフトウェアが意図したとおりに仕事するかどうかを評価します。最低限、すべてのQAがこれを書く。

ユニットテストケース：単体テストは、機能の一部または単一のユニットを評価します。例えば、QAは電子メールフィールドが様々な条件を満たしていることを検証するためにユニットテストを書くかもしれません。

セキュリティテストケース：これは、機能が本番稼動するためのセキュリティ基準を満たしているかどうかを評価します。通常、これには、著者認証、認証、OWASP標準への準拠などのテストが含まれます。

パフォーマンステストケース：これは、新機能がスピード、信頼性、スケーラビリティ、リソース利用などの要件を満たしているかどうかを検証する。

回帰テストケース：リグレッションテストでは、開発した新機能が製品内の既存機能に影響を与えないことを確認します。

これらに加えて、特定のテストケースを実行することもできる。例えば、デザイン主導の組織では、ユーザーインタフェース[UI]テストケースを含めるかもしれません。より大きなワークフローの一部を実行する生産性では、多くの統合テストケースを書くかもしれません。また、ヒューリスティックス、アクセシビリティ、インクルージョンなどに関する特定のユーザビリティ・テストケースを作成する場合もあります。

プロダクト所有者として、あなたはソフトウェアがやることを決定し、それに該当するテストケースを作成することになります。あなたにとって重要なすべてのシナリオをカバーしなければなりません。

テストケースは単にテストシナリオということでしょうか？そうではありません。

テストケースとテストシナリオ

テスト・ケースは、新しい機能がどのように動作すべきかの包括的な記録です。テストシナリオとは、どのようなアクションが起こる可能性があり、どのようにテストされ るかを高レベルで記述したものです。

前の例を拡張すると、テストシナリオは "ニュースレターのサブスクリプションをテストする "となります。しかし、テストケースは

• 許容可能な名前を持つ名前フィールドをテストする。
• 特殊文字を含む名前フィールドのテスト
• 有名人の名前フィールドのテスト
• 番号を含む名前フィールドのテスト
• John Doeのようなプレースホルダーや架空の名前のフィールドをテストする。

テストケースとテストシナリオの違い

違いがわかったところで、テストケースにフォーカスを戻し、ズームインしてみましょう。

テストケースの構成要素

要約すると、テストケースとは、ソフトウェアが意図したとおりに動いていることを保証するために、 テストする必要があるすべてのことを詳細に文書化したものです。そのため、テストケースは包括的で、粒度が細かく、多面的であり、複数の構成要素を含んでいます。

テストケースの重要な構成要素には、次のようなものがある：

テストケース ID：すべてのテストケースには番号があります。これは単純に聞こえるかもしれませんが、アプリケーションを徹底的にテストするためには、似ているような様々なテス トを実施することになります。テストケース ID は、それらを区別するのに役立ちます。

説明：テスト対象の説明。上の例では、"ニュースレターのデータベースに、実際に利息のある見込み客を追加する "といった具合です。

前提条件：前提条件：この機能を使用するために満たすべきすべての前提条件。例として、上記の各フィールドのバリデーションについて説明しました。それに加えて、他の条件が含まれるかもしれません：

• ユーザーがすでにニュースレターを購読していないこと。
• ユーザーがニュースレターの購読を解除していないこと。

ステップ：ステップ: 評価を完了し、成功にマークするためにユーザーまたはシステムが従うべきステップ。

• ユーザーが有効な名前を入力する。
• ユーザーが有効な電子メールIDを入力する。
• ユーザーがプライバシーチェックボックスをチェックします。
• ユーザーが送信ボタンをクリックします。

期待される結果：システムが次にやることのリスト。

• ユーザー名が無効な場合、エラーメッセージを表示します。
• 電子メールIDが無効な場合、エラーメッセージを表示する。
• ユーザー名と電子メールIDが有効な場合、それぞれのデータベースに保存します。
• データベースに保存したら、ユーザーに確認の電子メールを送信する。

実際の結果：実際の結果: テストケースを実行した後のテスト者の観察結果です。この結果は、何かがうまくいかない場合に開発者に送り返されます。

• Katy P3rryでnameフィールドをテストしたら、有効な入力として受理された。

これで、効果的なテストケースを書くための設定は完了です。その方法を説明します。

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

良いテストケースを書くには、ビジネスロジックと技術的な洞察力の両方が必要です。デジタルの世界での技術的な視点だけでなく、現実世界でのユーザーの視点からも理解する必要があります。以下は、あなたがその旅を始めるための強固なフレームワークです。

1.テストシナリオを特定する

テストケースを書く前に、その機能が実際に使われるシナリオを理解しましょう。ユーザーストーリーを読んだり、要件ドキュメントを研究したり、あるいは開発者と仕様について議論したりしましょう。

例えば、前の例のテストシナリオは次のようになります：ユーザーがニュースレターの購読に成功する。

このステップでは、要件文書にユーザーが具体的に記述されているかどうかを確認することが重要です。

例えば、有料ユーザーだけを対象としたニュースレター機能を作成する場合、非有料ユーザーが購読しようとするシナリオが考えられます。

ですから、要件、仕様、ユーザーストーリーに徹底的に目を通しましょう。

2.テストケースのオブジェクトを定義する

このフェーズでは、テストを実行することで何を達成したいのかを定義します。例えば、機能がプラン通りに動いているかどうかをテストするだけなら、機能テストケースを書くでしょう。

しかし、セキュリティやパフォーマンスも必要であれば、それに対応するテストケースも書くことになります。こうすることで

/参照 https://clickup.com/ja/blog/11186/agile-testing/ アジャイルテスト /%href/

プロセスを実行し、結果を開発チームに提示する。

3.明確で簡潔なステップを書く

このフェーズは、ワークフローの概要を説明するだけではない。その機能が期待通りに機能することを保証するためにQAがやることすべてである。

徹底してください：できるだけ詳細に。ユーザーやシステムのアクションに基づいて、何が起こる必要があるのかを含めてください。例えば、次のように書きます：

• 名前フィールドに名前を入力してください。
• 名前に番号が含まれている場合、「文字とスペースだけの名前を入力してください」というエラーメッセージを表示する。
• 名前に特殊文字が含まれている場合は、エラーメッセージ "Please enter a name with only letters and space" を表示します。
• 名前がプレースホルダーの場合、「有効な名前を入力してください」というエラーメッセージを表示します。
• 名前が有効な場合、ユーザーに送信を許可する。

再利用できるようにする：ほとんどの機能は、過去の他の機能と重複しています。例えば、ニュースレターのサブスクリプションのためのフィールドは、新しいユーザーアカウントを作成するためのフィールドと似ているかもしれません。一貫性と効率を維持するために、できるだけ再利用しましょう。

実際、再利用可能な 製品要求文書テンプレート から、テストシナリオやテストケースを抽出しやすくなります。

プロセスを描く：複雑な機能の場合、すべてのテストケースを直線的に文書化するのは難しいと感じるかもしれません。そのような場合は、フローチャートを使ってみましょう。

ClickUp Whiteboardsを使ったフローチャートとしてのコーヒーの作り方。

/参照 https://clickup.com/features/whiteboards クリックアップホワイトボード /%href/

は、機能ワークフローを可視化するための高度にカスタマイズ可能なブランクキャンバスを提供します。一人でやることにプレッシャーを感じる必要はありません。フローチャートを作成し、すべてのステークホルダー（ビジネスアナリスト、開発者、テストマネージャなど）と共有し、開始する前に賛同を得ましょう！

コンテキスト を設定する：テストシナリオがビジネスコンテキストの概要を示す一方で、テストのセットアップの概要を明確にする必要があります。ソフトウェアのバージョン、OS/ブラウザ、ハードウェア、日付/時間フォーマット、タイムゾーンなどを含めてください。また、テスト実行中に役立ちそうな文書やリソースもリンクされていること。

4.期待される結果を明記する。

これは、what happens ifに対する答えです！では、名前フィールドがバリデートされたらどうなるのか？名前フィールドがバリデートされなかったらどうなるか？

• ユーザーがすでに購読者であった場合はどうなるでしょうか？サブスクリプションを拒否しますか、それとも再登録しますか？
• ユーザーがまだ有料でない場合、今すぐ支払うように要求すべきでしょうか？
• ユーザーが以前に購読を解除した場合はどうしますか？再登録する前に再確認すべきでしょうか？

このように、あらゆる可能性に対して予想される結果を概説しましょう。機能が複雑であればあるほど、リストは長くなります。

5.前提条件と事後条件を含める

さて、どんな機能も島ではありません。ソフトウェア開発では、すべての機能は他の何かと接続しています。つまり、テストには前提条件と後件数があります。

前提条件の例。

• 有料カスタマーである必要がある。
• 有効な名前と電子メールを提供する必要がある。
• ご利用条件に同意いただける方
• 最新バージョンのChromeを使用していること
• モバイルからのログインが必要です

後条件例

• データベースに追加する必要がある
• 確認電子メールでサブスクリプションを受け入れる必要があります。
• CRMのニュースレターリストに追加する必要がある。

もしあなたがテストのコツを掴みたいと考えているプロダクトリーダーであれば、以下を参考にしてください。

/参照 https://clickup.com/ja/blog/58799/no-code-tools-for-product-managers/ プロダクトマネージャーのためのコードなしツール /%href/

.

基本的なことは以上だ。

テストケースを書くためのベストプラクティス

率直に言おう：テストケースを書くのは芸術だ。優れたテストケースは、要件に書かれていなかったバグや不具合を発見してくれます。例えば、名前フィールドにスペースが2つあったらどうでしょう？ユーザーの姓にハイフンがあったら？

テストケースが高品質のソフトウェアを提供するためのものであることを確実にするために、以下のベストプラクティスを検討してください。

ユーザーの立場で考える

テストケースを書く前に、ユーザーの立場で考えましょう。クリティカルできめ細かくしましょう。これまで説明した例では、次のように尋ねるかもしれません：

• 名前」とはどういう意味ですか？姓？姓？それとも両方？
• これは誰の名前ですか？フィールド名のテキストには、代わりに「あなたの名前」と書くべきか？
• 読者を誘導するプレースホルダー・テキストを用意すべきか？
• ユーザーが無効な名前を入力した場合、エラーメッセージは何が間違っているのかを示すべきか？

ユーザーの立場になって考えてみましょう。様々な可能性や、エッジケースを検討しましょう。すべてのテストケースを作成することはできないかもしれませんが、それらを検討することは機能を強化するのに役立ちます。

一度に一つのことに集中する。

ユーザビリティテストケースとデータベーステストケースを兼ねた機能テストケースは書かないようにしましょう。一度に一つのことをやること。こうすることで、テスト結果が合格/不合格になったときに、何がうまくいったのか、何が間違っていたのかを正確に知ることができます。

1つのテストに多くの変数を含めると、テストが失敗したときの問題が複雑になります。

一人でやらないこと。

テストケースはソフトウェアの品質を定義する。メイカー・チェッカー・プロセスにおけるチェッカーであるにもかかわらず、2人によるレビューというもう1つのレイヤーが必要です。ですから、テストケースを書いたら、ピアレビューを受けましょう。

同僚にあなたの書いたものに目を通してもらいましょう。彼らが欠点を見つけ、批判的なフィードバックをするように促しましょう。ビジネスアナリストや開発者と協力してやることも、彼らの意図をより明確に理解するのに役立ちます。

♻️ 再利用可能なテンプレートを作成する。

テストケースを書く際のベストプラクティスの中で、最も価値があるのはテンプレートを作成することです。同じような機能をテストする場合でも、全く異なる機能をテストする場合でも、テンプレートはあなたの考えに構造を与えます。鍵コンポーネント、自動番号付けメカニズム、あるいはすべてのテスト結果を提示するフレームワークを含めます。

このテンプレートをダウンロードする

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

ClickUpのテストケーステンプレート は、反復可能なフレームワークによって効率性と可視性を劇的に改善できることを示す、シンプルでありながら強力な例です。この初心者レベルのテンプレートはカスタマイズが可能で、チームがより速く、より多くのことをやることを可能にします。さらに？このテンプレートを使って自動化の候補を特定し、QAの努力を倍増させることもできる。

🛠️ 適切なツールを使う

ソフトウェア開発チームでは、複雑な機能の包括的なテストケースを書くのは時間のかかるタスクです。文書化し、簡単にアクセスできるように整理することは言うまでもありません。

やること は、適切なツールを選ぶことです。

テストケース管理のためのツールとリソース

優れたテストケース管理は、テスト内容の作成、整理、実行、記録、監視を可能にします。テストチームが効率を落とすことなく、徹底したテストができるようになります。開発チームがバグを明確に把握できるようになります。

メリットは無限であるが、課題もまた無限である。機能ごとのテストケース数の目安は、"必要なだけ "だ。機能によっては、2つ、つまりポジティブとネガティブを1つずつでもよい。テストケースが条件付きであれば、3つでもよい。あるいは複数でもよい。

これを管理するには、堅牢なツールが必要だ。いくつかの 最高の最新QAテストツール である：

テストレール

TestRail は、テストプランを文書化し追跡するためのテスト管理プラットフォームです。トレーサビリティ、カバレッジ、テスト自動化、アナリティクスの機能が含まれている。多くのソフトウェア開発ツールとネイティブに統合され、拡張機能 API を提供しています。

BrowserStack

BrowserStackはアプリとブラウザのテストツールです。iOSやAndroidアプリ、複数のブラウザでのWebサイトのテストを提供します。ビジュアルテスト、アクセシビリティテスト、観察可能性テスト、ローコード自動化などの特定のモジュールが含まれています。

Jira

最も人気のある アジャイルプロジェクト管理 ツールとしても使える。

/としても使える。 https://clickup.com/ja/blog/16983/bug-tracking-software/ バグ追跡ソフトウェア /%href/

.Jira を使えば、ユーザーストーリーや既知のバグ、その他の問題にリンクされているテストケースを書くことができます。

しかしながら、Jira はテストケース管理のために設計されていないので、レポート作成と自動化機能はリミットかもしれません。

クリックUp ソフトウェアチームのためのClickUp は、エンジニアリング・プロセスのあらゆる側面をサポートするように設計された、オールインワンのプロジェクト管理ツールです。テストケース管理も例外ではありません。

/img/ https://clickup.com/blog/wp-content/uploads/2024/11/image-6.png ClickUp テストケース管理 /テストケース管理

ClickUpによるテストケース管理の効率化

テストケースの作成 クリックUp は、堅牢なバグと問題追跡機能により、チームのバックログ効率を管理します。ClickUp で既存のテストケースを管理したり、新しいテストケースを作成することができます。 使用方法 ソフトウェアチーム用フォーム を使うことで、リクエストやバグを取得し、チームのタスクに自動的に変換することができる。

業務の可視性：ステータスをまたいでカンバンボードとしてビューしたり、カレンダービューを使ってスケジュールを立てることができます。ClickUp作業負荷ビューでQAチームのタスクを管理し、生産性向上へ迅速に移行しましょう。使用方法 ClickUpのバグと問題追跡テンプレート を使えば、ソフトウェア開発プロジェクトにおけるテスト全般を俯瞰することができます。

プロジェクト管理の自動化：テストケース管理をシームレスに

/プロジェクト管理の自動化 https://clickup.com/ja/blog/55711/product-development-process/ 製品開発プロセス /%href/

.

ClickUp 自動化を使用して、各テストケースに適切なテスターを割り当てます。QA がステータスを変更したら、レビューのために開発者に自動的に割り当てる。

テストケース

/参照 https://clickup.com/teams/agile アジャイルチームのためのClickUp /%href/

タスクに自動的に追加される再利用可能なチェックリストを構築する。ClickUp Brainを設定し、QAチームがより迅速にレポートを作成できるようにします。

ベストプラクティスを設定済み：数十種類の設計済みテンプレートを使用して、テストプロセスを構造化できます。さまざまな テストケーステンプレート または

/または https://clickup.com/ja/blog/58545/bug-report-templates/ バグレポートのテンプレート /%href/

.

テンプレートのダウンロード

ClickUpのテスト管理テンプレート

次に、以下をお試しください。 ClickUpのテスト管理テンプレート テストシナリオ、テストケース、テスト実行を効率化するためのテンプレートです。このテンプレートを使用して、プロセスを追跡し、結果を評価し、バグや問題について開発チームと協力します。

初心者のために、このテンプレートには、プロセスを順を追って説明する包括的な「始め方」のドキュメントもあります。

テストレポートの作成方法をお探しですか？そんなあなたのためにテンプレートをご用意しました。ダウンロードして、初心者にやさしい ClickUpテストレポートテンプレート を使ってテスト結果を要約し、開発者に渡しましょう。

ClickUpであらゆるケースに対応できる優れたソフトウェアを作ろう

ソフトウェア開発において、テストはすべてが問題ないことを確認する重要な役割を果たします。 を確認する重要な役割を果たします。テストは360度のサポートを提供します。

開発チームの仕事を検証します。ビジネスチームの意図との適合性を確認する。機能、パフォーマンス、セキュリティ、プライバシーといったユーザーのニーズに忠実である。

これほど重要で包括的なプロセスを管理するには、思慮深いツール群が必要です。これこそがClickUpなのです。

アジャイル、ウォーターフォール、ハイブリッドのいずれのソフトウェア開発モデルであっても、ClickUpには機能が満載されており、独自のニーズに合わせて高度にカスタマイズできるように設計されています。

パワフルで多面的なタスク管理に加え、ClickUpにはテストスイートも含まれています、

/参照 https://clickup.com/ja/blog/144586/devops-automation/ DevOps自動化 /%href/

DevOpsの自動化、統合、そしてパンチの効いたテンプレート。ご自身の目でお確かめください。

/参照 https://clickup.com/signup ClickUpを今すぐ無料でお試しください。 /%href/

.