「機能テスト vs 自動テスト」はQAで最もよくある比較の一つですが、それは誤解に基づいています。これら2つの用語は対義語ではありません。これらは全く異なる事柄を説明しており、一方がなくてももう一方があったり、両方が同時に存在したりします。「機能テスト」か「自動テスト」か、という選択肢として扱うことは、チームが誤ったテスト戦略を構築する原因となります。
このガイドでは、これら2つの用語を解きほぐし、それぞれが属する2つの異なる軸を説明し、実際のAPIテストワークフローでそれぞれがどこに位置するかを示します。
カテゴリの誤り
この混乱は、2つの異なる質問への答えを比較することから生じます。
機能テストが答えるのは、**何をテストしているのか？** です。ソフトウェアが意図されたとおりに動作するか、機能、挙動、出力をテストします。
自動テストが答えるのは、**どのようにテストを実行しているのか？** です。人間が手作業で手順を実行する代わりに、ソフトウェアツールでテストを実行します。
これらは独立しています。「何をテストするか」と「どのように実行するか」は別々の軸です。機能テストは手動でも自動でも実行できます。自動テストは、機能的な動作をチェックすることもできますし、パフォーマンスのような非機能的な動作をチェックすることもできます。したがって、本当の比較は機能テスト対自動テストではなく、たまたま一緒に言及される2つの異なる側面なのです。
それが理解できれば、「機能テストと自動テスト、どちらを行うべきか？」という質問は意味をなさなくなります。正しい質問は、「何をテストすべきか？」、そして「そのテストのどれを自動化すべきか？」です。
機能テストとは
機能テストは、アプリケーションの各機能が要件に従って動作することを検証します。通常はブラックボックステストであり、テスターは内部コードを見ることなく入力と出力をチェックします。機能にインプットを与え、アウトプットを観察し、要件で規定されている動作と比較します。
APIの場合、機能テストとは、エンドポイントが正しいデータ、正しいステータスコード、正しいエラーレスポンスを返すことを確認することです。`POST /orders`は注文を作成するか？無効なペイロードを`400`で拒否するか？レスポンスは文書化されたスキーマと一致するか？これらは機能チェックであり、実際のレスポンスを期待されるレスポンスと比較するAPIアサーションに基づいています。
機能テストの強みは、直接的な関連性です。つまり、ユーザーが実際に気にする「機能が動作するかどうか」をチェックします。その限界はスコープです。機能テストだけでは、速度、負荷時の安定性、セキュリティについては何も語りません。エンドポイントは機能的に完璧でも、トラフィックが多いと崩壊することがあります。そのギャップをカバーするのがパフォーマンス テストです。機能テストは必要ですが、全体像ではありません。
機能テストの対義語は**非機能テスト**であり、パフォーマンス、負荷、セキュリティ、ユーザビリティなど、この用語の正しい対義語であり、「自動テスト」ではありません。
自動テストとは
自動テストは、人が手作業で手順をクリックしていく代わりに、ツールやスクリプトを使用してテストを実行し、結果をチェックします。入力と期待される結果を含むテストを一度定義すれば、ツールがオンデマンドで、スケジュールに従って、またはすべてのコード変更時に実行します。
自動テストの対義語は**手動テスト**であり、人間が各手順を実行します。これがこの用語の正しい対義語です。
自動化の価値は一貫性と規模です。機械は千回目も初回と全く同じテストを実行し、疲れることがありません。これにより、リグレッションテストは、すべてのコミットで実行するのに十分な費用対効果が得られます。そのコストは、自動テストを作成し保守する必要があること、そして判断を行うことはできず、期待するように指示されたことのみをチェックすることです。より詳細な説明は自動テストとはにあります。
決定的に重要なのは、自動化はテストの種類ではなく、実行メカニズムであるということです。機能テスト、パフォーマンステスト、セキュリティテストなど、**何らかの種類の**テストを自動化します。「自動テスト」だけでは、何がチェックされているのかがわかりません。
2つの軸がどのように組み合わさるか
2つの軸を組み合わせると、実際に存在する4つの真のカテゴリが得られます。
| 機能テスト | 非機能テスト | |
|---|---|---|
| 手動 | テスターがチェックアウトフローをクリックして動作を確認する | テスターがUIの応答性が良いかどうかを判断する |
| 自動 | スクリプトがエンドポイントを呼び出し、レスポンスが正しいとアサートする | 負荷テストが500人の仮想ユーザーを駆動し、レイテンシーを測定する |
すべてのセルは、正当で一般的なテストの種類です。左上の手動機能テストは、ほとんどの人が「テスト」と聞いて思い浮かべるものです。左下の自動機能テストは、現代のAPIテストスイートの大部分を占めるものです。つまり、機能を自動的にチェックするスクリプトやシナリオです。右の列は非機能的な作業であり、こちらも両方の方法で行われます。
したがって、意味のある決定は「機能テストか自動テストか」ではありません。それは次のとおりです。
- **どの動作をテストするか**：機能的および非機能的の両方にカバレッジが必要です。
- **どのテストを自動化するか**：安定していて、反復的で、価値の高いもの。探索的で判断を多く伴うチェックは手動に残します。
テストはどのセルにも属することができ、健全な戦略はこれら4つすべてを使用します。
APIテストにおける位置づけ
APIテストは、2つの軸が最も明確に一致する分野です。なぜなら、APIは自動化された機能テストに非常によく適しているからです。
APIには明確な契約があり、構造化されたリクエストとレスポンスがあり、レンダリングするUIがありません。そのため、その機能的な振る舞いはスクリプトでチェックしやすく、正確にアサートしやすいのです。したがって、APIの場合、機能テストの大部分は自動化されるべきです。ツールがすべてのコミットで実行できるのに、同じリクエストを手動で何百回も再送信し、レスポンスを肉眼で確認する理由などほとんどありません。
実用的なAPIテストのアプローチは次のようになります。ステータスコード、レスポンスボディ、スキーマ適合性、エラー形式などの機能チェックは、テストケースとして記述され、テストシナリオにグループ化されます。これらは、あらゆる変更時にCI/CDを通じて自動的に実行され、機能チェックを実行し、どの検証が失敗したかを正確に報告します。負荷やパフォーマンスなどの非機能チェックも、スケジュールに従って自動的に実行されます。手動による作業は、探索的テストと、APIが問題を真に解決しているかの検証、つまりスクリプトではなく判断が必要な検証作業に費やされます。
何を自動化し、何を手動で保持するか
2つの軸を明確に理解することで、実際に重要な質問へとつながります。つまり、実行できる機能テストのうち、どれを自動化すべきか？すべてを自動化することは無駄であり、間違ったものを自動化すると、遅くて壊れやすいスイートが生まれます。いくつかのルールが役立ちます。
**反復的で安定したものを自動化する。**今後2年間、すべてのコミットで実行する機能チェックは、完璧な自動化候補です。作成コストは何百倍にも回収されます。以前の機能がまだ動作することを確認するリグレッションテストは、最も明確なケースです。
**最初に価値の高いパスを自動化する。**ログインフロー、チェックアウト、主要なAPIエンドポイント、障害が発生すると重大なインシデントとなる可能性のあるものは、早期に自動化すべきです。これらは、納期に追われてもスキップできないテストであり、自動化によってその誘惑がなくなります。
**稀なものや不安定なものは自動化しない。**2回しか実行しないチェックは、スクリプト化する価値がありません。毎日変更されている機能は、毎日テストが壊れます。落ち着くまで待ちましょう。動くターゲットの時期尚早な自動化は、メンテナンスのノイズを生み出すだけです。
**探索的テストは手動で保持する。**自動テストは、探すように指示されたものしか見つけられません。スクリプト化されていない方法でソフトウェアを操作する人間は、誰も予測しなかったバグを見つけます。この作業も機能テストであり、意図的に手動で保持すべきです。
**判断に基づくチェックは手動で保持する。**エラーメッセージが本当に役立つかどうか、ワークフローが首尾一貫していると感じるか、APIがユーザーの問題を実際に解決するかどうかは、人間が必要です。どんなアサーションもそれらを捉えることはできません。
その結果、意図的な分担が生まれます。安定した、重要で、反復的なパスをカバーする大規模な自動機能スイートと、探索と判断に焦点を当てた、より小規模で継続的な手動作業です。思慮深く自動化するチームは、壊れやすいスイートなしに迅速なフィードバックを得ますが、すべてを自動化するチームは、出荷する代わりにテストのメンテナンスに終始することになります。
Apidogで自動機能APIテストを構築する
Apidogは、スクリプト不要で自動機能APIテストを構築するために作られています。エンドポイントを定義し、ステータス、ボディフィールド、スキーマ、応答時間に対してビジュアルアサーションを追加し、リクエストをテストシナリオにグループ化します。これらのシナリオは、オンデマンドまたはCIパイプラインで実行され、機能チェックを自動的に実行し、どの検証が失敗したかを正確に報告します。
同じワークスペースで負荷テストも実行できるため、機能テストと非機能テストの両方の軸を1か所で自動的にカバーできます。正しさを確認するために構築した機能シナリオは、パフォーマンスのために実行する負荷テストになります。Apidogをダウンロードして、既存のAPIの自動機能テストスイートを構築してください。
よくある質問
自動テストは機能テストの一種ですか？ いいえ。自動テストはテストを実行する方法です。機能テストはテストする内容のカテゴリです。自動テストは機能テストまたは非機能テストのいずれかであり、機能テストは手動または自動のいずれかです。
機能テストは自動化できますか？ はい、そしてAPIでは通常そうすべきです。自動機能テスト（すべての変更で機能をチェックするスクリプトやシナリオ）は、最新のAPIテストスイートの核となります。
機能テストの本当の対義語は何ですか？ 非機能テストです。パフォーマンス、負荷、セキュリティ、ユーザビリティなどです。これらは、機能が正しい出力を生成するかどうか以外の品質をチェックします。
すべての機能テストを自動化すべきですか？ いいえ。安定していて、反復的で、価値の高いチェックを自動化します。探索的テストと判断に基づく検証は手動で保持します。自動化は、何かが本当に良いかどうかを判断することはできず、期待に一致するかどうかしか判断できないからです。
チームはどこから始めるべきですか？ 自動化された機能APIテストから始めるべきです。これらは高速で安定しており、コアロジックをカバーします。そこから自動化された非機能テストと手動の探索的テストを追加します。
自動テストは手動テスターに取って代わりますか？ いいえ。それは、テスターが探索的テスト、エッジケース、そしてソフトウェアが本当に良いかどうかを判断することに集中できるように、同じチェックを繰り返すという反復的な作業の部分を置き換えます。これらのタスクには人間が必要であり、手動でリグレッションチェックリストをクリックするよりも価値が高いです。
同じテストが機能テストと自動テストの両方になりえますか？ はい、そしてほとんどのAPIテストはまさにそれです。自動化された機能テストです。エンドポイントを呼び出し、レスポンスが正しいとアサートするスクリプトは、機能をチェックし、自動的に実行されます。これら2つのラベルは、矛盾ではなく、同じテストの異なる側面を説明しています。