HOME > ソフテックだより > 第167号(2012年8月1日発行) 技術レポート「システムテスト項目のリストアップ方法」

「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより(発行日順)のページへ
ソフテックだより 技術レポート(技術分野別)のページへ
ソフテックだより 現場の声(シーン別)のページへ


ソフテックだより 第167号(2012年8月1日発行)
技術レポート

「システムテスト項目のリストアップ方法」

1. はじめに

私は、ソフテック社内でも大きな規模のシステム開発の管理をしています。
過去の開発では、不適合対応が収束せずに納期が遅れたことや、出荷後に不適合を出してしまうなど、品質面でお客様へ迷惑をかけたことがありました。

管理をする立場であるため、顧客満足はもちろんですが、開発担当者も満足できる製品を作るために、書籍を読んで知識を広げ、品質を高める方法を考え、改善に努めています。

品質を高めるためには、プログラムを作るフェーズで、品質が高いプログラミングが要求され、そのプログラムを作るためには、様々なことを考慮した設計が必要です。
つまり高い品質のソフトウェアは、上流フェーズから品質を作りこまなければなりません。

上流フェーズから品質を意識して開発し、その品質の記録を残すフェーズとしてシステムテストを実施します。
システムテストで不適合を見つけ出すようでは、上流で品質を作りこめていないため、問題があるシステムとなります。

今回の「ソフテックだより」では、出荷前に実施するシステムテストを題材にします。

2. ソフトウェア品質

私は8年前に、大規模システムの管理をする機会を頂きました。

その当時の私は、「システムテスト」とは仕様書に記載されている機能が正しく動作することを確認する作業と考えていました。
また、「不適合を見つけるためにシステムテストを実施する」と間違った考えを持っていました。
その考えで開発を進めた結果、システムテスト段階になってから品質を高める作業に時間を使い、納期や品質面で大きな失敗をしました。

実際に、自分が1人で担当していた小さなソフトでは、機能が正しく動作することを確認し、不適合が見つかっても、ちょっと修正すればそれで正しく動作して、出荷後に不適合が出ることも、ほとんどありませんでした。

しかし、大きな失敗を経験して、この考えではソフトウェア品質を高めるには不十分であると気が付きました。

例えば、「機能は正しく動作するが操作や表示の反応が遅い」問題が出ると、機能確認だけでは不十分と気づきます。
また「不適合を修正したが別なところに2次バグが発生した」という問題が出ると、テストで発見した不適合だけ修正していても「モグラ叩き」になり、品質は向上しないのだと気づきます。

ソフトウェア品質を向上させるために、設計方法、プログラミング手法、テスト方法、様々なツールについて学習する中で、ISO9126というソフトウェア品質評価に関する国際規格があることを知りました。

ISO9126では、品質モデルを構造的に定義しています。
概略は以下のとおりです。

No. 品質特性 内容
1 機能性(functionality) 正確に機能が動作することに関する内容
2 信頼性(reliability) 連続稼働や異常回復などに関する内容
3 使用性(usability) 操作や運用方法に関する内容
4 効率性(efficiency) ソフトウェアの性能に関する内容
5 保守性(maintainability) 安定動作や問題が発生した場合の解析のしやすさに関する内容
6 可搬性(portability) OSやハードウェアなどソフトウェアの開発および動作環境に関する内容

表1. ソフトウェア品質特性

ISO9126の考えは要求仕様作成フェーズ、設計フェーズ、プログラミングフェーズ、テストフェーズなど、様々なフェーズで利用できます。
このような規格に沿ってシステムテストの項目を作成し、テストを実施することで、ソフトウェア品質を記録に残すことが出来るのではないかと考えるようになりました。

私が8年前に実施していたシステムテストは、『ソフトウェア品質特性の「1.機能性」』確認だけを実施していたことになります。

3. システムテストの手法

ここで、最近の開発で導入したシステムテストの手法を紹介します。
ISO9126や様々な書籍をヒントにしているため、新しい技術ではありませんが、少しでも参考にしていただければと考えています。

3-1. テスト仕様書先行開発

ソフトウェアは要求仕様書→設計書→プログラム→テストという流れで開発します。
この場合に、テスト仕様書を作成するタイミングはプログラム作成の終盤に入ってから実施することが多いと思います。
理由は、開発を進める途中で仕様変更が入ることがあり、テスト仕様書を先行して作成すると、仕様変更部分があった場合にテスト仕様書へ反映する後戻り作業が発生するためです。

従来の進め方
図1. 従来の進め方

図1のようにテストは、テスト仕様書に記載された内容のとおりソフトウェアが動作することを確認します。
ソフトウェアもテスト仕様書も、元は外部設計書であるため、外部設計書の品質が悪ければ、どちらの品質にも影響を与えます。

そこで、外部設計書の品質を確認するために、テスト仕様書の作成を先行し、外部設計書の問題があれば、それを早い段階でフィードバックする進め方としました。

新たな進め方
図2. 新たな進め方

外部設計書からテスト仕様書を作成出来ない場合は、その部分の仕様が不明であるため、プログラムを作る時にも同じ不明点となります。
また、テスト項目を抽出する際に、ソフトウェア品質特性を意識していれば、外部設計書に記載されていない仕様を、プログラム作成前に抽出することも出来ます。

