多くの人が私の職場の周りで責任転嫁をしているようで、興味深い質問が浮かび上がってきました。
既知:
要件チームは、製品の要件を作成します。開発者は、要件に従って独自の単体テストを作成します。テスト チームは、要件に従ってテスト条件、テスト デザイン、およびテスト ケースを作成します。
テスト チームのテスト ケースの X% が合格した場合にのみ、製品がリリースされます。
納品後、顧客は受け入れテストを行います --> 顧客対応チームはフィールドからバグを取得し、テスト チームにこれらの問題について知らせます。
質問：
顧客が多くの欠陥を提出することになった場合、誰が責任を負いますか? それらをカバーしていないのはテストチームですか？それとも、より良い要件を書かなかったのは要件チームですか? そして、システムをどのように改善しますか？
「テストチームのテストケースの X% が合格した場合にのみ製品がリリースされる」という文は、本当に気になります。チームは、テストの合格率だけでなく、より良いリリース基準を持つことを検討したいと思うかもしれません。たとえば、シナリオは既知であり、理解され、説明されていますか (そしてテストされていますか?) 確かにすべてのバグが修正されるわけではありませんが、延期または修正されていないバグは正しくトリアージされていますか? ストレス テストとパフォーマンスの目標を達成しましたか? 脅威をモデル化し、潜在的な脅威の緩和を説明しましたか? x の顧客 (内部/外部) にビルドをデプロイしてもらい、リリース前にフィードバックを提供してもらいました (つまり、「ドッグフード」) )? 開発者は、フィールドやテスターから出てくるバグを理解して、回帰単体テストを作成していますか? 要件チームは、シナリオが考慮されていない理由を確認するために、これらのバグが発生することを理解していますか? 仕様、開発、またはテストで説明されていない機能間の重要な統合ポイントはありますか?
チームへのいくつかの提案は、最初に発見された問題について事後分析を行い、どこで問題が発生したかを理解し、可能な限り品質を上流に押し上げるよう努めることです。要件チーム、開発者、およびテスターが、計画、開発、およびテストのサイクル全体を通じて頻繁かつ適切にコミュニケーションを取り、全員が同じページにいて、誰が何をしているかを把握していることを確認してください。実際に開発者同士で話し合ってみると、こんなにもクオリティが上がるなんて！
バグは、要件段階と開発段階の両方でシステムに侵入する可能性があります。要件チームは、要件を作成するときに、いくつかの間違いや過度に単純化した仮定を行う可能性があり、開発者は要件を誤解したり、独自の仮定を行ったりする可能性があります。
物事を改善するには、顧客は開発を進める前に要件を承認する必要があり、少なくともある程度は開発の監視に関与して、物事が正しい軌道に乗っていることを確認する必要があります。
私の頭に浮かぶ最初の質問は、「要件に対して欠陥がどのように積み重なっているか」ということです。
要件が「OK ボタンは青色であるべき」であり、欠陥が「OK ボタンは緑色」である場合、私は開発とテストを非難します。明らかに、どちらも要件を読んでいません。一方、「OK ボタンが黄色ではない」という苦情の場合は、明らかに要件の収集または変更管理プロセスに問題がありました。
この質問に対する簡単な答えはありません。システムには、プロセスに関与するすべての人に責任が分散する多数の欠陥が含まれる可能性があります。結局のところ、「欠陥」は「満たされていない顧客の期待」の別の言い方です。期待自体は必ずしも正しいとは限りません。