私の質問は少しばかげているように聞こえるかもしれません。
私のチームは、3 つの異なる で使用される Web アプリケーションをテストする必要がありますUser Roles。そのため、ユーザー ストーリーに基づいてテスト ケースを作成することから始めます。私の問題は、ユーザー ロールごとに 3 つの異なるテスト ケースを作成したくないということです。テストケースを書いて後でテストするとき、これには多くの時間が必要だと思います。理由は次のとおりです。
Total Test Cases Number = User Stories x Test Cases Per User Story x User Roles Number.
さらに、将来、新しいユーザー ロールが作成される場合でも、新しいテスト ケースを作成したくありません。
この状況を管理するためのより良い方法はありますか?
前もって感謝します。
ユーザー ストーリーへのユーザー アクセスを個別にコーディングしてテストします。ただし、ロールに基づいて完全に異なるストーリーを取得する場合を除きます。その場合、それは別個の仕様であり、独自のテストを保証します。
コーディングの面ではわかりませんが (状況とコードの実装方法によって異なります)、テストの観点から答えることができます (これまでの 2 年間、半分以上が従来のウォーターフォール システムでアジャイルに移行しています)。
私がテストした Web アプリケーションは、3 つのユーザー タイプ (グローバル) と 3 つのユーザー ロール (サイトのバケットである「プロジェクト」、画像のバケットとしてのサイト、興味があれば EyeQ を検索する) に関連付けられているという点で似ています。したがって、9 つの可能な組み合わせのうち、8 つがサイトを作成できます。現在の回帰手順ドキュメントには 100 を超えるテスト ケースがあり、20 ほどのサイトが編集/作成/削除されています。全体の合計: 500 以上のテスト ケースの大部分は手動で実行されます (自動化の取り組みは継続中ですが、UI の再起動に時間がかかるため)。
とにかく、大幅なUIの変更の結果として、手動手順の一部を書き直す必要があり、あなたが説明したような間違いを回避しようとしています（過度の繰り返し、つまり同じテストをわずかに変更して3回再利用する） ）。
ケースを作成する戦略に固執するのではなく、ループ (コーディングでも同じ用語が適用されます) を使用します。つまり、パスごとに 1 つのロール タイプの組み合わせを使用するテスト ケースです。同じテスト ケースを 3 回以上作成し、ロール/タイプごとに個別に実行する代わりに、手順を 1 回使用して最後にいくつかの手順を追加します。
テスト ケースの例: ユーザーがサイトを作成できる (私のアプリでは、タイプとロールの組み合わせの 8/9 がこれを実行できます)
私が来る前に彼らがしたこと: テスト ケース 1 - プロジェクトに結び付けられていないシステム管理者がサイトを作成できる (10 ステップ)。テスト ケース 2 - プロジェクト ロールを持つシステム管理者はサイトを作成できます (同じ 10 ステップ)。テスト ケース 3 - プロジェクトに関連付けられていないアカウント管理者がサイトを作成できる (最初のケースと同じ 10 ステップ); テスト ケース 4 - proj ロールを持つアカウント管理者はサイトを作成できます (同上)。テスト ケース 5... など
私がすること: テストケース 1: コンボ 1 でユーザーとして 10 ステップを行い、ステップ 11 - そのコンボとしてログアウトし、コンボ 2 でユーザーとしてログインし、1-10 を繰り返し、ステップ 12 - ステップ 11 からユーザーとしてログアウトします。コンボ 3 を使用してユーザーとして入力し、1 ～ 10 を繰り返します。
違い: 3 つ以上のテスト ケースまたは 30 以上のステップが実行された (この場合は約 100) 対 1 つのテスト ケース: 20 ステップ未満
ただし、問題の種類によって異なります。(例のように) 本当に反復的な場合は、可能な限りループするようにしてください。
利点は、自動テスト フレームワークを起動するときに、入力用の配列オブジェクトまたは構造体を使用したテスト ケース内の単純な for ループです。欠点は、モジュール化されていないことです (何かが壊れた場合、問題の原因を見つけるのにさらに 30 秒かかりますが、それは私の意見です)。