ソフトウェアテストにおけるテストシナリオとは（例）

テストシナリオとは何ですか?

A テストシナリオ テスト対象となる機能の高レベルな記述です。これは、ユーザーインタラクションやシステムの動作の可能性を表し、テスト条件と呼ばれることもあります。テスターは、エンドユーザーの立場に立って、テスト対象アプリケーション（AUT）の実際のシナリオとユースケースを理解する必要があります。

テストシナリオは、次の基準に基づいて分類できます。 アプリケーションのどの側面 検証を目的としています。これらのタイプを理解することで、すべての機能とユーザーインタラクションを完全にカバーできるようになります。

テストシナリオの種類

1. 機能シナリオ: これらは、特定の機能やモジュール（ログイン、サインアップ、チェックアウトなど）が要件通りに動作するかどうかを検証します。「何をすべきか」という側面に重点を置いています。
2. 非機能シナリオ: これらは、システムの機能ではなく、パフォーマンス、スケーラビリティ、使いやすさ、信頼性など、システムのパフォーマンスを評価します。
3. セキュリティシナリオ: これらは、アプリケーションがユーザーデータをどの程度保護し、不正アクセスや脆弱性を防止しているかを評価します。
4. UI (ユーザーインターフェース) シナリオ: これにより、視覚的なレイアウト、ナビゲーション、インタラクティブな要素が、さまざまなデバイスや画面サイズで直感的に機能するようになります。
5. エンドツーエンドのシナリオ: これらは実際のワークフローをシミュレートし、eコマース アプリでの検索、カートへの追加、支払いの完了など、複数のモジュールがシームレスに連携することを確認します。

シナリオテストはテストシナリオと同じですか?

テストシナリオは何をテストするかを定義しますが、 シナリオのテスト 複雑な、エンドツーエンド、または 実際のユーザーストーリー テストには、個々のテストケースを網羅的に列挙するだけでなく、多くの場合、テストケース群が使用されます。その目的は、特定の現実的なワークフローにおけるシステムのパフォーマンスを評価することです。

以下のビデオを使ってこれを勉強してみましょう –

テスト シナリオを作成する理由

テストシナリオは、以下の理由で作成されます。

• テスト シナリオを作成すると、テスト中に主要なユース ケースがカバーされることが保証されます。
• テストシナリオは、ビジネスアナリスト、開発者、顧客などの関係者によるレビューと承認を受けることで、テスト対象アプリケーション（AUT）が徹底的にテストされていることを確認することができます。これにより、ソフトウェアが最も一般的なユースケースで動作することを確認できます。
• これらは、テスト作業の労力を決定し、それに応じてクライアントへの提案を作成したり、労働力を編成したりするための迅速なツールとして機能します。
• これらは、最も重要なエンドツーエンドのトランザクションやソフトウェア アプリケーションの実際の使用方法を決定するのに役立ちます。
• プログラムのエンドツーエンドの機能を調べるには、テスト シナリオが重要です。

👉 無料のライブソフトウェアテストプロジェクトに登録する

テストシナリオを作成しない方が良い場合は何ですか?

次の場合、テスト シナリオは作成できない場合があります。

• アプリケーションが複雑または不安定な場合、またはプロジェクトのタイムラインが短すぎて構造化されたドキュメントを作成できない場合は、テスト シナリオを作成しないでください。
• Scrum、Kanban などの Agile 方法論に従うプロジェクトでは、テスト シナリオを作成できない場合があります。
• 新しいバグ修正や、 回帰テスト 以前のテストサイクルで既に文書化されている場合。このような場合、テストシナリオは以前のテストサイクルで既に十分に文書化されている必要があります。これは特に保守プロジェクトに当てはまります。

テストシナリオの書き方

テスターは、次の XNUMX つの手順に従ってテスト シナリオを作成できます。

• ステップ 1テスト対象システム（SUT）のBRS、SRS、FRSなどの要件ドキュメントを読みます。また、テスト対象アプリケーションのユースケース、書籍、マニュアルなどを参照することもできます。
• ステップ 2各要件について、想定されるユーザー行動と目的を洗い出します。要件の技術的側面を特定します。システム不正使用のシナリオを洗い出し、ハッカーの視点でユーザーを評価します。
• ステップ3： 要件ドキュメントを読み、デューデリジェンス分析を行った後、ソフトウェアの各機能を検証するさまざまなテスト シナリオをリストします。
• ステップ4： 考えられるすべてのテスト シナリオをリストアップしたら、 トレーサビリティマトリクス それぞれの要件に対応するテスト シナリオがあることを検証するために作成されます。
• ステップ5： 作成されたシナリオは上司によってレビューされます。 Later、プロジェクトの他の関係者によってもレビューされます。

AI はテストシナリオの自動化にどのように役立ちますか?

