記事ディレクトリ
1. ユースケースレビューの目的
レビューの対象範囲と有効性を確保するために、ユースケースレビューの参照標準を提供します。
- 三者間の要件の理解に齟齬を生じないようにするため
- テスターの品質基準がプロジェクト基準と一致していることを確認する
- 実行段階におけるテスターの無駄な作業を軽減するため
- 関係者が立ち上げの必要性を理解していることを確認する
2. ユースケースレビューの役割
1. プロダクトマネージャー向け
- テスターが要件を正確に理解しているかどうかを確認し、要件の各ポイントが確実にカバーされているかどうかを確認します。
- 正常なテストケースと異常なテストケースを見直すことで、当時の要件設計時に考慮していなかった状況を振り返る自己振り返りのプロセスでもあります。
2. 開発者向け
- 自分のプログラムコードにまだ完璧とは言えない部分が多くないかを確認することは、自分のコードを自己遡及的に検査するプロセスでもあり、間接的にテストの左シフトを実現します。
- 3 者は、ユースケースでは実現できないロジックをタイムリーに伝達することで高度な合意に達しました。
3. テスター向け
- テストケースを改善するために関係者全員とコミュニケーションをとる
3. ユースケースレビュー参加者
ユースケースのレビューには、製品 (要件を策定するプロダクト マネージャー)、開発 (製品を実装するフロントエンドおよびバックエンドの開発者)、およびテスト (作成を担当するテスター) の参加が必要です。そして要件のユースケースを実行します)。
ミーティングはテスターが主導し、対応するニーズを持つテスト生が 1 人ずつ上がってテスト ケースを説明します。
- テストグループ内でのレビュー：テスト部門のメンバーの参加
- プロジェクト チーム内でのレビュー: プロジェクト マネージャー、製品スタッフ、開発者、テスターの参加
4. ユースケースのレビュー内容
1. 一般的なユースケースのレビュー内容
- ユースケース設計の構造的配置が明確かつ合理的であるかどうか、また要件を効率的にカバーするのに役立つかどうか。
- 優先順位の取り決めが合理的かどうか。
- テスト要件のすべての機能ポイントをカバーするかどうか。
- ユースケースが適切に実行可能かどうか。たとえば、ユースケースの前提条件、実行手順、入力データ、期待される結果が明確かつ正しいか、期待される結果に対する明確な検証方法があるかどうかなどです。
- 冗長なユースケースが削除されているかどうか。
- 十分な陰性テスト ケースが含まれていますか。完全に定義されており、ここで 2&8 ルールを使用すると、ポジティブなユースケースの数は 4 倍になります。結局のところ、堅牢なソフトウェアでは、コードの 80% が関数実装の 20% を「保護」することになります。
- ユーザーの利用シナリオや利用プロセスのテストケースをユーザーレベルで設計するかどうか。
- 簡潔で再利用可能かどうか。たとえば、繰り返しの多いステップやプロセスを抽出し、再利用可能な標準ステップとして定義できます。
2. テストグループの内部レビューでは、次のことに重点が置かれています。
- テストケース自体の記述は明確か、曖昧さはないか。
- テストケースの実行効率を考慮するかどうか テストケース内の各ステップは繰り返し実行されることが多いですが、検証ポイントが異なったり、テスト設計の冗長性により効率が低下したりすることがあります。
- すべてのソフトウェア要件をカバーして、要件の変更をフォローアップするかどうか。
- 例外処理や例外テストポイントを可能な限り網羅しているか。
3. テストケースレビューのチェック項目
- テストケースが会社が定義したテンプレートに従って記述されているかどうか。
- テストケース自体の記述は明確か、曖昧さはないか。
- テストケースの内容が正しく、要件の目標と一致しているかどうか。
- テストケースの期待される結果が明確かつ一意であるかどうか。
- 操作手順が説明と一致している必要があるかどうか。
- テスト ケースはすべての要件をカバーしていますか。
- テスト設計に冗長性があるかどうか。
- テスト ケースが実行可能かどうか。
- ユーザーの使用シナリオとビジネスプロセスのテストケースをユーザーレベルから設計するかどうか。
- シナリオのテスト ケースは最も複雑なビジネス プロセスをカバーしていますか。
- ユースケースの設計にポジティブなユースケースとネガティブなユースケースが含まれているかどうか。
- システムが自動生成する出力項目に生成ルールが示されているかどうか。
- テスト ケースには、中間データとバックグラウンド データのチェックを含める必要があります。
- テスト ケースには正しい名前と番号が必要です。
- テスト ケースには実行の優先順位を付ける必要があります。
- テスト ケースには、テスト環境、データ、事前テスト ケース、ユーザー認証などの関連構成情報が含まれます。
- 各テスト ケース ステップは 15 ステップ以下である必要があります。
- 自動テスト スクリプトにはコメントが必要です (コメントには、目的、入力、期待される結果などが含まれている必要があります)。
- 非機能テスト要件またはテスト不可能な要件がリストされ、ユースケースで説明されていますか
5. ユースケースレビュー方法
- オンライン会議
- オフラインミーティング
- 一般OAは関係者と連絡を取る
6. ユースケースのレビュー時間
- テストケースが完了したら
- 要件文書の提出後、開発およびテスト前
- 会議時間は1時間以内に抑えるのがベストですが、内容が多い場合は複数回レビューすることも可能です
7. ユースケースのレビュープロセス
1. 会議前の準備
- テストケースが書かれている
- 参加者に事前に通知し、検討時間を合意し、会議室を予約します
- レビューのために事前にテスト ケースを参加者に送信します。
- 会議の5分前に会議室に到着し、テストケースや要件書類などを開きます。
- ユースケースが多い場合は、事前にマークを付けて優先度の高いユースケースを優先し、フロントエンドとバックエンドのユースケースを区別するなどして検討しやすくする
- 疑問をまとめて簡単に問い合わせられるようにする
2. 会議の流れ
2.1 方法 1: テスト ケースを上から下、左から右に 1 つずつ読みます。
大まかな流れはこんな感じです。
- メリット：一つ一つ丁寧に説明してくれるので網羅的かつ丁寧
- 短所: 優先順位に関係なく時間がかかり、参加者の注意力が低下します。
2.2 方法 2: まず、機能が複雑で優先度が高く、質問が多いユースケースを検討し、次に機能が単純で優先度が低い機能ポイントを検討します。
最初に優先度の高いユースケースを説明し、次に疑問の多いユースケースを説明し、機能が単純で優先度が低い機能ポイントを説明します。
- 利点: 集中力、高効率
- 短所：説明が不十分で、見落としがある可能性がある
2.3 会議のメモ
- レビュープロセス中に、5 分以上経っても結果が判断できない場合は、それを記録し、会議後の議論やフォローアップの焦点として使用できます。
- レビュープロセス中はできるだけ明確にするよう努め、各機能のポイントを最も簡潔な言語で説明してください。
- 曖昧な問題については、製品と開発で明確に確認する必要があります。
- レビューのプロセス中、参加者は視覚と聴覚の疲労を経験する可能性があるため、講演者は重要なポイントと重要な人物に焦点を当てる必要があります。
- レビュープロセスの問題については、時間内にマークを付けてください。
- ユースケースのレビューはユースケースのみを対象としたものであり、個々の機能を対象としたものではありません。
3. 会議後のまとめ
3.1 ユースケース検討会議後は、検討上の問題点をフォローアップし、改善する必要がある。
- プロダクトマネージャーによる補足や修正が必要な点は、要件書やプロトタイプ図に記録する必要がある
- 不足しているテスト ポイントを補足し、間違ったテスト ポイントを修正し、ユースケースを管理します
3.2 必要に応じて、ユースケースレビュー文書を完成させます
3.3 個人的な会議の行動の概要
7. ユースケースレビューの終了基準
- レビュー プロセス中に、関連担当者からフィードバック情報 (つまり、問題記録のリスト) を収集し、レビューが合格するまでこれに基づいてテスト ケースを更新します。
- レビュー後、テストリーダーは関係者にテストケースレビューレポートを発行します。
- レビューの結果はプロジェクトマネージャーによって承認および確認されます
注: 企業の要件によれば、一部の企業ではユースケースレビューレポートの完成を要求していないため、自己概要レビューを実行できます。