はじめに
先日「ハッピーパス（Happy Path）」という単語を知って、「こんな用語あったんだ」と驚きました。
知らなかったの恥ずかしい…(てかみんな当たり前に知っているのか…？)
調べてみると、テストの世界には意外と知られていない（けど覚えると便利な）専門用語がたくさんあることに気づいたので、この記事にまとめてみます。
「知ってて当然」というよりは「知ってると会話やドキュメントの理解がスムーズになる」用語を中心にピックアップしました。
おさらい：ハッピーパスとサッドパス
ハッピーパス（Happy Path）
ユーザーが想定通りに操作し、エラーも例外も発生しない「正常系」のシナリオのことです。例えば「ログインフォームに正しいIDとパスワードを入力してログインに成功する」という流れがこれにあたります。
サッドパス / アンハッピーパス（Sad Path / Unhappy Path）
ハッピーパスの対義語で、エラーや例外が発生する「異常系」のシナリオを指します。「パスワードを間違えてログインに失敗する」「必須項目が未入力で送信される」などが該当します。ハッピーパスとセットで覚えると理解が早いです。
テストの種類・観点に関する用語
エッジケース（Edge Case）/ コーナーケース（Corner Case）
入力値の境界や極端な条件で発生する、見落としがちな不具合パターンのことです。エッジケースは「1つのパラメータが極端な値を取る場合」、コーナーケースは「複数の条件が同時に極端な値を取る場合」というニュアンスの違いがあります。
スモークテスト（Smoke Test）
「煙が出ていないか」を確認するイメージから来た用語で、本格的なテストの前に「そもそも最低限動くか」をざっくり確認するテストです。ビルド後の動作確認などでよく使われます。
サニティテスト（Sanity Test）
「正気度テスト」と訳されることもあります。特定の機能や修正箇所が、期待通りに動作するかをピンポイントで素早く確認するテストです。スモークテストと混同されがちですが、スモークテストは「広く浅く」、サニティテストは「狭く深く」というイメージです。
リグレッションテスト（Regression Test）
日本語で「回帰テスト」。コードを変更した際に、既存の機能に予期せぬ影響（デグレ）が出ていないかを確認するテストです。
モンキーテスト（Monkey Testing）
まるで猿がキーボードやマウスをランダムに操作するかのように、無作為な入力や操作を行ってシステムが壊れないかを確認する手法です。意外と重大なバグの発見につながることがあります。
ファジング（Fuzzing）
モンキーテストと近い性質を持ちますが、単なるランダム操作ではなく、文法ベース生成やミューテーションベース生成といった、より体系的・自動化されたツールによって不正な形式のデータを意図的にプログラムに送り込み、クラッシュや脆弱性を探す手法です。セキュリティテストの文脈でよく登場します。
テスト設計技法に関する用語
同値分割（Equivalence Partitioning）
入力値を「同じ結果になるはずのグループ」に分割し、各グループから代表値を1つ選んでテストする技法です。すべての値を試す代わりに効率よく網羅性を確保できます。
境界値分析（Boundary Value Analysis）
バグは境界線上で発生しやすいという経験則に基づき、値の境界（最小値、最大値、その前後）を重点的にテストする技法です。同値分割とセットで使われることが多いです。
デシジョンテーブル（Decision Table / 決定表）
複数の条件の組み合わせと、それに対応する動作を表形式で整理し、条件の組み合わせに漏れがないかを確認するための設計技法です。
ペアワイズテスト（Pairwise Testing）
条件の組み合わせが多すぎて全パターンをテストできない場合に、「任意の2つの条件の組み合わせ」を必ず1回はカバーするように、効率的にテストケースを絞り込む手法です。なお「直交表（Orthogonal Array）」はこのペアワイズ網羅を数学的に実現するための手法の一つであり、両者は同義語ではありません。
テストの品質・構造に関する用語
フレーキーテスト（Flaky Test）
同じコード・同じ条件で実行しているのに、成功したり失敗したりする不安定なテストのことです。タイミング依存や外部リソースへの依存が原因になることが多く、CI/CDの信頼性を下げる厄介な存在として知られています。
テストダブル（Test Double）
テスト対象が依存している外部要素（DB、API、他クラスなど）を、テスト用の代役に差し替える際の総称です。この中には以下のような種類があります。
- モック（Mock）：呼び出されたかどうかなど、振る舞いを検証するための代役
- スタブ（Stub）：あらかじめ決められた値を返すだけの単純な代役
- フェイク（Fake）：簡易的な実装を持つ代役（例：インメモリDB）
- スパイ（Spy）：実際の処理をしつつ、呼び出し履歴なども記録する代役
- ダミー（Dummy）：ただ引数を埋めるためだけに存在し、実際には使われない代役
「モック」と一括りに呼んでしまいがちですが、実は目的によって呼び方が違います。
テストピラミッド（Test Pyramid）
「単体テスト（Unit Test）を土台に多く、結合テスト（Integration Test）を中間に、E2Eテストを頂点に少なく」という、テストの理想的な比率を表したモデルです。
アイスクリームコーン（Ice Cream Cone）アンチパターン
テストピラミッドの逆で、E2Eテストや手動テストばかりが多く、単体テストが少ないという望ましくない状態を指すアンチパターンです。テストピラミッドを覚えると同時に知っておくと理解が深まります。
ちょっと発展的な用語
ミューテーションテスト（Mutation Testing）
意図的にソースコードに小さな変更（バグ）を注入し、既存のテストコードがその変更を検知できるかどうかを確認することで、テストコード自体の品質を評価する手法です。
ゴールデンマスターテスト（Golden Master Testing / Characterization Testing）
仕様書がない、あるいはロジックが複雑すぎるレガシーコードに対して、現状の出力結果を「正解（ゴールデンマスター）」として保存し、リファクタリング後も出力が変わらないことを確認する手法です。
プロパティベーステスト（Property-Based Testing）
具体的な入力値と期待値のペアを1つずつ書くのではなく、「常に成り立つべき性質（プロパティ）」を定義し、ツールが自動生成した大量のランダムな入力でその性質が破られないかを検証する手法です。
スナップショットテスト（Snapshot Testing）
コンポーネントの出力結果（UIのレンダリング結果など）をスナップショットとして保存しておき、以降の実行で差分が出ていないかを比較するテスト手法です。フロントエンド開発でよく使われます。
コントラクトテスト（Contract Testing）
マイクロサービスなどでAPIを介して連携するサービス間で、「こういうリクエストにはこういうレスポンスを返す」という契約（コントラクト）が守られているかを検証するテストです。
カオスエンジニアリング（Chaos Engineering）
本番環境やそれに近い環境で、意図的に障害（サーバー停止、ネットワーク遅延など）を注入し、システムの耐障害性を検証する手法です。Netflixの「Chaos Monkey」というツールが有名です。
まとめ
テストの世界には「ハッピーパス」のように、知っているとシステムの品質について会話しやすくなる用語がたくさんあります。今回まとめた用語を意識しながらテストを設計・実装すると、テストケースの抜け漏れに気づきやすくなったり、チーム内での認識合わせがスムーズになったりするのではないかと思います。
他にも「これは面白い用語だ」というものがあれば、ぜひコメントで教えてください！