ソフトウェア開発におけるテストの役割

ソフトウェア開発において品質に大きく関わるのがテストである。仕様通りに動いているか、重大なバグがないか、使い勝手が悪くないか、複数の視点から行うテストを無事クリアしたソフトウェアが世に送り出される。最近ではスマートフォンの普及で個人製作のアプリもこれまで以上に多く市場に流通しているが、やはりIT技術者不足や開発期間が足りないせいかバグが多い印象を受ける。そして、個人で利用するアプリ以上に、業務で扱うものはより高い品質を求められている。ソフトウェア品質に大きく関わるテストがどのように行われているのか解説する。

デバッグとテストの違い

デバッグとテストはプログラムの欠陥を探し出すという点では似通っており、開発に詳しくないと違いがわからず混同してしまいがちだ。その違いは以下の通りである。

デバッグ

発見されたバグ・不具合の原因を特定
原因のプログラムを修正
バグ・不具合が修正されたか確認
作業者：開発者・デバッガー

テスト

ソフトウェアのバグ・不具合を発見
開発者に対してバグ・不具合を報告
開発者による修正後、バグ･不具合が解消されたか確認
ソフトウェアの機能、性能などの品質を評価
作業者：テスト担当者、テスター

テストはバグを見つけるだけでなく、機能や性能を評価するために行っているのである。これによってソフトウェアの品質が明確化されるのだ。デバッグはテストによって見つかった故障の原因となる欠陥を見つけ解決する作業である。
デバッグとテストは似通っているようで、担当する役割、作業者はそれぞれ異なっている。

テストプロセス

ソフトウェア開発において、テストは大変重要な役割を担っている。テストを行う際の手順（テストプロセス）を以下にまとめた。

テスト計画

テストのスコープ（範囲）や目的を明確にし、その後のテスト作業の方針や体制、スケジュールなどを計画
作業の方針を検討する際は、入力成果物と出力成果物も合わせて考える。場合によっては十分な入力成果物が要件定義や設計の段階で作成されていないこともありえる。体制やスケジュールを決定する際には、そういった開発の状況も考慮した上で作業量を見積もる必要がある。テスト作業の終了基準もこの段階で策定する。
テスト管理

テスト計画以降の作業が計画通りに実施できているかどうかを確認
問題がある場合は、その状況に対する対応を行う。テスト分析からテスト実装までの作業については主に進捗管理が中心になる。テスト実行の段階では実際にテスト対象のバグを発見するため、バグの発見状況の把握と、それに対する対応、すなわち品質管理を実施する。
テスト分析

テストベース（テストケースを作成する際にインプットとなる成果物）を整理する
テストすべき条件や要件、さらにはそれを実現するテストケースの作成方針（どのテスト技法を使うか、など）を決定する。テストベースが不足している、テストベースの品質が悪い、といった状況も考えられるため、必要に応じて成果物の作成やレビューを実施する必要がある。
テスト設計

テスト分析で洗い出した条件や要件を満たすような具体的なテストケースを作成
このときテスト技法を用いて、抜けもれや重複のないテストケースを作成することが望ましい。また、テストケースを作成する際には、操作や期待値だけでなく、実行するためにはどのような環境や事前条件が必要か、などを明らかにする必要がある。
テスト実装

テスト設計で作成したテストケースから、実施するための具体的な手順を作成
手順と合わせて想定した結果を発生させるためのデータや、テスト自動化を実施する場合は、テストスクリプトもこの作業で作成する。
テスト実行

テスト実装で作成した手順に従ってシステムを操作し、期待した結果が出るかどうかを確認
期待通りにいかない場合は、キャプチャなどの証跡を残してインシデントとして報告する。また、インシデントの原因分析も合わせて実施する。原因の特定、修正が完了したら、発見元のテストケースを再度実行し修正されたかどうかを確認する。またその際、修正の影響を分析した上で、影響箇所については関連する他のテストケースを再度実行する（回帰テスト）必要がある。
終了判定

