単体テストの観点


テストの重要性

単体テスト工程の良し悪しは後続の結合テスト、総合テストで大きな影響がでてきます。

開発担当の立場を経験し、プロジェクトリーダーの立場となって、システム開発を経験するとテストについての認識を再確認させられます。

システムの開発担当者の立場では、「不完全な仕様」を「短い開発期間」という制限の中、実際に開発に携わらなければならない場面が少なくありません。
その環境下で自分自身を守るため、プロジェクトをうまく遂行するためにも単体テストは重要な工程と考えられます。
しかし実際の開発現場で、テスト工程に十分な時間を確保しきれなくなることも実感してます。

結局、そのツケは結合、総合テストのなかでカバーすることになります。単体テストレベルのバグの発見、その修正にとられる時間は大きくなり、結合、総合テストの進捗がストップしてしまうことになってしまいます。

また、プロジェクトリーダーの立場から考えると、仕様は自分が理解しているが、開発作業をメンバーに任せる状況になります。
全てのプログラムの中身を確認するわけにもいかない中で、何をもって品質の担保がとればいいのかということに気付かされます。

テスト工程は無限に時間が用意されているわけではなく、単体、結合、総合と階層化された工程になることを考慮すると各テスト工程での観点をきちんと持つ必要がでてきます。

単体テストに観点がなぜ重要になるか

単体テストがどういうものか、どういうやり方がよいかという前に、テスト工程で起こることを考えます。

  • 結合テストの工程で目の当たりにする問題は、
  • 単体テスト担当者「そこは結合テストで確認するとおもったので、単体では確認してません」
  • 結合テスト担当者「そこは単体テストで確認しているとおもったので、結合では確認してません」
  • といったテスト担当者間での押し問答です。

これは、テスト工程をスケジュールどおりに消化する形式的な工程と考えているためだと思います。
逆に両方の工程で同じテストをしてしまう場合もあり、これは単純に２度目の作業工数が無駄になってしまいます。

後続の工程で問題が明るみにでたときに観点がなく行っていた作業はその対処が非常に難しくなります。 (そしてバグは必ず発生します。問題とするかどうかは環境やその状況に寄るとは思います)

  • 例えば、結合、総合とテストを進めていくと単体テストで確認できるような単純なバグが膨大に発生し、このままテストを進めるよりも単体テストをやり直した方がよい状況になったとします。しかしその作業のやり直しに誰も別途お金を用意してくれません。基本的に作業のやり直しはできません。
    そこでシステム会社が赤を被りやり直し作業の費用(人員、スケジュール)を調整します。
    しかし、今度は、上長がやり直し作業を行うことに許可をだしません。許可を出せないのは、同じ作業をしても結果は変わらないからです。結果が変わらないのであればやるだけ無駄な作業ということになります。
    この場合、どうすればやり直し作業を進めることができるか？目的や方針、観点を変えた作業でなければ進めらないのではないでしょうか。(こういう状況になること自体、そもそも目的、方針、観点を決定して作業していないと推測されます。)

テスト工程の漏れや重複などの失敗を防ぎ、システムのQCを向上させるために、テストの方針、観点は重要になってきます。

単体テストの観点

テストの目的は、設計・製造したものの品質を保証することです。

そして、単体テスト工程で確認できることと単体テスト以降で確認できることがあります。

特に単体テストでは、後の工程やシステム運用時に、「一回でも処理を通せば確認できただろうと判断されるようなバグ」は取り除きたいです。

単体テストの工程だからできることは、ホワイトボックステストです。
個々の項目が正しい判定で正しく処理されているを確認できます。
そして、実際、画面で動かしたときに正しく動いているかの確認になるかと思います。 　　　　　　　　　　
(個々の入力や画面の表示など不自然な動きをしていないか確認します。)

この場合、単体テストの観点は「条件網羅」になります。

結合テスト、総合テストでは、処理されるデータの整合性の確認を行うことが中心になります。
テストケースを洗い出し、シナリオを作成してのブラックボックステストになります。

