WRブログ

テストの計画とコントロールする方法

ソフトウェアの欠陥は、リリース後に大きな損失として返ってくる場合があります。
そのため、ソフトウェア開発において、テストはとても重要な役割を担っています。
そこで今回は、ソフトウェア開発でのテストがどのようにおこなわれているのかを解説します。
■テスト計画の立て方
ソフトウェアの開発者の中には、テストは開発者が同時並行でおこなえば良いと考えている人がいます。
しかし、テストは製品の最後の砦、いわばゴールキーパーのような存在です。
テストには以下のようなプロセスがあります。

①テスト計画を立てる
②テストの分析と設計
③テストの実装と実行
④テストの終了基準と評価
⑤テストの報告

まずは「テスト計画を立てる」について解説していきます。テスト計画を立てるためには、まずテストの目的を定める必要があります。
この場合の目的は、ソフトウェア自体の目的や、プロジェクトのスケジュール、テストにかけられる予算などによって変わってきます
■テストのスコープを考える
一般的にテストの目的は、テストのスコープに合わせて設定します(ユニットテストでは欠陥の検出、システムテストでは処理の速度など)。
その理由は、ひとつのテストでソフトウェアの全てを検証することはできないからです。
そのため、まずはテストのスコープを決めていきましょう。
■テストの戦略と終了基準を決める
スコープが決まったら、次に、どのようなテストをおこなって、何を検証するのかという「テストの戦略(ブラックボックステスト技法を使い、結合テストで欠陥がないか検証する、など)」と、どこでテストを完了するかという「テストの終了基準」を決めていきます。
テストでは、必ずしも、立てた目的が達成できるとは限りません。
そのため、目的とは別で終了基準を設定する必要があります。
この終了基準には「テストの目的を達成したかどうか」や「決めたカバレッジを満たしているか」などがあります。
■リソースを割り当て、スケジュールを立てる
テストをおこなう際のリソースには、人的リソース、時間的リソース、環境的リソース、予算的リソースなどがあります。

・人的リソースには、単にテストに避ける人員数だけではなく、テストごとに必要なスキルセットと、そのスキルを持った人をどれだけ用意できるか、なども含まれます。

・時間的なリソースには、納期やプロジェクトの期間に合わせて、どれだけの時間が割けるかがあります。時間的なリソースが割けない場合、人的リソースもしくは予算的リソースを要する場合が出てきます。

・環境的リソースは、テストを実施するために必要な動作環境、使用するテストツールなどが当てはまります。

・予算的リソースとは、新製品の開発で、ノウハウを持った人を外部から委託する場合や、テスト自体をアウトソーシングする場合などに検討する必要があるリソースです。

テストに割けるリソースが見えてくると、テスト全体のスケジュールが見えてきます。
このとき、テストに必要なスキルセットが揃っていない場合や、テスト環境が十分でない場合、そのための学習期間や、機材を揃える必要などがでてきます。
そのため、テスト計画は、ソフトウェア開発の初期段階から考える必要があります。

■テスト結果の評価
テストの計画を立てたら、いよいよテストをおこなっていきます。
しかし、テストには例外がつきもので、前述で立てた計画通りにテストをするためには、テストをコントロールする必要があります。
そこで、テストをコントロールするために必要なことをご紹介します。

まず、テストで出た結果の評価についてです。テストの結果から導き出せることは、合否判定だけではありません。
パフォーマンスの測定や、テスト実施時のリソースの効率などは、基準値に近い値であれば問題ないという場合も多いです。
また、単に数値を測定するだけのテストもあります。
■テスト結果のドキュメント化
テストが完了したら、それは「テスト報告書」としてドキュメント化する必要があります。
ここで勘違いされがちなのが「テストの実行結果をそのまま書いてもテスト報告書にはならない」ということです。
もちろん、テストの実行結果や、その合否判定は大切です。しかし、それだけでは報告書として不十分です。

テストの報告書に記載するべき内容としては、まず、立てたテスト計画に対して、どのようにテストがおこなわれたのか、実行結果や合否判定はどうであったか、リソースの消費状況はどうであったか、などがあげられます。
また、テストで出てきた欠陥に対する分析や考察もあると、次に報告書を読む人に対して丁寧であると言えます。
重要なのは、そのテスト結果を誰に報告するのか、です。それによって報告書の書き方も変わってきます。
■テストで見つかった欠陥の修正
テストで欠陥が見つかると、それは「インシデント」として報告されてきます。
インシデントとは、システムが正常な動作とは異なる動作をするため、修正・対策が必要な事項のことです。
見つかった欠陥の修正は、可能であればテストと同時並行でおこなわれます。
修正された箇所は再度テストがおこなわれ、影響範囲によっては、回帰テストなどで一度テストをパスした箇所にあらたな欠陥が出ていないかを検証する必要もあります。
★まとめ
●テスト計画の立て方
●テストを実施するうえで必要な事
●テストの結果報告とコントロールの仕方

ここまでで、テストの一通りの流れと、そのコントロールの仕方などについて解説してきました。
テストにも、開発と同じように流れがあることを理解しておきましょう。


【参考文献】:
『ソフトウェアテスト教科書 JSTQB Foundation 第3版』

【参考URL】:
http://itpro.nikkeibp.co.jp/article/COLUMN/20070920/282591/,(参照 2016年7月30日)
http://gihyo.jp/dev/serial/01/vital_point/0001,(参照 2016年7月30日)
http://www.itmedia.co.jp/im/articles/1111/07/news206.html,(参照 2016年7月30日)
http://gihyo.jp/dev/serial/01/vital_point/0014,(参照 2016年7月30日)

【無料ダウンロード】ソフトウェア品質向上ガイドBOOK

第三者検証のスペシャリスト集団である株式会社ウェブレッジが、特に上流工程でのソフトウェア品質向上の手法に関してまとめた資料を無料でご提供しております。

ソフトウェア品質向上ガイドブック

ソフトウェア品質向上ガイドブック

ソフトウェア品質向上ガイドブック

Scroll Up