テスト実行の結果などを分析し、作業を終了して次に進んでよいかどうかを判定
分析対象は、バグの検出状況などがあげられる。判定基準はテスト計画で決定したものを利用する。ただし、基準に満たなかったからといって即座に作業をやり直すのではなく、計画の段階で予期していなかったものの妥当と考えられる理由がある場合は、そのまま終了と判断することがある。そうでない場合は、必要に応じて追加テストなどを実行する。
終了作業

終了判定を通った後の作業の最終確認や今後の活動へのフィードバックを実施
計画通りに成果物が作成されているか、未対応のインシデントはないか、あるとしたら今後の対応方針は決まっているか、などを確認し、テスト結果報告書や品質結果報告書などを作成する。

以上がテストプロセスを構成する8つのテストの作業に関する説明である。これらをきちんと実施することでテストの漏れや無駄がなくなる。

テストの大分類

ソフトウェア開発におけるテストは大まかに3つに分類される。誰がどのような目的で行っているのか、それぞれ詳しく記載する。

デベロッパテスト

デベロッパと名前の示すとおり開発者が行うテストのこと。コーディングと併行して行う
自分で書いたコードに誤りがないかを確認するためのテストである。テスト可能な最小単位で行うため不具合発見が早い｡また開発者がテストを行うため、コード内容を把握していることにより原因究明がしやすいという利点がある。このテストは設計書からテストケースを作成するため、テストケースに誤りがあった場合は問題を発見できない。
カスタマテスト

ソフトウェアの発注者やユーザーによって実施されるテスト
発注者の環境で利用可能か、要求に沿っているか、といった水準を満たしているか確認するためのテストである。このテストによってソフトが完成するかどうかが決定される。
QAテスト

ソフトウェアの品質管理、測定を目的として行うテスト
QAとは「Quality Assurance」の略で品質保証という意味である。バグの検出や性能、セキュリティ、使いやすさ、多角的な視点からソフトを評価する。ソフトウェアの信頼性を向上するためのテストである。また、QAは開発チームとは交じらず、独自の組織として機能させるケースの方が多い。

テストの種類

ソフトウェア開発におけるテストは開発状況に応じて、テストの目的や手法が異なる。そして会社によってそれぞれ呼称が異なっていることも多々ある。ここでは一般的なテストの種類を紹介する。

単体テスト

「UT(=Unit Test)」と略称されることがある。作成したプログラムを構成する小さなユニットが設計どおりに機能しているか検証することである。主にバグを見つけるために行うテストである。ソフトウェアの中の一つのパーツに注目するため問題箇所の発見、修正は比較的に容易で基礎的なテストだといえるだろう。そのため、このテストを疎かにすると問題発見に余計な手間を取られてしまうため、重要なテストである。
プログラムを実装した開発者が単体テストを行うケースが多い。
結合テスト

「統合テスト」、「連結テスト」、「IT(Integration　Test)」、などと呼ばれることが多い。結合テストは単体テストを行ったユニットを複数結合することで正しく動作するかテストする。ユニット単体で動いたものが、他のユニットと結合することで機能に問題がないかテストする。
どこから単体で、どこから結合なのか明確な決まりはなく、両テストの境界が曖昧になることがある。そのため個々のプロジェクトで基準が変わることがある。
総合テスト

「ST(System Test)」と略称される。個々のプログラムや機能を結合した完成品に近いソフトウェアをテストする。結合テストよりプログラムが大きくなるため、プログラム間の連携が正しく取れているかが重要である。要件通りの機能、性能であり、致命的なバグがないことが求められる。
受け入れテスト

「UAT」、「承認テスト」とも略称される。クライアントに対して開発したシステムやソフトウェアを引き渡す前に行う。システムの不具合を見つけることが目的ではなく、“実際に使うことが出来るシステム”が開発ベンダーより正しく納品されたかどうかを検証する。そのため、リリース直前の工程で行われることが多い。
運用テスト

導入テスト、OT(Operations Test)とも略称される。ソフトウェア開発の最終段階でシステムが完成したと判断された際に行う。一般的にはソフトウェアを発注した企業の担当が行うもので、受入れテストや出荷前テストを兼ねることもあり、実際の業務手順に沿ったテスト計画を立てて実施する。本番に近い環境で行うため、ソフトウェアを受諾するかの判断をすることがある。