機能テストと非機能テストの違いとは？目的・観点・実施タイミングを発注者向けに解説

「テストが終わりました」では判断できない——発注者がテスト工程を理解すべき理由

開発ベンダーから「テストが完了しました」と報告を受けたとき、発注者としてリリースの可否を判断できるでしょうか。多くの場合、その報告書には「テスト項目数」や「バグ件数」が並んでいますが、何がテストされていて、何がテストされていないのかを把握できなければ、実質的な判断はできません。

この問題の根本にあるのは、「テスト」という言葉が指す範囲のあいまいさです。テストには大きく分けて2種類があります。ひとつは機能テスト、もうひとつは非機能テストです。この2つの区別を知らないまま報告を受け取ると、システムが「仕様どおりに動くかどうか」は確認できていても、「実際の業務環境で耐えられるかどうか」がまったく検証されていない、という状態でリリース承認を出してしまうリスクがあります。

たとえば、社内の基幹システムを新たに構築したとします。機能テストでは「受注データを入力して保存できる」「帳票を正しく出力できる」といった動作を確認します。しかし、月末に100名が同時にアクセスしても処理が遅延しないか、不正アクセスに対して適切に防御できるか——こうした観点は非機能テストで初めて確認されます。ベンダーが機能テストしか実施していなかった場合、その報告書は「テスト完了」と書かれていても、本番稼働に向けた検証としては不十分です。

発注者がテスト工程を理解すべき理由は、技術的な詳細を把握するためではありません。「何が確認されていて、何が確認されていないか」を問える立場になるためです。その出発点として、機能テストと非機能テストの違いを知ることが必要になります。

本記事では、以下の順序で解説します。まず機能テストと非機能テストそれぞれの定義と目的を整理し、次に両者の違いを目的・観点・実施タイミングの軸で比較します。さらに非機能テストの種類（性能・負荷・ストレス・セキュリティ・ユーザビリティなど）を詳しく取り上げ、最後に発注者がテスト計画を確認する際の具体的なチェックポイントを示します。

機能テストとは何か——「仕様どおりに動くか」を確認するテスト

機能テストとは、システムや画面が要件定義・仕様書に記載したとおりに動作するかどうかを確認するテストです。開発会社に対して「この機能をこう動かしてほしい」と伝えた内容が、実際のシステム上で正しく実現されているかを検証します。

技術的な観点よりも、「業務として使えるかどうか」に近い視点で行われるテストだと理解すると、発注者側にもイメージしやすくなります。

機能テストで確認する主な観点

機能テストでは、主に以下の観点を確認します。

• 入力に対して正しい出力が返るか——フォームに値を入力したとき、期待どおりの結果が表示・保存されるか
• 操作の流れが仕様どおりに機能するか——ボタンを押したとき、次の画面に遷移するかなど、画面間の動作が正しくつながるか
• エラー時に適切なメッセージが表示されるか——必須項目が未入力のまま送信した場合など、例外ケースへの対応が仕様を満たしているか
• データが正しく登録・更新・削除されるか——操作の結果がデータベースに反映され、画面上でも正しく確認できるか

機能テストが対象とする典型的なケース——ログイン・データ登録・帳票出力など

発注者が日常業務で想像しやすい例を挙げると、機能テストの対象は次のようなケースに当たります。

• ログインできるか——正しいIDとパスワードを入力したときに画面に入れるか。誤ったパスワードを入力したときにエラーが表示されるか
• 注文が正しく保存されるか——商品を選択して注文を確定したとき、その内容がシステムに記録されているか
• 帳票が正しく出力されるか——請求書や納品書などを出力したとき、項目・金額・書式が仕様書の定義と一致しているか
• 検索・絞り込みが機能するか——条件を指定して検索したとき、該当するデータのみが表示されるか

これらはすべて、「仕様書に書いてあったことが、実際のシステムでも再現されているか」を確かめる作業です。機能テストは、発注者が要件として定義した内容と、開発者が実装した内容のずれを発見するための工程といえます。

非機能テストとは何か——「どれだけうまく動くか」を確認するテスト

非機能テストとは、システムが仕様どおりに動くかどうかではなく、どれだけうまく動くかを検証するテストです。速度・安定性・安全性・拡張性といった、システムの品質特性を確認することが目的です。

機能テストが「ログインできるか」「注文が完了するか」を問うのに対して、非機能テストは「1,000人が同時にアクセスしても応答が遅れないか」「不正なリクエストを受けたときに情報が漏れないか」を問います。

非機能テストが欠けたとき何が起きるか——リリース後に発覚するリスクの実態

非機能テストを省略した場合、機能上は正常に動作するシステムが、実運用では使い物にならないという事態が起きやすくなります。具体的なリスクとして、以下のようなケースが少なくありません。

