総合テスト

システムベンダー側のSEがユーザに納品する前に行なう3段階の試験の最後が総合テストで、システムテストと呼ばれることもあります。
システム開発V字モデルでは、総合テストは基本設計に対応する工程であり、基本設計工程で定義されたシステム要件が実現できているかを確認する作業となります。

結合テストまでで、システムに要求された機能要件は、プログラムを結合した状態で実現できていることが検証済です。
総合テストでは、非機能要件も含めてシステム(プログラムがすべて結合された状態のもの)が実業務で問題なく運用可能であることを検証します。

非機能要件テスト

IPA(情報処理推進機構)から「非機能要求グレード」が提供されており、大項目として6項目が挙げられています。

可能性 情報システムを継続的に利用可能とするための要求
性能・拡張性 システムの性能、および将来のシステム拡張に対する要求
運用・保守性 システムの運用と保守のサービスに関する要求
移行性 現行システム資産の移行に関する要求
セキュリティ 情報システムの安全性の確保に関する要求
システム環境・エコロジー システム設置環境やエコロジーに関する要求

プロジェクトの特性により、各非機能要件に対する重要度や必要性は変動することになりますが、試験項目としては「実業務で問題なく運用可能か」に着目して選出します。

例えば、開発環境とシステム設置環境ではマシンスペックも接続状況も異なることから、開発環境で計測した性能値がシステム設置環境では実現できない可能性があります。
セキュリティ認証機器を実際のインフラ設備に設置した場合に反応速度の遅延が発生してしまい、タイムオーバーによる認証不可となることも考えられます。

総合テストでのチェックポイント

総合テストの試験項目は、基本設計時に作成した業務フローを基に、実際の運用をシミュレートするようなテストケースを過不足なく抽出してください。
ただし、テストの対象としてはコンピュータ化した部分に限定します。

業務フローからシステム処理フローを作成しているのであれば、システム処理フローの範囲内がテスト対象となります。
具体的には、納品するプログラムの動作結果がテストの対象ということであり、動作結果が基本設計として合意した範囲内であれば問題なしと判断します。

業務面での課題発見と対応

例えば、人間系の業務である「印字出力された伝票に検印する」といったテストも、実業務での利便性からは必要な視点といえます。
テストの結果、検印欄がギリギリの設計であったため、印影が他の印字部分と重なり読み取りにくい、といった不便さに気付くかもしれません。しかし、伝票のレイアウトは要件定義から基本設計に至る過程で検討し、最終的に基本設計内容の合意という承認行為が行なわれているものです。

システム開発者が総合テストで検証するのは、基本設計として承認された仕様が実現されていることです。確かに実際の運用では不便な点があるかもしれませんが、不便かどうかといった評価はシステム開発者が行なうものではありません。
システム発注側であるユーザが改善すべきものと認めた場合に、それを新たな要求事項と位置付け、あらためてシステム開発(改修)案件として対応すべきものとなります。

総合テストにおける試験結果分析

結合テストまでの工程で、機能面の誤りは全て取り除かれている、という前提で総合テストは実施されるため、検出される誤りは非機能要件が主なものと考えられます。
それでも「人間はミスをする」ものですから、機能面の誤りも多少残存している可能性があります。誤りが検出された場合は、誤りの有無を問題視するのではなく、誤りの発生原因を分析し適切な対策を講じる、ということが必要です。
また、誤りが作り込まれた工程を見極めることも大切なことです。

誤りの作り込みの検出と対策

「どの作業工程」で「どんな理由」で誤りを作り込んだのかがわかれば、実行すべき対策が明確になり、効果的で効率的な対応をとることができます。

一例ですが、「マスタ設定とデータ入力の組合せで、あるパターンの時、単価の端数処理の計算ミスが検出され、入力プログラムの実装ミスがわかった」とします。
同じような計算ミスが存在しないか確認するため、他のデータ入力プログラム15本をチェックしたところ、4本に同様のロジックミスが見つかり修正をしました。

1つの実装ミスから水平展開をし、結果として潜在不具合化する可能性のある4本のプログラムのロジックミスが検出できてよかった、として作業を終わらせていないでしょうか。
データ入力プログラムが全16本あるうち、なぜ4本だけロジックミスが発生したのか、なぜ12本にはロジックミスが無かったのか、という疑問を感じませんか。

ロジックミスが4本だけ発生した原因を追求することで、本質的な誤り発生要因が浮かび上がり、16本のデータ入力プログラム以外のプログラムにもロジックミスが見つかる可能性があります。例えば、ロジックミスの発生要因が、プログラム設計における共通仕様作成時の思い違いということであれば、他の共通仕様でも同様な問題が存在しているかもしれません。

誤りは存在しないのであれば、それに越したことはありませんが、誤りが検出されることによって、システムの弱点が明確となり、対策を講じることで品質強化に結びつけることができます。
「人間はミスをする」という考えを前提にすると、誤りが検出されないという場合、試験品質に問題が無いか、という心配が湧き上がります。その心配を解消するためには、試験品質をどのように保証するか、というなかなか難しい課題にぶつかります。
むしろ誤りが検出されることで品質向上の機会が与えられたとポジティブにとらえ、そのためにも誤りが検出できるような品質が高い試験設計をすべきと考えます。

 ブログランキング・にほんブログ村へ

シェアする

  • このエントリーをはてなブックマークに追加

フォローする