実施した結果、開発効率面では高い効果を出すことが出来ませんでした。
テスト仕様書を作成するため、早い段階で外部設計書の不明点を洗い出すことが出来ましたが、内部設計とテスト仕様書作成が並行しており、お互いに情報をフィードバック出来なかったことが原因だと考えています。
不明点を早期に洗い出せるメリットも見えているため、情報のフィードバックの仕組み作りが今後の解題となっています。

良かった点は、早い段階でテスト仕様書が出来たため、テスト内容の認識合わせをお客様と早い段階で実施出来た点です。
テスト仕様書はプログラムと違い、日本語で記述されているため、プログラム言語が分からないお客様とも、これから完成するソフトウェアの認識合わせをする成果物として有効に利用できることが分かりました。

3-2. システムテストの分類化

テスト仕様書を作成する際に思いつきでテスト項目を抽出するのは効率的ではありません。
このため、ISO9126などを参考にしてテスト目的を分類化し、その分類ごとにテスト項目を抽出しました。
分類内容は以下のとおりです。

  1. 機能テスト(ISO9126:機能性)
    仕様書に記載されている機能や、機能の組み合せに関するテスト項目を作成します。
    このテスト項目を作成した後は、仕様書に記載されている内容が全てテスト仕様書に記載されていることを確認するために、仕様書の塗りつぶし確認を実施することでテスト仕様書の信頼性を上げることが出来ます。
  2. ボリュームテスト(ISO9126:効率性)
    ログの最大件数や、ネットワーク機器の最大接続など数量の最大値に関するテスト項目を作成します。
  3. ストレステスト(ISO9126:効率性)
    イベントの同時発生など、CPUの負荷やネットワークの負荷に関するテスト項目を作成します。
    ボリュームテストとの違いは、時間の概念を含みます。
    ストレステストの場合は、単位時間あたりのイベント発生量を「負荷」として考えます。
  4. 効率テスト(ISO9126:効率性)
    通信の応答時間や、ファイルの書込み時間など、性能を測定するテスト項目を作成します。
    ここで重要なポイントは、不適合と判断する時間規定を作ることです。
    通信仕様では無応答時間を規定することは一般的ですが、ファイルの書込み時間の規定などは要求仕様で規定されることが少ないと思います。
    このような規定は顧客と相談しながら決める必要があります。
  5. 回復テスト(ISO9126:信頼性)
    異常の検出と、異常の回復に関するテスト項目を作成します。
    この項目を作成すると、要求仕様や外部設計で規定されていない異常内容が見つかる場合があります。
    早い段階で、その異常内容を発見することで、ソフトウェアへのフィードバックが可能となります。
  6. 設置テスト(ISO9126:使用性、保守性、可搬性)
    設置および運用方法を想定したテスト項目を作成します。
    例えば、通信で機器が接続されている場合は、電源投入の順番を変えて起動しても問題無いことの確認や、通信の断線など異常状態で起動した場合でも異常を検出することの確認なども行います。
    また、操作のしやすさの確認もこの項目に含まれます。

    機能は要求仕様を見れば分かりますが、お客様がどのように利用するのか意外と分からない場合があります。
    ここでテスト項目を抽出する際に、お客様から利用方法を具体的に聞き出すことで、設計不足など見つかる場合もあります。

  7. 信頼性テスト(ISO9126:信頼性)
    連続稼働を想定したテスト項目を作成します。
    例えば、信号のONとOFFを1週間繰り返して、検出抜けが発生しないことの確認や、何も操作せずに1週間放置して、メモリリークや異常が発生していないことを確認します。

上記のようにテスト目的を分類化した成果として、外部設計書に記載されていない内容や、顧客も想定していない問題を上記のテスト項目の抽出中に発見することが出来ました。

4. まとめ

書籍などに書かれている一般な内容ですが、私が担当したシステムに導入した例を含めて紹介しました。
システムテストは、動作を確認するフェーズであり、システムテストを実施する時点のソフトウェア品質が悪ければ、良いテスト仕様書を導入しても意味がありません。
しかし、その品質を確認するシステムテストが甘ければ、市場へ不適合のあるソフトウェアを流出させることに繋がるため、良いテスト仕様書で確認することも重要なことです。

10年ほど前に、私が入社する前の1990年頃に開発されたソフトウェアを修正する機会がありました。
ソフト修正をする前に、仕様を把握する一環として当時のテスト仕様書を確認すると、通信テスト項目には「正しく通信すること・・・OK」と1文だけ記載されており驚いたことを覚えています。
このシステムで出荷後に不適合が発生した話は聞いたことがありませんでしたが、これではテストを本当に実施しているのか?と疑問が出てきます。
その一方で、私が数年前に担当したシステムではテスト項目が2万件程度あり、期間にして1ヶ月のシステムテストを実施したシステムでも、顧客から多くの不適合の指摘を受けたことがあり、品質とテストの関係については、自分にとって今でも課題です。

今回、紹介した方法が答えではなく、今後の勉強や経験で変わってくると思います。
しかし、システムテストの1つの方法として参考にしていただければと思います。

(T.O.)


関連ページへのリンク

関連するソフテックだより

ページTOPへ