システム開発における「第4コーナー」テスト工程で注意すべきポイント：明日から使えるシステム開発プロジェクトの進め方 再入門（5）（3/3 ページ）

本連載では、システムを外部に発注する事業会社の側に立ってプロジェクトをコントロールし、パフォーマンスを最大化するための支援活動をしてきた筆者が、これまでの経験を基に、プロジェクト推進の勘所を解説していく。今回は、製造工程の後に控えるテスト工程で注意すべきポイントや6つの品質特性、品質分析について解説する。

[前岩浩史，ウルシステムズ]

定量指標や定性分析を用いて品質分析を実践する

　テストケースを全部消化したらテストは終わり。そう考える人は多い。実際にテスト計画書の終了条件に「全てのテストケースを消化している」「発生した不具合が修正されている」「不具合が修正できない場合は、次工程への申し送り事項として明記している」とだけ記載しているケースをよく見掛ける。

　しかし、それは誤りだ。例えば、100の機能があるシステムを考えてみよう。もし、単体テストケースが100件しかなかったらどうだろうか。1機能当たり、1件のテストはあまりにも少な過ぎる。結果が全てOKだとしても「品質」が十分とはとても言えないだろう。

　99の機能はそれぞれ不具合が5件だったが、1機能だけは20件も見つかった。こういった状況も不具合を全て修正したとしても品質に問題なしというのは難しい。「周辺の機能や同じ担当者が作成した他の機能にも不具合が潜在しているのではないか？」と考えるのが自然だ。

　全てのテストケースを消化し、不具合を修正するだけでは不十分だとお分かりいただけるだろう。本来は問題箇所がないかどうかを考えるべきなのだ。テストの状況や結果を確認しながら、問題の原因を調査し、追加テストをすることによって品質を高めていく必要がある。

　品質を高める過程で手掛かりになるのが「品質評価手法」である。ここでは、テスト密度と不具合密度を定量的に分析する評価手法と、不具合の状況を定性的に分析する評価手法を紹介する。

定量的な分析

『ソフトウェアデータ白書』

　定量的な分析では、規模に対してどれだけのテストケースを用意しているかを表す「テスト密度」と規模に対してどれだけの不具合が発生するかを表す「不具合密度」を設定し、密度の範囲内に収まっているかを確認する。密度の基準値はIPA/SECが公開する『ソフトウェアデータ白書』を利用する。

　白書では、ファンクションポイント（FP）かSLOC（Source Lines Of Code：ソース行数）を基に規模を設定している。SLOCはプログラムが完成しないと分からないし、そもそも「行数」の定義が難しいなどの難点がある。また、ファンクションポイントはチケットドリブンでの開発やスプリントごとにバックログを割り当てていく開発にはそぐわない面もある。しかし、白書には個人が一生かかってもこなせない数のプロジェクト情報が詰まっている。何とか活用できないか前向きに考えてみよう。

　投下人月からファンクションポイントを算出する方法もある。例えば、プロジェクトの開発の目標値は「15FP/人月相当」と定義してしまう。投下する人月＝コストなので大きなブレは生じない。例えば、全体工数が50人月のプロジェクトの場合、FPの範囲は詳細設計〜製造・単体テストとする。これらの工程に工数の60％を投下するとFPは450と算出できる。それを白書に当てはめれば密度を定義できる。途中の数字にこだわる必要はない。仮説に基付いても良いので、何とか密度を出すようにしよう。

　密度の基準は、使用している言語・フレームワークが類似した過去プロジェクトの実績から割り出す方法もある。言語差や利用する環境が異なる白書よりも妥当な数値を設定できる。過去プロジェクトの規模（SLOCやファンクションポイント、投下人月）とテストケース数・不具合実績数をベースにし、いったん、今回のプロジェクトの規模との比率で目標値を割り出す。その後、過去プロジェクトの稼働後品質などを加味して、目標値に補正を掛ける。ただし、そうした実績値を蓄積している会社は少ない。パートナーである開発会社に提供してもらうか、これから数値をためていくしかない。

　定量的な分析を進める上では数値に縛られ過ぎないように注意したい。目標値を1件でも超えると「再テストが必要だ！」と言いたくなるが、そこまで厳密にやる必要はない。目標値を極端に超えていないか、あるサブシステムに偏った傾向はないかといったレベルで見ればよい。目標値を定めるのは合格不合格の判定をするためではなく、極端な乖離や偏りの存在をあぶり出し、原因を考えるきっかけを作るためだと考えるべきだ。

定性的な分析

　次に定性的な分析について説明しよう。こちらは不具合の発生状況からシステムの弱い部分を洗い出していくアプローチだ。テストで発見したバグは氷山の一角であることは多い。同じ原因で似たようなバグが潜んでいる可能性は十分にある。傾向を分析することで効率的にバグを摘出できる。

　具体的には発見したバグを機能別・工程別といった観点で分類すると良い。「どの機能のどんな処理で不具合が発生しているのか」「その原因は設計ミスなのか」「プログラムのミスなのか」「あるいはレビュワーの技量があれば事前に問題を発見できたのか」など、必ず何らかの傾向が見えてくるものだ。発見した傾向に基づいて仮説を立てて適宜対策を打っていく。

　障害管理表には、それぞれの課題がどのカテゴリに当てはまるかを記入できるようにしておく。不具合を起票する時点で、どの機能のどんな処理の不具合なのか、どの工程でどんな原因で発生したのかを考えさせるようにする。

次回のテーマは「非機能」

　以上、テスト工程で注意すべきポイントを解説してきた。要約すると、早い段階から計画を立て、十分なリソースを割り当て、テスト結果を分析してシステムの品質を評価し、品質を高めることが肝要である。

　また、ユーザー受け入れテストでの確認点でも述べたが、「要求通りにシステムが作られている」上で「業務が回るか」が重要だ。そもそもの要求が間違っている場合もあるため、実際のシステムを利用し、業務が運用できるかどうかを、業務担当者自身に確認してもらう必要がある。

　本稿を一つの参考に、システム開発の「第4コーナー」を落馬せずに乗り切り、ゴールに到達していただきたい。

　次回のテーマは「非機能」である。意外と軽視されがちだが、本稼働後に大きな問題を起こす原因になり得る箇所でもある。トラブルを避けるためのノウハウを紹介する。