• 重すぎて使えない：キャンペーン時や月末の集中アクセスで応答が極端に遅くなり、ユーザーが離脱する
• 障害から復旧できない：サーバー障害が発生した際に復旧手順が確認されておらず、業務が長時間停止する
• セキュリティ上の欠陥が露呈する：リリース後に脆弱性を突かれ、顧客情報が流出するリスクが発生する

これらはいずれも、機能テストをどれだけ丁寧に実施しても防ぐことができません。非機能テストが欠落していると、リリース後に初めてリスクが顕在化するケースがほとんどです。

非機能テストの種類一覧——性能・負荷・セキュリティ・ユーザビリティなど

非機能テストは単一の手法ではなく、複数の種類から構成されています。主なものを以下に整理します。

• 性能テスト：通常の利用条件下での応答速度・処理能力を確認する
• 負荷テスト：同時アクセス数を増やしたときにシステムがどこまで耐えられるかを検証する
• ストレステスト：限界を超えた負荷をかけて、障害発生時の挙動と復旧性を確認する
• セキュリティテスト：不正アクセス・脆弱性・情報漏洩リスクを検証する
• ユーザビリティテスト：実際の利用者が直感的に操作できるかを確認する

これらは「非機能テストの種類」として総称されますが、それぞれ目的も確認方法も異なります。発注者としては、どの種類が今回のプロジェクトに必要かを、テスト計画の段階で開発会社に確認しておくことが重要です。

機能テストと非機能テストの違いを整理する——目的・観点・実施タイミングの比較

機能テストと非機能テストは、名称が似ているため混同されやすいですが、確認する内容も実施のタイミングも異なります。テスト計画書や報告書を読む際に「どちらの話をしているのか」を判別できるよう、5つの比較軸で整理します。

• 何を確認するか（目的）：機能テストは「仕様どおりに動作するか」を確認します。非機能テストは「どれだけうまく動くか」、つまり速度・安定性・安全性といった品質特性を確認します。
• どの観点で評価するか：機能テストの観点は「要件定義書・仕様書に書かれた動作と一致しているか」です。非機能テストの観点は「レスポンスタイム」「同時接続数」「脆弱性の有無」など、数値や基準値との照合になります。
• いつ実施するか（タイミング）：機能テストは単体テスト・結合テスト・システムテストといった各工程で段階的に実施されます。非機能テストは、システム全体が組み上がった後のシステムテスト後半から受け入れテストにかけて実施されるケースが多いです。
• 誰が主体になるか：機能テストは開発ベンダーのQAチームが主体になることが一般的です。非機能テストのうち、性能テストや負荷テストは専門のエンジニアが担当し、ユーザビリティテストには発注側の担当者が関与するケースも少なくありません。
• テスト設計に必要な情報源：機能テストは要件定義書・画面仕様書・ユースケース図が主な根拠になります。非機能テストは非機能要件定義書やSLA（サービスレベルアグリーメント）、セキュリティポリシーが根拠となります。

テスト計画書を確認する際、「どの情報源をもとに設計されているか」を見ると、機能テストと非機能テストのどちらの話なのかを判別しやすくなります。非機能要件定義書が存在しない場合、非機能テストの設計根拠が曖昧になっているリスクがあるため、計画段階での確認が重要です。

非機能テストの種類を詳しく理解する——性能・負荷・ストレス・セキュリティ・ユーザビリティ

非機能テストは「品質特性の確認」という大きな目的を共有しながら、確認する観点によっていくつかの種別に分かれます。発注者として承認・確認を行う際は、それぞれの種別が「何を見るテストか」「自社のシステムに照らしたとき、なぜ必要か」を把握しておくと、テスト計画の妥当性を判断しやすくなります。

性能テストと負荷テストの違い——よく混同される2つの関係を整理する

「性能テスト」と「負荷テスト」は混同されやすい用語です。関係を整理すると、性能テストが上位概念であり、負荷テストはその中に含まれる手法の一つと理解するとわかりやすいです。

性能テストは、システムが「どれくらいの速さ・効率で動作するか」を確認するテストの総称です。応答時間・処理速度・リソース使用率などを測定します。ECサイトや社内の基幹システムのように、日常的に多くのユーザーが操作するシステムで特に重要です。

負荷テストは、性能テストの一種です。想定される同時アクセス数や処理量をシステムにかけ、基準値（例：ページ応答3秒以内）を満たすかを確認します。キャンペーン時に急激にアクセスが増えるサービスや、月末に処理が集中する業務システムなどで欠かせません。

ストレステスト・耐久テスト——限界と安定性を見るテスト

