難しい問題だと思います。
テスト部隊を導入したり、テストをアウトソースしても、品質があがらない。
理由はこんなところにあるかもしれません。
例えばこんなレポートがあがってきます。
＜テスト実施結果＞
・指摘項目数 256件
そのうち、
・修正対応済み 16件
・修正対応中 16件
・修正拒絶 224件
修正拒絶とは、開発側がテスト部隊の指摘に対して、あ～でもないこ～でもない理由をつけて修正に応じなかったものです。
拒絶理由を集めている組織であっても、中身はこんな感じかもしれません。
＜拒絶理由＞
・指摘誤り 64件
・再現せず 64件
・修正工数過大 96件
指摘誤りのうち、何割かは開発側が仕様を曲解して言いくるめたものであったりします。これはあとでユーザからの指摘となって帰ってきます。取れるチャンスのあった不具合をわざわざ取らずにリリースしているということです。
厳しい品質基準を持つ組織では、再現せずの場合、テスト部隊は本気で再現させて、再度レポートを提出します。いつまでもレポートが往復し、時間が浪費されます。再現性の低い問題の場合、開発側は再現にかかる工数を盾にして、問題の切り分けを要求します。もっとも実装に詳しいはずの開発者が切り分けの仕方をしらないというなさけない現実の裏返しと考えられるでしょう。
修正工数過大については、利用している外部ライブラリの修正が必要とか、流用元の「アンタッチャブル」な実装の修正が困難であるとか、あまりにも重要なコンポーネントの不具合が疑われるために修正による影響（まぁエンバグですな）の大きさに恐れおののいて、言い訳を並べているに過ぎません。
試験やテストの目的は不具合を見つけることです。見つけた不具合を直さないなら、
そんな試験はやめてしまえ
ということになります。
もともとテストをしていなかった組織がテストを導入しようとするとき、テスト担当に任命されたあなたは、その壁の高さに驚くことでしょう。
しかし振り返ってみてください。自分が開発担当だったときに、ユーザやテスト部隊のレポートを、めんどくさいからといって、ろくに再現テストもおこなわずに、拒絶したことはありませんか。
それが品質を低下させる本質なのです。
隕石が落ちてきて頭に当たるかのような不具合はごくごくまれです。
ほとんどの不具合は、床に落ちている紙くずのようなものです。手でひとつずつ拾っていれば、そのうち片付きます。
シュレッダーごみは細かくて拾いにくいとか、それは俺が捨てたごみじゃないから、などと放置しているとどんどんごみは増えて行き、どうしようもなくなります。
どうしようもなくなっても、ひとつずつ拾うしか方法はありません。作り直しとか場当たりなリファクタリングというのは、ごみの上にじゅうたんやマットをかぶせてごみを隠しているだけのことかもしれません。
ごみが増えてくると、高価なテストツール（掃除機）を買おうという甘い誘惑も沸いてきます。でこぼこの床では掃除機が使える場所は限られています。
コメント