ビジネス アプリをテストしていますが、私の上司は、私のテスト ケースが詳細すぎて、会社に価値をもたらさないと主張しています。UI と機能のテストでは、すべてのテキスト ボックス、メニューなどをテストし、MTM で適切なテスト ケースを作成しました。
テスト ケースにはどの程度の詳細を含める必要がありますか? それらはどの程度詳細にする必要がありますか?
ビジネス アプリをテストしていますが、私の上司は、私のテスト ケースが詳細すぎて、会社に価値をもたらさないと主張しています。UI と機能のテストでは、すべてのテキスト ボックス、メニューなどをテストし、MTM で適切なテスト ケースを作成しました。
テスト ケースにはどの程度の詳細を含める必要がありますか? それらはどの程度詳細にする必要がありますか?
自分が持っているものや批判されているものを見ずに何かを提案するのは難しい.
テストケースをより一般的なものにする方法についてのちょっとしたアイデア:ある種のリポジトリを利用してみてください。
これらは UserRepository (GoodUser、BadUser、GoodUser.Admin、GoodUser.Customer など) にすることができます。
このような戦略は、自動化テストに適用されます。
このように、
1. Enter "Login1" into 'login field';
2. Enter "Password1" into 'password field';
3. Press 'Sign in' button...
あなたは単に持っているでしょう
1. Sign in as GoodUser.Customer;
また、後でログイン プロセスに他のフィールドを追加する場合、何十ものテスト ケースを編集する必要はありません。
幸運を!
あなたが新しいテスターである場合は、まずアプリケーションを理解しようとし、次に要件を尋ねてください。要件に従って、テスト ケースを作成できます。アプリケーションの 100% テストは不可能です。すべての機能を完成させ、アプリケーションの UI と機能を改善するのに役立つバグ シートを作成してください。
メニュー、テキスト ボックス、ボタンなどに冗長なテスト ケースを追加しないでください。これがお役に立てば幸いです。
アプリケーションでは、アクションのテスト ケースを 1 つ作成し、結果を記録できます。
元:
ログインページでは、単一のケースを作成し、すべてのフィールドの検証を行いながらさまざまな入力を提供し、要件に基づいて結果を記録できます。