ストレステストは、通常の想定を超える負荷をかけ、システムがどの時点で限界を迎えるかを確認します。限界点の把握と、障害発生時の挙動（クラッシュするか、段階的に劣化するか）の確認が目的です。金融系やインフラ系など、障害時の影響が大きいシステムで特に重視されます。

耐久テストは、長時間稼働させた際のメモリリークや性能劣化を検出するテストです。24時間・72時間など、実運用に近い期間にわたって負荷をかけ続けます。常時稼働が前提のSaaSや監視システムで重要度が高くなります。

セキュリティテスト——不正アクセス・脆弱性を検出するテスト

セキュリティテストは、外部からの不正アクセスやデータの不正取得・改ざんに対する耐性を確認するテストです。SQLインジェクションやクロスサイトスクリプティング（XSS）といった既知の攻撃手法に対して脆弱性がないかを検証します。個人情報や決済情報を扱うシステム、外部公開するWebサービスでは、テスト計画への明示的な組み込みが求められます。

ユーザビリティテスト——使いやすさを評価するテスト

ユーザビリティテストは、実際のユーザーがシステムを操作し、直感的に使えるか・迷わず目的を達成できるかを評価するテストです。他のテスト種別と異なり、数値ではなくユーザーの行動・発言・表情などの観察が主な評価材料になります。社内ポータルや顧客向けアプリなど、操作者のITリテラシーが多様なシステムで効果を発揮します。

発注者がテスト計画を確認するときの5つのチェックポイント

ベンダーからテスト計画書や進捗報告を受け取ったとき、「内容が妥当かどうか判断できない」と感じる担当者は少なくありません。CLANEがプロジェクトの支援を行う際にも、発注者が確認すべき観点として以下の5点をお伝えしています。

1. 機能テストの観点だけで計画が終わっていないか

テスト計画書に記載されているのが画面操作や入力値の検証（機能テストの観点）のみで、性能・セキュリティ・負荷といった非機能テストが含まれていないケースがあります。機能テストと非機能テストの違いを意識しながら、両方の計画が存在するかを最初に確認してください。

2. 非機能テストの合否基準（閾値）が数値で定義されているか

「性能テストを実施します」と記載があっても、「応答時間が何秒以内であればOK」という閾値が定まっていなければ、テスト結果を合否判定できません。目標値が数値で明記されているかどうかを確認することが重要です。

3. 本番環境に近い条件でテストが行われるか

テスト環境のスペックや構成が本番と大きく異なる場合、テストをパスしても本番リリース後に性能問題が発生することがあります。特に負荷テストや性能テストは、本番に近い環境・データ量で実施されるかどうかを確認してください。

4. テスト結果がエビデンスとして記録・保管されるか

口頭や簡易報告だけでテスト完了とされると、後から問題が発生したときに経緯を追えなくなります。スクリーンショット・ログ・テスト成績書など、何らかの形でエビデンスが残る運用になっているかを確かめてください。

5. リグレッションテストの範囲が明確になっているか

機能追加や不具合修正を行った後、既存機能に影響が出ていないかを確認するのがリグレッションテスト（回帰テスト）です。どの機能を対象に、どのタイミングで実施するかが計画書に明示されていない場合、修正のたびに意図せぬ不具合が混入するリスクが高まります。

まとめ——機能テストと非機能テストは「両輪」として計画されているかを確認する

機能テストと非機能テストの違いは、一言で整理すると「仕様どおりに動くか」と「どれだけうまく動くか」という観点の差です。どちらか一方が優先されるわけではなく、両方が計画・実施されて初めてシステム全体の品質が担保されます。

機能テストだけが済んでいる状態では、同時アクセスが集中したときにシステムが応答しなくなるリスクや、セキュリティ上の脆弱性が残るリスクが見えないままリリースを迎えることになります。逆に非機能テストのみを実施しても、基本的な業務フローが仕様どおりに動かなければ、システムとしての価値は成立しません。

発注者として次に取るべきアクションは、大きく2つの方向性に整理できます。

• テスト計画書の確認：機能テストと非機能テストの両方が明記されているか、それぞれの実施タイミング・担当・合格基準が具体的に記載されているかを確認する
• ベンダーへの確認事項の整理：「性能テストの実施有無」「想定する同時接続数の設定根拠」「セキュリティテストの範囲と手法」など、非機能テストに関する項目を明示的に確認する

ベンダーから「テストは完了しています」と報告を受けた際に、それが機能テストだけを指しているのか、非機能テストも含むのかを確認できるかどうかが、発注者としての判断精度を左右します。テスト計画書を受け取った段階で、両輪が揃っているかを確認する習慣を持つことが、リリース後のトラブルを防ぐ実践的な一歩になります。