testing - 欠陥とCR-区別する方法

Question

シナリオ：

現在、システムと統合のテストを行っています。毎日、テスターに​​よって多くの欠陥が発生します。これらの欠陥のほとんどは、私たちが与えられた要件と一致しません。多くのシナリオは開発者にとって新しいものです。私たちが持っていた要件は、ビジネスによって承認されました。

誰かが欠陥とCRを区別する方法を明確にすることができますか？

Answer 1

要件ではなかったものはすべて変更要求です。

しかし、残念ながらライブはそれほど簡単ではないので、読んでください。

欠陥とは何か、変更要求とは何かについての口論は、プロジェクトでは非常に一般的です。妥協しなければならないことが多いため、状況の管理は困難です。

私は、プロジェクトマネージャーがプログラムマネージャーによって削除されるのを見てきました。なぜなら、彼らはすべての欠陥が本当に変更要求であると主張したからです。彼らはしばしば正しかったが、それでもその行動はプログラムの全体的な進歩に役立たなかった。私はまた、元々必要とされたことはなく、努力が見積もられていたにもかかわらず、すべての欠陥を受け入れて城を建てることによって自殺したプロジェクトマネージャーを見てきました。

私は個人的に常に、欠陥を装って入ってくる、本来は必要とされていない機能を構築していることをマネージャーが知っていることを絶対に確認しています。また、これが私の視点であることをクライアント/テスターが知っていることを確認します。しかし、私はまた、欠陥が何であるかを考える際に非常に寛容です。

例：私は最近、私たちが金融支払いシステムを開発したプロジェクトに参加し、別のプログラマーが私に「彼らが望んでいるものは、これがCRであるという欠陥ではなく、とんでもないことです！」と言いました。私はそれを見て、このビジネスドメインでの私の経歴から、それは実際には非常に基本的な要件であり、このためのCRを求めることは本当に笑えると思いました。それで、大騒ぎせずに修正することにしました。

また、次の質問も検討する価値があります。

• あなたは固定価格プロジェクトに参加していますか？あなたはまだリソースを持っていて、うめき声​​なしであなたに良い評判と将来の契約を与える機能を追加することによって本当の素晴らしさを示していますか？
• CRを欠陥として受け入れると、ペナルティが科せられますか？欠陥の数が少ないことはKPI（主要業績評価指標）であり、あなたのキャリアに影響を与えていますか？
• 要件の定義は最初は不十分でしたが、それを受け入れましたか？欠陥に記載されている要件は本当に明白であり、暗示されていると見なすことができますか？たとえば、金額フィールドで数値のみを許可するように指定したことはありませんが、それでも意味があります。
• 全体像について質問せずに要件を受け入れ、部分的に責任を負っていますか？
• クライアントはあなたを引き裂き、あなたがノーと言って欠陥を拒否することができないことを悪用していますか？

プロジェクトでは、私は常にクライアントのために最善を尽くそうとしますが、過度に罰せられないようにしてください。