みなさん、こんにちは。前回はエレクスの第三者テスト専用ホームページ「ソフトウェアテスト.com」内で無償公開している「ソフトウェアテストのコツ ハンドブック」からテストの必要性などを紹介しました。今回は、そのテストにはどのような分類があるのかを見たいと思います。
■前回記事はこちら
テスト分類を明確にサービス
第三者検証サービスにおけるテスト内容は、システムの上流から下流まで網羅します。まず、ソフトウェアやプログラムなどの機能が正しく動作するかを検証する単体テストがあります。これは恒常的に実施されるもので、開発部隊の技術者も実施しています。これによってしっかりと欠陥や不具合を抽出します。次に、機能間の連携で不具合を検証する結合テストです。それが終われば、システムやソフトの全体動作を検証するシステムテストに入ります。最後に、機能／非機能を含めて正しくシステムが動作するかを確認する受け入れテストとなります。この流れはシステム開発の技術者であれば日頃から行っているものですが、その技術者がテスト手法にまで踏み込んで行っているかというと心もとない感がします。
発注者であるユーザーから見ると分かりにくいかもしれませんが、例えば一戸建ての家を建てたときに、単体テストは台所のキッチンシンクが指定の高さで設置されているか、換気扇はコンセントを入れて動くかなど。結合テストでは、シンクの水を流した時に水は排水パイプから漏れずに下水槽に流れるか、キッチン換気扇をオンにしたときに煙は室内に残らず家の外に排出されるかなど。そして受け入れテストでは発注者の要望通りに家具が配置され導線が確保できているかなどをイメージしていただければわかりやすいと思います。
次にテストの形態ですが、プログラムを実行して不具合を検出する「動的テスト」と、ドキュメントの確認（レビュー）やツールによるソースの自動解析のようにコードを実行しない「静的テスト」に分けられます。それぞれを実施することで不具合を検出するために補い合っています。違いは、動的テストが現象として現れた不具合を検証するのに対して、静的テストは不具合の原因となる欠陥を発見するという点にあります。どちらも非常に重要な役割を果たしています。 詳しくは、ソフトウェアテスト.comで無償配布している「ソフトウェアテストのコツ ハンドブック」＜ダウンロードページ＞からダウンロードしてご確認ください。
ハンドブックでは、「開発ライフサイクルでドラフトのドキュメントが入手でき次第テスト担当者はレビューを実施すべき」と指摘しています。これは、開発部門がテストしていてはなかなかできない取り組みです。つまり、第三者検証サービスによってはじめて不具合を客観的に検証できることを意味しています。こうした点はユーザーにもわかってもらいたいところですね。
次回はテストの設計手法に入りたいと思います。
ご愛読、ありがとうございました。