ラン

品質保証業務(その10:プログラム検査)

試送
「試送」とは、「合格となるかどうかを試す為に品質保証部門に送る」と言う意味である。

プログラムのコーディングが完了すると、誰でもが直ぐに実行したくなるものである。
これと同じように、設計者は検査合格となるかどうかを安易に試したくなる。
しかし、試送品質が低いと不良による検査実施不可項目数が多くなるので、
試送を繰り返すことになり、結果として工程が遅れることになる。
安易に試送をさせない為に、設計には「後工程はお客様」であることを認識させることが重要である。
つまり「品質保証部門は最初のお客様」であると言うこと。
このため、不合格が発生したときのペナルティーを決めておき、
試送後も設計部署での品質向上を続けさせる必要がある。

プログラム検査
プログラム検査とは、製品をコンピュータで実行し、
検査項目に従って製品が正しく動作することを確認することである。

【品質保証部門は現実主義に徹する】
設計の要求に妥協して納期を優先し、未完成品や代用物で検査をしてはならない。
品質保証部門は、顧客に提供するものと同じ物で、かつ同じ環境で実施するべきものである。
完成品以外の物を、「提供物と同じはず」であるとして検査してはならない。
同じであるはずの物が、往々にして同じでないことが多い。
現物、現場、実物、実機主義を貫く必要がある。

・プログラム検査中に摘出した問題点は、「問題点一覧」に記入し設計に連絡する。
「疑わしきは不合格」の考えで、少しでも疑いがある場合は全て問題点として報告する。
連絡が遅れると設計での調査が遅れ、結果的に工程遅延につながる。
また、折角不良を発見しても、設計部署が口頭で確認して不良ではないと言われて、
社外事故を発生させた事例もある。
判定に迷ったら、上長に相談し、判断してもらうこと。

・全ての検査項目の確認が完了したときにプログラム検査終了とする。
プログラムの不良のために、確認不可項目があれば、判定不可の項目数とする。

・不合格と判定した場合(ドキュメント不良や原因不明を含む)は、
検査見解、設計要求事項を記述した「検査結果の報告書」を作成し設計に差し戻す。
この時、品質向上目標値(設計での不良摘出件数)を設定し品質向上を促す。

・不合格の検査項目が無くなり、その他の検査合格基準を達成したら合格とする。

不合格内容の確認
検査作業で発生した問題は、全て問題点一覧にあげる/あがるような環境にすること。

○プログラム不良:
1件1件、何故設計で摘出できなかったかを5Why方式で追及し、抜本対策を立てさせること。
デグレードまたは重要度Aの新規不良が多い場合は、
設計技術力が低く、品質が安定しないので、上位技術者によるレビューを要求する。
新規不良が多い場合は、
製造技術力の問題が多くコーディングレベルの問題なのか否かを見極めること。
コーディングレベルの問題ではなく仕様がらみの場合は、要求仕様の段階のものか、
機能レベルの段階のものかと言った観点で根本原因を追求し対策を講ずる必要がある。
潜在不良が多い場合は、
不良を作り込んだバージョンに遡りサポート仕様の範囲を限定し必要に応じて再検証する必要がある。
更に、重要度に応じて既存製品(バージョン毎)への事故対策の発行要否を検討し、既納製品へのフィードバックを図る必要がある。

○仕様不良:
仕様改善のレビューの実施、PCLの追加等初期段階からの品質強化を図ること。
プログラム不良より重要な問題であると言うこと認識すること。

○仕様:
マニュアル記述不十分でないか検討し、マニュアルへの反映を図ること。

○ハード不良:
1件1件、設計からハード不良調査依頼表を発行させ、そのフォローを行うこと。

○原因不明:
原因が判明しない限り工完の対象としないことを事前にPRし、徹底的に究明に当たること。

○検査ミス:
ユーザミスしやすい原因を究明し、マニュアルをよくするように働きかけること。

【テスト(検査を含む)漏れ】
一言で「テスト漏れ」といっても、実際は、テストケースとして設定されるのが漏れたということ。
限界値テストなどでテストケースが漏れるだけではなく、
その機能が使われる「環境」の想定が漏れることがある。
これはテスト者のスキルもあるが、
テスト仕様としての記述が省かれていることが、「環境」の想定を困難にしている。
このようなケースでは、市場に出てからバグが見つかることになる。
一般に、設計者の立場では「機能」を明らかにするところに重点が置かれ、
熟練したテスト者は、その機能が使われる「環境」に注目する。
設計者も考えないわけではないが、どうしても一つの「環境」の中で機能を考えてしまう傾向があるため、違った環境でテストされると、途端にエラーとなってしまう。
ここに、熟練したテスト者の存在意義があるし、
設計作業を終了する前に、テスト仕様書が書かれていることの意義がある。
テスト仕様書が完成していなくても、出来るだけ早い段階で、
テスト項目を設計者に見せることで、品質を織り込むことができ、同時に、テスト内容の検証も可能となる。
名前:
コメント:

※文字化け等の原因になりますので顔文字の投稿はお控えください。

コメント利用規約に同意の上コメント投稿を行ってください。

 

最近の「品質保証活動のあり方」カテゴリーもっと見る

最近の記事
バックナンバー
人気記事