BA が要件を書きます。 QA は要件を検証します。この 2 つの役割が密接に連携していないと、「職業が間違っている」というバグが大量に発生します。
通常、ビジネス エラーは、開発力の低下や QA テストの欠如が原因ではありません。通常、ルートは次のとおりです。
- 受け入れ基準が十分に明確ではありません。
- ビジネスルールは利害関係者の頭の中にあります。
- エッジケースは記載されていません。
- QA はリファインメントに参加できません。
- 欠陥トリアージは技術のみを考慮し、ビジネスへの影響は考慮しません。
1. BA と QA はいつ調整する必要がありますか?
スプリントの終わりではなく、洗練から。
次の場合に QA を招待する必要があります。
- ストーリーには複雑なビジネス ルールがあります。
- 多くの役割/権限があります。
- 統合/API があります。
- データ移行あり。
- UAT またはコンプライアンスを備えている。
- 重大な NFR があります。
QA がビルドの完了時にのみ要件を確認する場合、エラーは遅れてしか検出できません。
2. AC からテストシナリオまで
適切な合格基準は、テスト シナリオの入力となります。
ストーリー:
顧客として、出席できないときに枠を空けるために、予約をキャンセルしたいと考えています。
AC:
Given khách có lịch hẹn Confirmed
When khách hủy trước giờ hẹn ít nhất 4 tiếng
Then hệ thống cập nhật trạng thái thành Cancelled
And slot được mở lại cho khách khác đặt
And khách nhận email xác nhận hủy
テストシナリオ:
| ID | シナリオ | 予想される |
|---|---|---|
| TC-001 | 4 時間前までにキャンセル | キャンセルされ、スロットが再開され、メールが送信されました |
| TC-002 | 4 時間以内にキャンセル | キャンセルを許可しない、ポリシーを表示 |
| TC-003 | 予定をキャンセル キャンセル済み | キャンセル不可 |
| TC-004 | 電子メール サービス エラー | 予約はまだキャンセルされています。電子メールの再試行/ログ |
| TC-005 | 別のユーザーが予定をキャンセルしました | 403 または権限なし |
QA は、BA が見落としがちなケースを BA が確認するのに役立ちます。
3. 重大度と優先度
これら 2 つの概念はよく混同されます。
- 重大度: システム/機能エラーの重大度。
- 優先度: ビジネス/リリースのコンテキストに基づいて、緊急に修正する必要があるレベル。
たとえば:
| バグ | 重大度 | 優先事項 | なぜ |
|---|---|---|---|
| 支払いが 2 回請求される | クリティカル | P0 | お金と信頼への影響 |
| 内部管理でのロゴのオフセット 2px | 低い | P3 | 低衝撃 |
| 請求書の日付形式が間違っています | 中 | P1 | 法的/会計上の影響の可能性 |
| CSV のエクスポートにオプションの | がありません。コラム 中 | P2 | 回避策はあります |
BA はビジネスへの影響を理解しているため、優先的に参加する必要があります。
4. 欠陥トリアージ会議
議題 30 分:
1. Review bug mới theo severity
2. Xác định business impact
3. Xác định workaround
4. Quyết định fix now / fix later / won't fix
5. Update release risk
6. Assign owner và deadline
各欠陥には次のものが必要です。
- 再現手順。
- 実際の結果。
- 期待される結果。
- 環境。
- 証拠のスクリーンショット/ログ。
- 関連要件/AC。
- インパクト。
- 重大度。
- 優先順位。
- 所有者。
5. 欠陥トリアージマトリックス
| 影響 | 回避策 | 決定 |
|---|---|---|
| 高 | 回避策なし | リリース前に修正 |
| 高 | 回避策あり | 製品/BA がリスクを決定 |
| 中 | 回避策なし | 容量を修正 |
| 中 | 回避策あり | 延期できる |
| 低い | 回避策あり | バックログ |
感情に基づいて決定を下すべきではありません。理由を明確に述べなければなりません。
6. 回帰スコープ
要件が変更された場合、QA は何を再テストするかを知る必要があります。
BA は次のように書く必要があります。
- 要件の変更。
- どのようなビジネスルールが変わりましたか?
- どの API/データが影響を受けますか?
- どの役割が影響を受けますか?
- どのレポート/ダッシュボードが影響を受けますか?
- どの UAT シナリオを更新する必要がありますか?
例えば：
Change: Cho phép hủy lịch trước 2 tiếng thay vì 4 tiếng.
Regression scope:
- Cancel appointment flow
- Slot availability recalculation
- Email template
- Admin booking history
- UAT scenario UAT-03
7. BA はバグをどのように読み取るべきですか?
QA がバグを記録するとき、BA は単に「仕様は正しいか?」と尋ねるのではありません。尋ねてください:
- 仕様があいまいですか?
- AC はこのケースをカバーしますか?
- ビジネス ルールにはソースがありますか?
- これはバグですか、それとも変更リクエストですか?
- 修正されない場合、ビジネスにどのような影響がありますか?
- 回避策はありますか?
- SRS/RTM/テスト ケースを更新する必要がありますか?
要件の欠落が原因でバグが発生した場合、BA は要件を開発者に押し付けるだけでなく、責任を持って要件を改善する必要があります。
8. UAT の欠陥
UAT の欠陥は通常、次の 3 つのカテゴリに分類されます。
| タイプ | 取り扱い方法 |
|---|---|
| 本当のバグ | 重大度/優先度ごとに修正 |
| 要件のギャップ | 変更リクエストまたはスコープの更新 |
| トレーニング/プロセスの問題 | アップデートガイド、トレーニング、コミュニケーション |
BAは明確に区別する必要があります。すべての UAT 応答がバグであるわけではありません。
9. 完全な欠陥トリアージの例
機能: オンライン相談のスケジュールを変更します。
| バグ | 説明 | 重大度 | 優先事項 | BA分析 | 決定 |
|---|---|---|---|---|---|
| BUG-101 | 4 時間未満でスケジュールを変更した顧客は引き続き成功します。 | 高 | P0 | BR-003 に違反し、コンサルタントの業務に直接影響します。 | リリース前に修正し、回帰テストのカットオフを追加しました。 |
| BUG-102 | ダブルクリックすると確認メールが2回送信されます。 | 中 | P1 | 冪等性が欠如しているか、UI がボタンを無効にしていないことが原因である可能性があります。 | スプリントで修正し、テストの重複送信を追加します。 |
| BUG-103 | エラー メッセージには、「4 時間」ではなく「2 時間」と表示されます。 | 低い | P0 | 重大度は低いですが、顧客にとって間違ったポリシーを引き起こすため、優先度は高くなります。 | UAT サインオフ前のコピーを修正しました。 |
| BUG-104 | コンサルタント ダッシュボードの読み込みには 5 秒かかります。 | 中 | P2 | NFR しきい値を下回っている場合、リリースをブロックしませんか? NFR-PERFと比較する必要があります。 | エンジニアは p95 を測定し、NFR を超える場合は修正します。 |
| BUG-105 | カスタマーサービスは顧客のスケジュールを変更する方法を知りません。 | バグではありません | P2 | これはトレーニング/SOP の問題であり、ソフトウェアの欠陥ではありません。 | SOP とトレーニングノートを更新します。 |
BA はトリアージ中に次のことを尋ねる必要があります。
- このバグはどの要件/ルールに違反しますか?
- 回避策はありますか?
- 法的/コンプライアンス/顧客の信頼に影響しますか?
- AC/テストケースを更新する必要がありますか?
- これはバグ、要件のギャップ、または変更リクエストですか?
良好なトリアージの結果には、今すぐ修正する、後で修正する、拒否する、変更リクエストに変換する、トレーニングの問題など、明確な決定が残されている必要があります。
10. よくあるエラー
エラー 1: QA は改良に参加できません
QA の到着が遅れると、エッジケースの発見も遅くなります。
エラー 2: BA はバグの後、要件を更新しませんでした
バグによって新しいルールが指定されている場合は、SRS/AC/テスト ケースを更新する必要があります。そうしないと、同じバグが再発します。
エラー 3: 誰が最も大声で叫ぶかに従ってバグに優先順位を付ける
優先順位は、影響、緊急性、回避策、リリースのリスクに基づいて決定する必要があります。
練習問題を練習する
あなたがかつて書いた物語を選択してください。テーブルを作成します。
- 交流
- テストシナリオ
- 期待される結果
- 必要なデータ
- 必要な役割
- エッジケース
次に、もう一度質問せずに QA テストを実行できるかどうかを自問してください。
参照元
- スクラムガイド 2020: https://scrumguides.org/scrum-guide.html
- IIBA BABOK ガイド: https://www.iiba.org/standards-and-resources/babok/
結論
BA と QA は 2 つの観点から品質を保護します。BA はビジネス上の重要性を保護し、QA は検証可能性を保護します。 2 つの役割が早期に機能し、構造化されていれば、チームはバグを減らし、手戻りを減らし、UAT を大幅に軽量化します。