テストにおいて摘出された欠陥を記録・管理するうえで、いつも考え込んでしまうのが、「重要度」という項目です。「A」「B」「C」、「高」「中」「低」、「Critical」「Major」「Minor」「Cosmetic」など、その区分にもいくつかありますが、そもそも重要度って何なのでしょう。ちゃんと定義しておかないと、担当者ごとに適当に判断されるため、分析の項目としては何の役にも立ちません。
重要度の定義は、コストの大きさで考えるとわかりやすいのですが、そのコストには、大きく2つの考え方があると思います。
|
JSTQBのお勉強でコストの分類に触れていますが、(1)は内部コスト、(2)は外部コストと言えるでしょう。
(1)と(2)は比例するわけではない（コード1行の欠陥が、カオスな故障に結びつくかも知れない）ので、どちらかを選ぶ必要があります。
では、(1)と(2)のどちらを選ぶべきでしょうか。
決め手としては、「その欠陥を記録するための手間、どちらが少ないか」という観点があります。どれだけ素晴らしい定義をしても、それが記録されないのであれば無意味ですからね。
では、(1)と(2)のどちらを選ぶべきでしょうか。
決め手としては、「その欠陥を記録するための手間、どちらが少ないか」という観点があります。どれだけ素晴らしい定義をしても、それが記録されないのであれば無意味ですからね。
では(1)と(2)、どちらのコストが見積やすいか。
それは(1)だと思います。
(2)でかかるコストは、単に修正に要するものだけでなく、お客様への状況説明のための資料作成や打ち合わせに始まり、信用の失墜やら違約金の支払いやら、エンジニアリングとはあまり関係のないものまで含まれてしまいます。それはお客様の性格やタイミング、運などにも左右されるでしょう。
一方(1)であれば、対応するドキュメントの修正、当該コードおよび類似コードの修正、当該およびその周辺のテストケースのリトライという、純粋に「ソフトウェア開発」の範疇で見積もることができます。
それは(1)だと思います。
(2)でかかるコストは、単に修正に要するものだけでなく、お客様への状況説明のための資料作成や打ち合わせに始まり、信用の失墜やら違約金の支払いやら、エンジニアリングとはあまり関係のないものまで含まれてしまいます。それはお客様の性格やタイミング、運などにも左右されるでしょう。
一方(1)であれば、対応するドキュメントの修正、当該コードおよび類似コードの修正、当該およびその周辺のテストケースのリトライという、純粋に「ソフトウェア開発」の範疇で見積もることができます。
「欠陥の記録はしっかりと、しかし極力少ない手間で」と考えるとこんな結論になりますが、みなさんはどのような定義をしていますか？