単体テスト工程の時だけ、ホワイトボックステストを行うことが可能だと思います。

VBなどコーディングしながらコンパイルしているのに条件網羅のテストをする必要があるのかという考えも思い浮かぶかもしれません。
コーディングするときに実際に画面を動かしながら、制御を確認しながら製造をしているからですが、その前提条件は、担当者が始めから作るものを例外を含め全て理解して開発を行うのであればということだと思います。

実際の開発現場は、残念ながらそれほど単純ではありません。

開発開始時に修正の必要がない完璧な仕様が決まっていることはないと思います。
開発がすすんでくれば常識となるような事柄も開発開始時には意識されていないことがあることも少なくありません。

もちろん、プロジェクトが進むにつれて、開発担当者も学習し、仕様の理解が深まります。
開発途中で仕様の漏れや矛盾点に気がつくことも少なくなく、要件の修正、設計の修正が生じることもあり、その都度、対応が必要になります。

スケジュールが進んでいくと開発担当者は当初の予定していた作業よりも多くの作業が必要がでてくるため、十分な考慮をするより場当たり対応をしてしまうこともよく目にします。 そのようななか、開発が進むとソースのコピペが繰り返されます。開発環境が日々複雑になっていく中で開発が進んでいくのが実際の開発現場だと思います。

これらを踏まえると、開発工程が完了時点で、再度、全ての機能が正常に動作しているか見直すことは重要になってきます。

ただ、気をつけたいポイントはあります。
パーツ、パーツで制御を確認しながら製造しているため、単体テストを行ってもバグが発生しないルートはすでに存在していることです。
ただ処理がエラーなく通ることの確認ではなく、正しく処理が行われることを確認する必要があると考えられます。

そこで条件網羅で単体テストをする際は、使用するパラメータを境界値、限界値、ＮＵＬＬ値など、うまく選択していく必要があると思います。

そして、画面の入力制御、出力情報、メッセージダイアログの内容が正しいかを確認します。(処理がエラーなく通るか以外にも実際目視で確認することはあると思います。)

また、条件網羅とは別に、データ更新定義書と実際に登録、更新されるデータ項目の型や値の確認も単体テスト工程で確認しておくべき作業だと思います。

単体テストを効率的にすすめるために

効率的に、条件網羅をテスト観点として単体テストを進めるために

  1. １．製造の完了
    • 製造完了したら、すべてのコメントの記述を見直す。
    • ※ソースコメントを正確に記述することは製造工程の作業です。
  2. ２．ソースコメントからテスト項目表を出力する
    • →「UT.Browser」でテスト項目表を作成
      ※コメントの未入力チェックを行うことができます
  3. ３．ソースレビュー
    • ・詳細設計書
    • ・ソース
    • ・単体テスト項目表

    条件網羅を単体テストの観点としてテストを行う場合、詳細設計書の機能が網羅されているかの確認を行うことが
    できないのでソースレビューで実装漏れがないかを確認します。
  4. ４．レビュー結果を修正、テスト項目表の再出力
  5. ５．単体テスト実施
    • 境界値、限界値を使っての条件分岐、ループ文、例外処理が正しく処理されることを確認する。
    • ・if文の判定、switch文の分岐が正しいかどうか、目視も含め単体テストで行うことには変わりはない。
    • ・パラメータや引数等のパターン確認やループ処理は、境界値、限界値、未入力をつかってを単体テストで行う。
    • ・メッセージの内容も事象と一致した内容が表示されるかどうかを確認(異常系含む)
  6. ６．データ更新定義書の確認

後のテスト工程は、単体テストが正常に完了していることが前提で進められます。
この前提が崩れてしまうと前工程の手戻り作業が発生することになり、その影響は小さくありません。
また、QCを高めるために、ソースのコメントの正確さは今後のメンテナンス、調査などに大きく影響します。


最終更新日：2012年09月05日