ソフトウェアの機能テストとは？テストの適用範囲や自動化のメリットを紹介

本ブログでは、ソフトウェア開発における「機能テスト」について詳しくご紹介します。

まずは「機能テストの概要・システム開発の工程」について整理。
その後「機能テストの種類や適用範囲・自動化」についても一挙に解説します。

「機能テスト及び、開発の全工程を知りたい」「機能テストをスムーズに進めたい」という方は、ぜひご一読ください。

そもそものテストケース（テスト計画やプロセスなど）についてはこちらをご覧ください。
テストケースのBlogはこちら

テスト仕様書・計画書作成の方法やガイドをまとめた資料はこちら。 巻末に項目のサンプルも用意しています。

機能テストとは、ソフトウェアテスト手法のひとつです。

開発における機能とは、ソフトウェアの機能が「何をするか」を指します。

そのため、機能テストでは「結合したプログラム＝ひとつの機能」として捉え、そのテスト対象が品質要求・仕様を満たしているかを検証します。

また、機能テストは品質保証におけるプロセスのひとつです。
そのため、性能テスト・負荷テストと同様に「システムテストの一環」として実施されることが大半です。

テスト手法は一般的に「ホワイトボックステスト」と「ブラックボックステスト」に大別されます。
機能テストでは主に、ソフトウェアの内部構造は考慮せずに外部動作を検証するため、ブラックボックステストに分類されます。

ブラックボックステストではソフトウェアの内部構造を考慮せず、仕様書などからテスト項目を洗い出すことで仕様を満たしているかを検証します。

一方でホワイトボックステストではソフトウェアの内部構造を理解した上で、それらが開発側の意図した通りに動作しているかを検証します。

システム開発は品質維持・向上のため、決められた工程に沿って実行します。

ここからは、全体像を理解すべく「システム開発の工程」についてご紹介します。開発工程を理解することで、システム開発がよりイメージしやすくなれば幸いです。

この段階では、顧客とともにシステムについて
「どのような開発手法・要素を盛り込みたいか」を明確化します。

主にシステムの運用方法・予算・人員・スケジュールなど、開発の必須要件を決定します。

また、システム開発はこの間に作成される「要件定義書」に基に実行されます。
そのため、予めトラブル発生防止のために、開発側と顧客側の認識に相違点などがないかすり合わせを行うことも大切です。

外部設計は基本設計とも呼ばれ、要件定義書を基にユーザーが閲覧する部分（インターフェース）を決める工程です。

また、「外部設計書」は一般的に開発側が作成します。

プロジェクトの規模感・内容によりますが、外部設計書はシステムの各機能別で作成します。さらに、顧客側と相互にユーザー視点・品質要求などのフィードバックを行っていきます。

また、外部設計書は顧客向けのドキュメントであるため、曖昧な表現や専門的な用語・データの記載はできるだけ避けましょう。

外部設計が決定次第、内部設計を行います。

内部設計は詳細設計とも呼ばれ、外部設計書を基にプログラムの各設定などを開発側の視点で「内部設計書」にまとめる工程です。

また、外部設計書は開発側のエンジニア向けに作成するドキュメントです。

内部設計でプログラミングがある程度作成できたタイミングで、製造工程に入ります。
開発側のエンジニアが、内部設計書を基にプログラミングを実行します。

プログラミング後はテスト工程に戻り、プログラムの動作が要件定義書を満たしているかを確認します。

まずはプログラム作成直後に「単体テスト」を実行します。

単体テストでは主に、個々の機能（モジュール）ごとに不具合がないかを検証します。
万が一途中で不具合を検出した場合はその都度修正・復旧作業を行い、テスト結果を振り返りながらプログラムを完成させます。

単体テスト完了後は「結合テスト」を実行します。
テストで確認する事項
複数の機能（モジュール）を組み合わせた状態で

• サブシステムに不具合が発生しないか
• インターフェース上に違和感やずれがないか
• 「サブシステム間の連携が正常になされているか

などを確認します。

また、大規模なプロジェクトにおけるサブシステム間の連携確認では、結合テストを「内部結合テスト/外部結合テスト」の2段階に分けて実行することもあります。

結合テスト後には、開発側の最終工程である
「総合テスト（システムテスト）」を行います。

総合テストでは、システム全体が不具合なく要件定義を満たした動作をしているかを確認します。また、大量アクセスなどの耐久性や処理速度に対する挙動など、多方面から抜け漏れのないよう検証を行います。

総合テスト後には「運用テスト」を実行します。
運用テストはシステムの納品・リリース前に行うため、品質に直結する重要なテスト工程です。

