Untitled

２．５　品質管理

　品質管理とは、テスト管理と障害管理と、いい替えることができる。
　一般にプログラムテストとは、プログラムに潜在的にあると思われるバグを効率的に見つけだしていく工程である。プログラムが仕様通りにできているかを証明する工程ではない。システムが仕様通りに作動するか否かは、いちばん最後のシステムテスト（検収テスト）で確認する。
　システムの品質はそのバグ発生の状況で判断される。プロジェクトの流れの中で、障害の発生状況を観察することは、品質管理の上で非常に重要である。
　また、システムが本番リリースされた後でも引き続き品質の管理、監視を行っていく必要もある。
　品質管理という作業は、基本に忠実に、やるべき事をきちんとやる事につきる。

(1)テストの管理のポイント
プログラムテストの実行の管理のポイントについて、以下の項目を挙げておく。
・事前にテスト終了条件をきめておく。
テストは終了を判定するのが難しいフェーズである。したがって、事前に終了条件を決めておく必要がある。
・効率よくテストを行う。
様々な要素の組み合わせで、無数のテストケースが存在する。これらをすべてテストするのは、時間的にも不可能である。ならば、いかに効率よく、必要なテストケースを選び出すかが重要であろう。具体的には、現実に起こり得る確率と、障害が発生した時の損害の大きさの２点から判断し、リスクのより大きいものから行っていくのが適当である。
・テストの再現を可能としておく。
障害が発生しその調査をする場合、その障害が発生した原因をあらゆる観点から見る必要が出てくる。このとき、全く同じ環境で障害を再現することができれば、調査はかなり行いやすくなる。このような環境設定を可能にしておけば、効率的なテストが実現する。
また、システムテストの実行の管理ポイントは以下の通り。
・システムユーザの立場でのテストをおこなう。
特に、システムテストは必ず事前にユーザにテスト計画を承認してもらうか、あるいはユーザ自身にテストに参画してもらう。ユーザが納得しない限りテストを終了としてはならない。
・システムテストでは、状況を見た細やかな配慮や柔軟な対応が必要。
障害が発生した場合、あるいは障害のリカバリに長い時間を要してしまう場合、どのような対応をとっていくか、臨機応変に対応し、納期に間に合わせる努力をしたい。
いずれにしても、いきあたりばったりのテストではきちんとした品質管理はできない。

(2)障害管理
障害管理していく上で注意するポイントを挙げておく。
ａ．障害がほとんど発生していないのに、試験項目の消化が進んでいない。
原因としては、以下のものが挙げられる。
・試験以前のステップの作業遅れ
・試験計画及び準備の不備
・試験の最初の段階での大きな障害発生
ｂ．障害発生が予想を大幅に上回る。
この場合は、品質管理に大きな問題があると認識できる。それ以前の工程における品質管理がずさんであったため、後処理にしわ寄せとして起こるのが、　このパターン。
なお、事前に障害件数または発生率を予想しておくのが前提条件。
ｃ．未確認項目の件数が増加傾向にある。
原因としては、以下のものが挙げられる。
・障害発生件数が多すぎて、追求や対処が追いつかない
・設計がまずく、対処がしにくい
・障害管理ができていない
ｄ．テスト対応要員数の割りに処置件数が少ない。
対応要員の能力に問題があると思われる。
ｅ．障害原因に仕様に関するものが多い。
仕様の不理解や仕様変更の周知漏れが主な原因である。また、インターフェースミスやオペレーションミスの場合もある。これらのかげには、わかりにくい仕様とか運用しにくいシステムとかの問題が潜んでいる場合もあるので、軽視はできない。
ｆ．障害記録がずさん。
障害記録をきちんと行うということは、プロジェクトを通して、整理して監視することである。

いずれにしても、我々が主体的に障害管理を行うべきである。手法をしらないとか人手が足らないとかで、逃げてばかりいたら、いつまでたってもきちんとした障害管理はできない。少しは努力し、進歩したいものだ。
さらにいえば、バグのでないような環境や、種々の規約の整備を行うことが品質管理にとどめをさす。

(3)キャパシティプランニング
できうるなら、キャパシティプランニングを実行したい。性能測定に基づいたシステムチューニングを行い、本番環境での動作に支障がないかの検証を行った方がよい。本番リリースした後で、システムのパフォーマンスが極めて悪いため、前のシステムに戻すと、いうことは、多方面に大きな影響を与えてしまうものである。
また、どのフェーズのテストでもいえることだが、できる限り本番環境に近い環境で行いたい。

情報技術スキルアップの種のページへ

GLORY's OFFICEへ