システムではマスタ設定内容によって切り替わる機能が多く、その設定で業務の流れも変わります。したがって、結合テストにおいては、シナリオ内のテストケース洗い出す際、顧客がどのようなマスタ設定をするかを事前に知っておくべきでしょう。事前に知っておくことで、精度の高いテストケースを作成することができます。

　その結果として、結合テストでは通ったが、顧客環境では動かないといったトラブルを回避することができるのです。また、実運用に関係ない余計なテストケースを作成することもなくなるため、テスト工数を削減することが可能です。

　例えば、ERPパッケージをカスタマイズする場合、パッケージ上は支払方法に振込、手形、引落、相殺が選択できたとしても、将来的にも相殺を使用する予定はないのであれば、顧客同意の上、相殺のテストを仕様書から除いたほうがよいでしょう。また、ある支社では手形は使用しないのであれば、部門ごとのテストからこれを外すのも同様です。

　さて、では本番環境に近い状態で結合テストをするにはどうしたらよいでしょうか？通常、システムを稼働させるには、開発作業に加えてデータ移行やマスタ設定といった導入作業がありますが、開発のボリュームが大きいと後手に回りがちです。

　しかし、上記のような理由から、結合テスト仕様書作成時までには、データ移行やマスタ設定の工程を大まかには終了するようスケジュールを組み、実施しましょう。これがプロジェクトを成功させる上での大きなポイントとなります。

　ただし、顧客が設定したデータを社内テストデータとして使用する際は、当然ですが所定の手続きを踏むこと、個人情報はマスキングすることを徹底しましょう。

　再度「結合テスト計画書兼実施状況報告書」を見てみましょう。前ページでは計画段階での使用法を説明しましたが、ここでは結果報告としての使い方を紹介します。

　結合テストは開発規模によって数ヶ月におよぶ場合があります。その際、最後になって「こんな結果でした」と顧客に報告しても、その間心配でしょうし、ましてや状況が悪かった場合、対処ができません。したがって定例報告日を決めて状況を報告することになります。その報告時に「実施状況」シートを使用してください。

　「実施状況」シートではシナリオごとのバグ発生率を把握するようになっており、どの業務に問題が集中しているかを分析します。また、テスト実施回数ごとのバグ発生率も記載しているため、例えば2回の実施で結合テストを終了してよいかの判断基準となります。

　報告の際、図3のようなグラフを用いるとさらによいでしょう。このグラフはバグ発生数およびバグ改修数が日々の進ちょくとして表されるため、品質の定量的判断にはよく用いられるものです。「DUNGEON」では「障害管理一覧」のテンプレートで作成可能で、次回詳しく紹介することとします。

　今回は結合テストフェーズについて説明しましたが、要点としては、運用ルールを決めること、概要を作成しわかりやすく記載すること、定量的に分析することなど、これまで話してきたことと内容が重複しています。

　つまり上記のような観点を抑えておけば、システム開発の各工程において応用可能であることを覚えておきましょう。次回はテストフェーズのまとめとして、定量的に分析するためのフォーマット「障害処理票」と「障害管理一覧」について解説します。 タイトルへ戻る