顧客の要求や要件定義を満たした上で、実際の運用環境下で不具合がなく正常に動作するかを検証します。また、ユーザビリティ上のトラブルなどを想定し、今までのテストと比較しながら細部まで確認を行います。

ここまでの全テスト工程をクリア次第、開発したシステムのリリース（システム移行）を行います。具体的には実際にシステムを利用できるよう、旧システムからの移行作業を実施します。

旧システムとの仕様の違いによるトラブルなど、さまざまな懸念点を考慮する必要があるため、最も慎重に行なわれる工程です。そのためリリース工程では、予め「移行手順書」の準備を要します。

想定される懸念点や作業手順を整理しておくことで、落ち着いてスムーズに移行作業を行うことができます。

移行作業は主に、一気に切り替えを行う「一斉作業」と、
各機能を徐々に切り替えていく「順次移行」があります。

機能テストには、以下の４種類があります。

• スモークテスト
• 健全性テスト
• 回帰テスト
• ユーザビリティテスト

ここからはそれぞれの機能テスト方法についてご紹介していきます。

スモークテストとは、ソースコードの開発・追加・修正を終えた開発途上のソフトウェアにおいて行われるテスト方法です。主に各ビルドに対して実行されます。

「ソフトウェアが正常に起動するか」「主要な機能が動作するか」などを予備的かつ簡易的に確認するテストです。

開発作業でのソースコードの些細な不備やビルドの失敗など、手戻り防止に有効なテストです。

健全性テストとは、サニティテストとも呼ばれます。主に安定したビルドをテスト対象としており、スモークテストと比較すると、狭い範囲を深く確認する検証作業であると言えます。

具体的には「新機能追加・不具合修正後にそれらが適切に実行され、求められている機能を満たしているのか」を確認します。

回帰テストは退行テスト、リグレッションテストとも呼ばれます。
プログラムの1部分を変更・修正した際に、他の部分に予期せぬ不具合などの影響が出ていないかを確認する」テストです。

作業工数がかかることからスケジュールなどの都合上、省略されるケースもありますが、不具合の残存したシステムのリリース防止などに寄与する重要なテスト工程です。

ユーザビリティテストとは、開発システムの利用が想定されるユーザーを意識して行うテスト方法です。

想定ユーザーに製品のプロトタイプを使用してもらうことで、システムのユーザビリティレベルや、内容を調査・分析します。

上記方法によるレビュー獲得により、プロトタイピングを重ねることができるだけでなく、開発側が見落としていた改善点を発見し、ユーザーに愛される製品へのブラッシュアップが可能となります。

機能テストの適用範囲は主に「システム/各サブシステム/個々のプログラム」などさまざまな階層です。そのため、機能テストは各テストレベルでの実施が必要になります。

機能テストの適用範囲は下記のように、さまざまな階層にわたります。

• システム
• 各サブシステム
• 個々のプログラム　など

そのため、機能テストは各テストレベルでの実施が必要になります。

例えば、個々のプログラムに関する仕様レベルであれば「単体テストレベル」での実施となるでしょう。一方、システム全体の仕様レベル・ユーザビリティレベルなどで実行する場合には「システムテストレベルの機能テスト」となります。

システム開発は年々複雑化の一途を辿っています。そんな中、機能テストが自動化できることをご存知でしょうか？

昨今、品質を落とさずに業務を効率化し、バランス良く技術的負債を軽減するソリューションとして「テスト自動化」を導入する開発プロジェクトが増加傾向にあります。

また、テスト実行～結果レポートの生成までを自動化することで、さまざまなメリットがもたらされます。

自動化の主なメリットは、以下の通りです。

機能テストを自動化するメリット

• テスト工程の抜け漏れ・ミスの防止
• テストの妥当性向上
• テスト作業工数の削減
• テストシナリオ、パラメーターなどの作成時間の確保、クオリティ向上
• 過去テストのシナリオ活用による回帰テストの工数削減
• 同一形式でのテストレポートの出力・共有が可能
• 上記により、担当者ごとの結果のばらつきもチェック可能

いかがでしたでしょうか？今回はソフトウェア開発における「機能テスト」について種類や適用範囲、自動化までを一挙にご紹介しました。正しい手順で質の高いテストを実行するためにも「システム開発の工程」は各内容を含めて考慮に入れておくと良いでしょう。

本ブログを通して、機能テスト・システム開発工程に関する知識をより深めていただければ幸いです。また、「機能テストの自動化」についても導入ご検討のきっかけとなれば幸いです。