AIは、テストシナリオの自動化を従来のスクリプトよりもスマートで高速、そして適応性の高いものにすることで変革しています。すべてのテストに対して手動でスクリプトを作成する代わりに、AI搭載ツールはユーザーストーリー、要件、さらには履歴データからテストシナリオを自動生成できます。機械学習を活用したプラットフォームは、過去のテスト失敗のパターンを分析して高リスク領域を予測し、テスターが本当に重要な作業に集中できるよう支援します。

AI駆動型自動化フレームワークはスクリプトを自己修復することができ、UIが変更されるとロケータを自動的に更新することで、メンテナンス時間を大幅に短縮します。また、 CI/CDパイプライン 継続的なテストとリアルタイムのフィードバックを保証します。

たとえば、AI エンジンは、e コマース サイト上の何千ものユーザー ジャーニーをシミュレートし、壊れたフローを検出し、最適化されたテスト範囲を提案することもできます。

テストシナリオ作成のヒント

• 各テスト シナリオは、プロジェクト方法論に従って、少なくとも 1 つの要件またはユーザー ストーリーに結び付けられる必要があります。
• 複数の要件を一度に検証するテスト シナリオを作成する前に、その要件を個別にチェックするテスト シナリオがあることを確認してください。
• 複数の要件にまたがる過度に複雑なテスト シナリオを作成しないでください。
• シナリオの数が多くなり、すべてを実行するにはコストがかかる場合があります。顧客の優先度に基づいて、選択したテストシナリオのみを実行します。

学生へのヒント: テスト シナリオでは何をテストするかが記述され、テスト ケースではそれをどのようにテストするかが記述されます。

例 1: e コマース アプリケーションのテスト シナリオ

e コマース アプリケーションの場合、いくつかのテスト シナリオは次のとおりです。

テストシナリオ 1: ログイン機能を確認する

テストシナリオとテストシナリオの違いを理解していただくために、 テストケース、このテスト シナリオの具体的なテスト ケースは次のようになります。

1. 有効なメール ID とパスワードが入力されたときのシステムの動作を確認します。
2. 無効なメール ID と有効なパスワードが入力された場合のシステムの動作を確認します。
3. 有効なメール ID と無効なパスワードが入力された場合のシステムの動作を確認します。
4. 無効なメール ID と無効なパスワードが入力された場合のシステムの動作を確認します。
5. 電子メール ID とパスワードが空白のままでサインインが入力された場合のシステムの動作を確認します。
6. 「パスワードを忘れた場合」が期待どおりに機能していることを確認します
7. 有効/無効な電話番号とパスワードが入力されたときのシステムの動作を確認します。
8. 「署名を残す」がチェックされている場合のシステムの動作を確認する

明らかなように、テスト ケースはより具体的です。

テストシナリオ 2: 検索機能を確認する

テストシナリオ 3: 製品を確認する Descriptイオンページ

テストシナリオ 4: 支払い機能を確認する

テストシナリオ 5: 注文履歴を確認する

これら 5 つのシナリオとは別に、他のすべてのシナリオのリストをここに示します。

• リピート顧客のホームページの動作を確認する
• カテゴリ/商品ページを確認する
• カスタマーサービス/お問い合わせページを確認する
• 毎日のセールページをチェック

例 2: 銀行サイトのテスト シナリオ

テスト シナリオ 1: ログインおよび認証機能を確認する

テスト シナリオ 2：送金可能か確認する

テスト シナリオ 3：小切手取引明細書が閲覧可能

テスト シナリオ 4：定期預金・定期預金の預け入れが可能か確認する

等々…

テストシナリオのテンプレート

テストシナリオテンプレートExcel(.xlsx)のダウンロード

テストシナリオにおける一般的な課題とミス

効果的なテストシナリオの作成は簡単そうに聞こえますが、落とし穴が潜んでいることがよくあります。テスターが直面する一般的な課題とミスをいくつかご紹介します。

• 不明瞭な要件: 要件があいまいであったり、要件が変化したりすると、シナリオが不完全になったり、関連性がなくなったりします。
• 重複するシナリオ: 冗長なシナリオは時間を浪費し、テスト実行時に混乱を生じさせます。
• エッジケースを無視する: 共通パスのみに焦点を当てると、重大な欠陥を見逃してしまいます。
• 優先順位付けが不十分: すべてのシナリオを平等に扱うと、影響の大きい機能のテストが遅れます。
• 過剰なディテール: シナリオが複雑すぎると、メンテナンスが困難になり、俊敏性が低下します。
• トレーサビリティの欠如: 要件とシナリオ間のリンクが欠落していると、カバレッジのギャップが発生します。
• 自動化の準備を無視する: 自動化に適さないシナリオを記述すると、スケーラビリティが制限されます。

よくあるご質問