ア行

アドホックテスト

• 計画を立てずに経験と直感に基づいて行う非形式的なテスト
• テスト設計書やテストケースを作成せず、思いついた操作を試す探索的な手法
• バグの再現手順が不明確な場合や、テスト観点の抜け漏れを探す際に有効

アサーション

• プログラム内で特定の条件が満たされているかを検証する仕組み
• 条件が偽の場合にエラーを発生させることで、不正な状態を早期発見できる
• 自動テストでは期待値と実際の値を比較する際に使用される

アジャイル開発

• システムやソフトウェア開発におけるプロジェクト開発手法のひとつ
• 大きな単位でシステムを区切ることなく、小単位で実装とテストを繰り返して開発を進める
• 従来の開発手法に比べて開発期間が短縮されるため、アジャイル（素早い）と呼ばれている

インシデント

• 調査や対処が必要な事象や問題の総称
• バグや障害だけでなく、仕様の不明点や確認事項も含まれる
• チケット管理システムで管理されることが多い

インスペクション

• 最も形式的なレビュー手法で、定義された役割と手順に基づいて実施される
• 司会者、記録者、レビューア、モデレータなどの明確な役割分担がある
• メトリクスを収集し、プロセス改善に活用する

インテグレーションテスト

• 複数のモジュールを結合した時に正しく機能するかを確認するテスト
• 主にモジュール間の接続点（インターフェース）がうまく機能するかを確認する場合と、結合した状態で外部から見て一体として正しく機能するかを確認する場合がある
• 結合テスト、統合テストと同意

インフォーマルレビュー

• 最も非形式的なレビュー手法で、文書化されたプロセスを持たない
• 同僚にコードや仕様を見てもらって意見をもらう程度の軽いレビュー
• 短時間で実施でき、早期にフィードバックを得られる

ウォーターフォール開発

• 要件定義、設計、実装、テスト、運用という工程を順番に進める開発手法
• 各工程が完了してから次の工程に進むため、後戻りしにくい
• 大規模システムや要件が明確なプロジェクトで採用されることが多い

ウォークスルー

• レビュー手法の一つで、レビューイが成果物の内容をレビューアに説明すること
• 主な目的は欠陥の発見、ソフトウェアプロダクトの改善、異なる実装方法の検討など
• 典型的には作業成果物の作成者がレビューミーティングを主導する

受け入れ基準

• ユーザー、顧客、その他の認可団体が、コンポーネントやシステムを受け入れる場合、満たさねばならない基準

受け入れテスト

• システムが、ユーザーのニーズ、要件、ビジネスプロセスを満足するかをチェックするための公式なテスト
• このテストにより、システムが受け入れ基準を満たしているかどうかを判定できる

エクスプローラトリーテスト

• テスト設計とテスト実行を同時に行う探索的なテスト手法
• テスターの経験や知識を活用し、学習しながら動的にテストを進める
• タイムボックス（決められた時間枠）を設定して実施することが多い

エスカレーション

• 問題や課題を上位者や関係部署に報告し、判断や対応を仰ぐこと
• 自分の権限や知識では解決できない場合に行う
• 迅速なエスカレーションは問題の早期解決につながる

エンドツーエンドテスト（E2Eテスト）

• システム全体を通じたユーザーシナリオを実行し、実際の使用環境に近い状態で動作を確認するテスト
• フロントエンドからバックエンド、データベースまで含めた統合的な検証
• ユーザーの実際の操作フローに沿ってテストを行う

エンドユーザー

• ある製品を実際に使ったり消費したりする人や組織のこと
• 製品の作り手や売り手から見て、直接の顧客（クライアント）や所有者と、実際の利用者が異なる場合に用いられる概念

カ行

開発環境

• 開発中の機能を見てもらう時などに使用する場所
• stagingよりさらにカジュアルな環境で、簡単に作って潰すような使われ方をする
• development/dev環境とも呼ばれる

回帰テスト

• プログラムの修正後に、既存機能に影響がないことを確認するテスト
• リグレッションテストと同意
• 自動化して繰り返し実行されることが多い

境界値分析

• 入力値の境界付近でバグが発生しやすいことを利用したテスト技法
• 例：1〜100の範囲の場合、0、1、100、101をテストする
• 同値分割と組み合わせて使用されることが多い

キャッシュ

• 英語でCacheと表記し、貯蔵庫、隠し場所という意味を持つ
• よく使うデータを取り出しやすいところにあらかじめ準備しておく仕組み
• 身近な例：インターネットでページを閲覧した際、一度アクセスしたページのデータをブラウザで一時的に保管し、2回目以降にアクセスした際、表示スピードを上げる

クリティカルパス

• プロジェクトの完了に最も時間がかかる一連の作業の経路
• この経路上の作業が遅れると、プロジェクト全体の遅延につながる
• スケジュール管理において重要な概念

クローズ

• チケットや課題を完了済みの状態にすること
• バグが修正され検証も完了した場合などに行う
• ステータス管理の最終段階

結合テスト

• 複数のモジュールを結合した時に正しく機能するかを確認するテスト
• 主にモジュール間の接続点（インターフェース）がうまく機能するかを確認する場合と、結合した状態で外部から見て一体として正しく機能するかを確認する場合がある

ケースバイケース

• 状況や場合によって判断や対応が異なること
• テストでは仕様が曖昧な場合に「ケースバイケース」と表現されることがある
• 明確な基準を設けることが望ましい

検証環境

• 本番リリース前の動作検証を行う場所
• ほとんど本番に近い環境だが、サーバースペックは落としてあったり、外部API接続がテスト環境につながっていたりなどが異なる
• staging/stg環境とも呼ばれる

コードレビュー

• プログラムコードの品質を確保するために、他の開発者がコードを確認すること
• バグの早期発見、コーディング規約の遵守、知識共有などが目的
• プルリクエストを通じて実施されることが多い

サ行

サニタイジング

• ユーザーからの入力値に含まれる特殊文字を無害化する処理
• XSS攻撃やSQLインジェクション攻撃を防ぐために実施
• エスケープ処理とも呼ばれる

サブスクリプション

• 月額料金でサービスを受けられる課金モデル
• Amazon Primeのようなイメージ
• 継続的な収益が見込めるビジネスモデルとして普及

仕様書

• システムやソフトウェアの機能、動作、要件を詳細に記述した文書
• 設計書、要件定義書などがこれに含まれる
• テスト設計の基礎となる重要なドキュメント

シナリオテスト

• 実際のユーザーの利用シナリオに沿ってテストを実行する手法
• 単機能テストでは発見できない、複数機能を跨いだバグを見つけられる
• ユーザー視点でのテストが可能

システムテスト

• 開発したシステムが期待通りに動作するか、構築したシステムが仕様通りの機能や性能要件を満たしているか確認するテスト
• 総合テストと同意

スクラム

• アジャイルソフトウェア開発におけるプロジェクト管理のための反復型でインクリメンタル型のフレームワーク（枠組み）
• スプリントと呼ばれる短い開発サイクルを繰り返す
• デイリースクラム、スプリントレビュー、レトロスペクティブなどの儀式がある

スプリント

• スクラム開発における1〜4週間程度の開発サイクル
• スプリント内で計画、開発、テスト、レビューを完結させる
• 各スプリント終了時に動作する成果物を生み出すことが目標

スモークテスト

• システムの主要機能が動作するかを確認する簡易的なテスト
• ビルド後やデプロイ後に最初に実行される
• 詳細なテストを実施する価値があるかを判断する

正常系テスト

• 正しい操作や入力で、期待通りの結果が得られることを確認するテスト
• ハッピーパステストとも呼ばれる
• 異常系テストと対になる概念

セッション

• 通信の開始から終了までを指す
• ネットワークに接続中のユーザがWebサイトを訪れ、サイト内で動作する一連の流れを1つの単位とする
• Webサイトにアクセスして、そのサイトから出て行くかブラウザを閉じるまでが1セッション

セキュリティテスト

• システムの脆弱性を発見し、セキュリティ要件を満たしているかを確認するテスト
• 不正アクセス、データ漏洩、権限昇格などを検証
• ペネトレーションテストや脆弱性診断が含まれる

総合テスト

• 開発したシステムが期待通りに動作するか、構築したシステムが仕様通りの機能や性能要件を満たしているか確認するテスト
• システムテストと同意

ソフトウェア

• コンピュータを動かすプログラムのこと

ソフトウェアテスト

• コンピュータを動かすプログラムの不具合をチェックすること

同値分割

• 入力値の範囲を同じ結果になるグループに分けてテストする技法
• 各グループから代表値を選んでテストすることで効率化
• 境界値分析と組み合わせて使用される

タ行

単体テスト

• プログラムを構成する比較的小さな単位（ユニット）が個々の機能を正しく果たしているかどうかを確認するテスト
• 通常、関数やメソッドが単体テストの単位（ユニット）となる
• コード作成時などの早い段階で開発者によって実施されることが多い

チケット

• 課題や作業を管理するための単位
• Jira、Redmine、Backlogなどのチケット管理システムで管理される
• バグ、タスク、改善要望などがチケットとして登録される

デグレーション（デグレ）

• 退化や悪化という意味で、システムやプログラムの不具合を修正した時、ほかに新たな不具合やバグが発生してしまう状態のこと
• 修正によって以前は動いていた機能が動かなくなること
• 回帰テストで検出する

デッドロック

• 複数のプロセスやスレッドがお互いのリソースを待ち続けて処理が進まなくなる状態
• データベース処理などで発生しやすい
• 適切な排他制御で防ぐ必要がある

テストケース

• テストを実行するための具体的な手順と期待結果をまとめたもの
• 前提条件、入力値、操作手順、期待結果などで構成される
• テスト実行の基本単位

テストスイート

• 複数のテストケースをまとめたもの
• 関連するテストをグループ化して管理する
• 自動テストで特定のテストスイートを実行する際に使用

テストデータ

• テスト実行時に使用するデータ
• 正常値、異常値、境界値などを含む
• テスト環境に適したダミーデータを用意する

テストハーネス

• テスト実行を支援するツールやコードの総称
• ドライバ（上位モジュールの代替）やスタブ（下位モジュールの代替）が含まれる
• 単体テストや結合テストで使用される

デプロイ

• 開発した機能やサービスを利用可能にする作業
• 開発環境から検証環境へアップロードしてテストに使用できる状態にすること
• ソフトウェアをインストールする作業

トリアージ

• バグや課題の優先順位を決定するプロセス
• 重要度と緊急度を基に対応順序を決める
• リソースの効率的な配分に必要

ドキュメントテスト

• 仕様書、設計書、マニュアルなどのドキュメント自体の品質を確認するテスト
• 記述の正確性、完全性、一貫性を検証
• レビューを通じて実施されることが多い

ナ行

ネガティブテスト

• 異常系や例外処理が適切に動作するかを確認するテスト
• エラーメッセージの表示、システムのクラッシュ防止などを検証
• 異常系テストと同意

ハ行

バージョン管理

• ソースコードやドキュメントの変更履歴を記録・管理すること
• Git、SVNなどのバージョン管理システムを使用
• チーム開発において必須の仕組み

バグ

• プログラムやシステムの欠陥や不具合
• 期待した動作をしない、エラーが発生するなどの状態
• 重要度と優先度に応じて修正される

バグトラッキング

• バグの発見から修正、検証までを追跡・管理すること
• Jiraなどのバグトラッキングツールを使用
• バグの状態、担当者、修正予定などを記録

バッチ処理

• 一定量の（あるいは一定期間の）データを集め、一括処理するための処理方法
• バッチ処理の対義語としてリアルタイム処理がある
• 身近な使用例：在庫管理、テストの自動化など

パフォーマンステスト

• システムの性能や効率を測定するテスト
• 応答時間、スループット、リソース使用率などを評価
• 負荷テスト、ストレステストが含まれる

バリデーション

• 入力内容や記述内容が要件を満たしているか、妥当性を確認すること
• 入力フォームなどでよく使用される入力チェック

ビルド

• プログラマーが作成したプログラムの元ネタ（ソースコード）から、実際に動くプログラムを作り出し、利用者に引き渡せる配布可能なパッケージを生成する一連の工程全体

品質

• ユーザーが要求している性質や性能のことで、ユーザーが満足しているかどうかによって品質の良し悪しが決定する
• 仮に、一般的には問題なく動くシステムだったとしても、ユーザーの要求通りでなければ品質が悪いというわけ

品質管理（QC）

• 品質管理という意味であり、英語ではQuality Controlの略語
• リリースするまでの間に品質が一定水準を満たしているかをチェック、管理する
• その水準は企業や顧客によって異なる

品質保証（QA）

• 品質保証という意味であり、英語ではQuality Assuranceの略語
• 世の中にリリースされたシステムやアプリの品質を企画からリリース後に至るまで保証したり、サポートする
• リリース後に至ってもシステムの状況によっては修正を行ったり、顧客の要件を満たすためにサポートする

フィックス（修正）

• バグや不具合を修正すること
• "〜をフィックスする"という使い方をする
• 開発者によって実施される

フェールセーフ

• システムに障害が発生した場合に、安全な状態を維持する設計思想
• 例：エレベーターの故障時に自動停止する
• 安全性を重視するシステムで重要

負荷テスト

• 大量のデータを投入し、高い負荷をかけてソフトウェアが正常に機能しているか確認するテスト
• 想定のユーザー数でも耐えることができることを確認するためのテスト
• 使用されるツール：Apache JMeter、httperf、The Grinderなど

ブラックボックステスト

• 内部構造を考慮せず、入力と出力の関係だけを確認するテスト
• 仕様書を基にテストケースを作成
• テスターに実装の知識が不要

ブロッカー

• 作業を進める上で障害となっている問題や課題
• 解決するまで次の作業に進めない重大な問題
• 迅速な対応が求められる

プロジェクト

• 特定の目標を達成するための一時的な取り組み
• 開始と終了が明確に定義されている
• リソース、スケジュール、予算が設定される

ペアテスト

• 2人のテスターが協力してテストを実施する手法
• 1人が操作し、もう1人が観察・記録する
• 知識共有や視点の多様化に効果的

ホワイトボックステスト

• プログラムの内部構造やロジックを理解した上で実施するテスト
• コードカバレッジを測定できる
• 開発者によって実施されることが多い

本番環境

• エンドユーザーが利用する環境
• システムが製品として実際に稼働している環境
• production/prod環境とも呼ばれる

マ行

マイルストーン

• プロジェクトの重要な節目や到達点
• 中間目標やリリース予定日などが設定される
• 進捗管理の指標となる

マージ

• 複数のコードやブランチを統合すること
• バージョン管理システムで使用される操作
• コンフリクト（競合）が発生する場合がある

マニュアルテスト

• 人間が手動でテストを実行すること
• 自動テストと対比される
• 探索的テストやユーザビリティテストで有効

モーダル

• 子ウィンドウのこと
• 閉じるまで親ウィンドウの操作ができない

モジュール

• プログラムを構成する部品や機能の単位
• 独立して開発・テストできるように設計される
• 再利用性や保守性を高める

モックオブジェクト

• テスト用に作成された模擬オブジェクト
• 外部システムやデータベースへの依存を排除できる
• 単体テストで使用される

ヤ行

ユーザビリティテスト

• システムの使いやすさを評価するテスト
• 実際のユーザーに操作してもらい、問題点を発見する
• UIデザインの改善に活用される

ユニットテスト

• プログラムを構成する比較的小さな単位（ユニット）が個々の機能を正しく果たしているかどうかを確認するテスト
• 通常、関数やメソッドが単体テストの単位（ユニット）となる
• コード作成時などの早い段階で開発者によって実施されることが多い
• 単体テストと同意

ユースケース

• システムの機能をユーザーの視点から記述したもの
• アクター（利用者）とシステムの相互作用を表現
• 要件定義やテスト設計の基礎となる

ラ行

リファクタリング

• 外部から見た動作を変えずに、コードの内部構造を改善すること
• 可読性、保守性の向上が目的
• テストで動作を保証しながら実施する

リグレッションテスト

• 回帰テスト、退行テストなどとも呼ばれ、プログラムの一部を修正した時に、その影響でほかに不具合が出ていないかをチェックするために行う
• デグレーションが起こっていないかどうかを検証するために実施するテスト

リスクベースドテスト

• リスクの高い部分を優先的にテストする手法
• リソースを効率的に配分できる
• リスク分析が重要

リリース

• システムやアプリケーションを本番環境に公開すること
• エンドユーザーが使用できる状態にする
• リリース判定会議を経て実施される

ルートコーズ

• 問題の根本原因
• 表面的な原因ではなく、真の原因を特定すること
• 再発防止のために重要

レビューア

• レビューを行う人
• 仕様書などのドキュメントを間違いがないかチェックする人
• テスト観点の観点漏れがないかチェックする人
• テストケースに漏れがないかチェックする人

レビューイ

• レビューをされる側の人
• レビューアとは逆の人
• レビューの対象となる成果物の作成者

ログ

• システムやアプリケーションの動作記録
• エラー調査やパフォーマンス分析に使用
• アクセスログ、エラーログ、デバッグログなどがある

A-Z

API（Application Programming Interface）

• アプリケーションやソフトウェアとプログラムをつなぐもの
• ソフトウェアの機能を共有できる仕組み
• RESTful APIやGraphQL APIなどがある

CI/CD（Continuous Integration/Continuous Delivery）

• 継続的インテグレーション／継続的デリバリー
• コードの変更を自動的にビルド、テスト、デプロイする仕組み
• Jenkins、GitHub Actions、CircleCIなどのツールが使用される

Cookie

• ユーザーとサーバー間で特定の情報をやり取りするファイル
• 閲覧中のWebサイトからスマホやパソコンに保存される情報
• 保存されるデータ例：ID、パスワード、メールアドレス、訪問回数など

CSV（Comma-Separated Values）

• カンマ区切りのテキストデータ形式
• Excelなどで開くことができる
• テストデータの作成や結果の記録に使用される

development環境（dev環境）

• 開発中の機能を見てもらう時などに使用する場所
• stagingよりさらにカジュアルな環境で、簡単に作って潰すような使われ方をする
• 開発環境とも呼ばれる

Hotfix（ホットフィックス）

• ソフトウェアに発見された不具合を解消するために配布される修正プログラムのうち、問題に迅速に対応するため緊急に発行されるもの
• クライアントが製品の現在のリリース内で問題を発見し、次の大きなリリースまで修正されるのを待つことができない場合に使用される

JSTQB（Japan Software Testing Qualifications Board）

• 日本におけるソフトウェアテスト技術者資格認定の運営組織
• ISTQBの加盟組織として2005年4月に認定された
• Foundation Level、Advanced Level、Expert Levelなどの資格がある

modal（モーダル）

• 子ウィンドウのこと
• 閉じるまで親ウィンドウの操作ができない

N/A（Not Available）

• 該当なしの意味
• テストケースを用いたテスト実行において、仕様変更などにより該当項目が存在しなくなった場合、該当項目の結果欄に「N/A」と記載、または選択する場合がある

NT（Not Test）

• テストしない／テスト対象外の意味
• テストケースを用いたテスト実行において、該当項目はあるけど開発が途中だったり現在のフェーズでは対応しない場合、項目の結果欄に「NT」と記載する
• 基本的に開発側と同意が取れてから対応する

NG（No Good）

• テスト結果が期待と異なり、不合格であること
• バグが発見された状態
• OKと対になる概念

OK

• テスト結果が期待通りで、合格であること
• 問題がなく正常に動作している状態
• NGと対になる概念

production環境（prod環境）

• エンドユーザーが利用する環境
• システムが製品として実際に稼働している環境
• 本番環境とも呼ばれる

QA（Quality Assurance）

• 品質保証という意味
• 世の中にリリースされたシステムやアプリの品質を企画からリリース後に至るまで保証したり、サポートする
• リリース後に至ってもシステムの状況によっては修正を行ったり、顧客の要件を満たすためにサポートする

QC（Quality Control）

• 品質管理という意味
• リリースするまでの間に品質が一定水準を満たしているかをチェック、管理する
• その水準は企業や顧客によって異なる

SDK（Software Development Kit）

• ソフトウェア開発キットと訳される
• 特定のソフトウェアを開発する際に必要なツールのセット（APIのライブラリ、サンプルプログラム、技術文書などが含まれる）のこと

SLA（Service Level Agreement）

• サービスレベル契約
• サービス提供者と利用者の間で、サービスの品質や範囲を定めた合意
• 稼働率、応答時間などの保証値が記載される

staging環境（stg環境）

• 本番リリース前の動作検証を行う場所
• ほとんど本番に近い環境だが、サーバースペックは落としてあったり、外部API接続がテスト環境につながっていたりなどが異なる
• 検証環境とも呼ばれる

UDID（Unique Device Identifier）

• 端末一台一台に割り振られている重複のない番号
• 案件ではDeployGateからアプリをインストールするためにUDIDを登録してもらう必要がある（iOSのみ）
• 登録されていない場合、DeployGateからアプリをインストールしようとすると「UDID is not included」となりインストールができない（iOSのみ）

UDP（User Datagram Protocol）

• コネクションレス型のプロトコル
• TCPに比べ信頼性がないものの高速に転送を行うことができる
• 主な使用用途は、音声通話、Videoストリーミング、マルチキャスト通信、ブロードキャスト通信、少量のデータ転送など

UI（User Interface）

• ユーザーインターフェース
• ユーザーがシステムと対話するための画面や操作方法
• ボタン、フォーム、メニューなどが含まれる

UX（User Experience）

• ユーザーエクスペリエンス
• ユーザーが製品やサービスを使用する際の総合的な体験
• 使いやすさ、満足度、感情的な反応などを含む

WIP（Work In Progress）

• 作業中、進行中の意味
• 現在対応中のタスクやチケットを指す
• カンバンボードなどで使用される

【中級編〜上級編】より専門的な用語集

ア行

α（アルファ）テスト

• 開発者側の環境で実施される初期段階のテスト
• 主に社内の限定されたユーザーによって実施される
• β（ベータ）テストの前段階

アクセシビリティテスト

• 障害を持つユーザーを含む、すべてのユーザーがシステムを使用できるかを確認するテスト
• WCAG（Web Content Accessibility Guidelines）に準拠しているかを検証
• スクリーンリーダーでの動作確認なども含まれる

アサーションカバレッジ

• テストコード内のアサーション（検証文）がどの程度実行されたかを示す指標
• コードカバレッジとは異なる観点での網羅性を測定
• テストの品質を評価する際に使用

イテレーション

• アジャイル開発における開発サイクルの単位
• スプリントと同義で使われることが多い
• 繰り返し開発を行うことで段階的に製品を完成させる

インクリメンタルテスト

• システムを段階的に統合しながらテストする手法
• トップダウンアプローチやボトムアップアプローチがある
• スタブやドライバを使用して未完成部分を補う

インバリアント

• プログラム実行中に常に真であるべき条件
• オブジェクトの一貫性を保証するために使用
• 不変条件とも呼ばれる

エンピリカルテスト

• 経験に基づいて実施されるテスト
• テスターの知識や直感を活用
• アドホックテストや探索的テストに近い

エラーハンドリング

• エラーや例外が発生した際の処理方法
• 適切なエラーメッセージの表示、ログ記録、リカバリー処理などを含む
• 堅牢なシステムを作るために重要

オラクル問題

• テスト結果が正しいかどうかを判断する基準（オラクル）を定義することの難しさ
• 特に機械学習やAIシステムのテストで顕著
• 複数の視点から検証する必要がある

カ行

カオステスト

• システムに意図的にカオス（混乱）を引き起こして耐性を確認するテスト
• カオスエンジニアリングの一環
• Netflix Chaos Monkeyなどのツールが有名

カバレッジ

• 網羅率
• 全体のどれくらいを網羅できているかのこと
• テストカバレッジ（全テストに対する進捗率）のこと

カナリアリリース

• 新バージョンを一部のユーザーにのみ公開し、問題がないことを確認してから全体に展開する手法
• リスクを最小化できる
• 段階的なロールアウト戦略の一つ

技術的負債

• 短期的な解決策を選択したことで、将来的に追加のコストが発生する状態
• リファクタリングやテストの不足が原因となることが多い
• 計画的に返済していく必要がある

境界値テスト

• 境界値分析に基づいたテスト
• 0、1、最大値、最大値+1などをテストする
• バグが発生しやすいポイントを重点的に検証

キャプチャ/リプレイテスト

• ユーザーの操作を記録（キャプチャ）し、再生（リプレイ）することでテストを自動化する手法
• Seleniumなどのツールで実施可能
• メンテナンスコストが高いというデメリットがある

クラウドテスト

• クラウド環境を利用してテストを実施すること
• 多様なデバイスやブラウザでのテストが容易
• BrowserStack、Sauce Labsなどのサービスがある

グレーボックステスト

• ブラックボックステストとホワイトボックステストの中間的な手法
• 内部構造の一部を知った状態でテストを設計
• より効果的なテストケースを作成できる

クロスサイトスクリプティング（XSS）

• ユーザからの入力内容をWebページに表示するWebアプリケーションにおいて、ウェブサイト（標的サイト）の脆弱性（XSS脆弱性）を利用した攻撃手法
• 身近な例：入力フォームにHTMLタグやJavaScriptタグが入力された場合、その内容をそのまま実行してしまう
• 対策としてエスケープ処理などが行われる

クロスサイトリクエストフォージェリ（CSRF）

• セッションが有効になっている状態で、悪意のある第三者が作成したURLにアクセスすると、意図しない情報を送信してしまう攻撃を指す
• 2005年頃、mixiで日記にあるリンクをクリックすると、自身の日記にも同様の内容を投稿してしまう「はまちちゃん事件」が流行、問題となった
• 対策は、リクエストトークンの整合性を確認したり、HTTPのRefererヘッダで送信元のチェックを行う等

クロスブラウザテスト

• 複数のブラウザ（Chrome、Firefox、Safari、Edgeなど）で動作を確認するテスト
• ブラウザごとの表示や動作の違いを検証
• BrowserStackなどのツールが使用される

ゴールデンマスター

• 正しい動作が保証されたテスト結果のコピー
• 回帰テストで基準として使用される
• スナップショットテストとも関連

コードカバレッジ

• テストによって実行されたコードの割合
• ステートメントカバレッジ、ブランチカバレッジ、パスカバレッジなどがある
• 高いカバレッジが品質を保証するわけではない

コンテキスト駆動テスト

• プロジェクトの文脈（コンテキスト）に応じてテストアプローチを変える考え方
• "ベストプラクティス"は存在せず、状況に応じた判断が必要
• James Bachらが提唱

コンポーネントテスト

• 個別のコンポーネント（部品）を単独でテストする手法
• 単体テストと同義で使われることが多い
• モジュールテストとも呼ばれる

サ行

サイドエフェクト

• 関数やメソッドが、返り値以外に外部の状態を変更すること
• グローバル変数の変更、ファイル書き込みなどが該当
• テストを複雑にする要因となる

サニティテスト

• 主要機能が正常に動作するかを確認する簡易的なテスト
• スモークテストとほぼ同義
• ビルド検証テストとも呼ばれる

シフトレフト

• テスト活動を開発プロセスの早い段階に移行する考え方
• 要件定義や設計段階からQAが関与する
• バグの早期発見によりコスト削減につながる

シフトライト

• 本番環境でのモニタリングやフィードバックを重視する考え方
• シフトレフトの補完的な概念
• カオスエンジニアリングや本番環境でのテストが含まれる

状態遷移テスト

• システムの状態と状態間の遷移を検証するテスト技法
• 状態遷移図や状態遷移表を基にテストケースを作成
• ワークフローやライフサイクルを持つシステムで有効

冗長性テスト

• システムの冗長化機能（バックアップ、フェイルオーバーなど）が正しく動作するかを確認するテスト
• 高可用性を求められるシステムで重要
• 障害発生時の切り替え動作を検証

スパイクテスト

• 短時間に急激な負荷をかけて、システムの挙動を確認するテスト
• 負荷テストの一種
• アクセス集中時の動作を検証

ステートメントカバレッジ

• 命令網羅率
• すべての処理を行うように指定した内の全体に対するテストの進捗率

ストレステスト

• システムの限界を超える負荷をかけて、どのように故障するかを確認するテスト
• システムの破壊点を見つけることが目的
• 負荷テストよりも過酷な条件で実施

スタブ

• テスト対象が依存する下位モジュールの代替品
• 単体テストや結合テストで使用
• ダミーデータを返すなどの最小限の実装を持つ

スナップショットテスト

• 過去の正しい状態を保存し、現在の状態と比較するテスト
• UIコンポーネントのビジュアルリグレッションテストで使用される
• Jestなどのフレームワークでサポートされている

静的解析

• プログラムを実行せずにコードを分析すること
• コーディング規約違反、潜在的なバグ、セキュリティ脆弱性を検出
• SonarQube、ESLintなどのツールが使用される

静的テスト

• プログラムを実行せずに実施するテスト
• レビュー、インスペクション、静的解析が含まれる
• 早期に欠陥を発見できる

セキュリティホール

• システムやソフトウェアのセキュリティ上の脆弱性
• 攻撃者に悪用される可能性がある
• CVE（Common Vulnerabilities and Exposures）で管理される

全数テスト

• すべての組み合わせをテストすること
• 現実的には実行不可能な場合が多い
• ペアワイズ法などで組み合わせを削減する

相互運用性テスト

• 異なるシステムやコンポーネント間の連携が正しく動作するかを確認するテスト
• API連携、データ交換などを検証
• 統合テストの一種

タ行

耐久テスト

• 長時間連続してシステムを稼働させ、メモリリークや性能劣化がないかを確認するテスト
• ソークテスト、エンデュランステストとも呼ばれる
• 数時間から数日間実施される

ダークローンチ

• 新機能を本番環境にデプロイするが、ユーザーには見えない状態にしておく手法
• フィーチャートグルを使用して実現
• 段階的なリリースを可能にする

探索的テスト

• テスト設計とテスト実行を同時に行う手法
• テスターの学習と発見を重視
• タイムボックスを設けて実施することが多い

デシジョンテーブルテスト

• 複数の条件とその組み合わせによる結果を表形式で表現したテスト技法
• 条件の組み合わせを漏れなく網羅できる
• 複雑なビジネスロジックのテストに有効

デシジョンカバレッジ

• テストの対象となるプログラムコードのうち、判定条件（デシジョン）の真/偽を実行した割合
• 100%のデシジョンカバレッジは、100%のブランチカバレッジと100%のステートメントカバレッジの両方を意味する
• 100%のデシジョンカバレッジの達成は、100%のステートメントカバレッジの達成を保証する。逆は保証しない

ディペンデンシーインジェクション

• 依存性注入
• オブジェクトの依存関係を外部から注入する設計パターン
• テスト容易性を高める

ディレクトリトラバーサル攻撃

• ファイル共有画面やWebサイトにて、相対パスを悪用して、本来はアクセスできないディレクトリにアクセスする攻撃方法
• URL欄に../を入れることで、上位ディレクトリにアクセスできるので、それを悪用し、データを壊したり盗んだりする
• 対策は、ロールを正しく設定して対象のディレクトリ以外はアクセスできないようにしたりする、Webサーバの設定を適切にする等

テストオートメーションピラミッド

• 自動テストの理想的な構成を示すモデル
• 底辺に多数の単体テスト、中間に統合テスト、頂点に少数のE2Eテストを配置
• Mike Cohnが提唱

テストオラクル

• テスト結果が正しいかどうかを判断するための基準や仕組み
• 仕様書、既存システム、ユーザーの期待などがオラクルとなる
• オラクルの選定がテストの品質を左右する

テストダブル

• テスト用の代替オブジェクトの総称
• モック、スタブ、フェイク、ダミー、スパイが含まれる
• Gerard Meszarosが体系化

テストデータマネジメント

• テストで使用するデータの計画、作成、管理、削除を行うこと
• 本番データのマスキングや匿名化も含まれる
• GDPRなどの規制への対応も必要

テストハーネス

• テスト実行を支援するツールやコードの総称
• ドライバ（上位モジュールの代替）やスタブ（下位モジュールの代替）が含まれる
• 単体テストや結合テストで使用される

テストファースト

• テストを先に書いてから実装を行う開発手法
• TDD（テスト駆動開発）の基本原則
• 仕様の明確化とテスト容易な設計につながる

テスト優先度

• テストケースの実行順序や重要度
• リスク、ビジネス価値、技術的複雑さなどを考慮して決定
• リソースが限られる場合に重要

ドライバ

• テスト対象が依存する上位モジュールの代替品
• 下位モジュールのテストで使用
• テスト対象を呼び出す役割を持つ

動的解析

• プログラムを実行しながら解析すること
• メモリリーク、パフォーマンスボトルネックなどを検出
• プロファイラやデバッガが使用される

動的テスト

• プログラムを実行して実施するテスト
• 実際の動作を確認できる
• 静的テストと対比される

ナ行

ノンファンクショナルテスト

• 機能以外の品質特性を検証するテスト
• パフォーマンス、セキュリティ、使いやすさ、保守性などを評価
• ISO/IEC 25010の品質モデルが参考になる

ネガティブパステスト

• 異常系や例外処理を確認するテスト
• 不正な入力、エラー条件を意図的に発生させる
• システムの堅牢性を検証

ハ行

ハードニング

• システムのセキュリティを強化すること
• 不要なサービスの停止、パッチ適用、設定の見直しなどを行う
• セキュリティテストの前段階として実施

ハザード分析

• システムに潜む危険要因（ハザード）を特定し、リスクを評価すること
• 安全性が重要なシステムで必須
• HAZOP、FTAなどの手法がある

パスカバレッジ

• プログラムのすべての実行パス（経路）を実行した割合
• 最も厳しいカバレッジ基準
• 複雑なプログラムでは100%達成が困難

バックログ

• 実装予定の機能や修正すべきバグのリスト
• プロダクトバックログとスプリントバックログがある
• 優先順位付けが重要

ハッピーパステスト

• 正常系のテスト
• ユーザーが期待通りに操作した場合の動作を確認
• すべてがうまくいくシナリオ

バリデーションテスト

• システムが顧客の要求を満たしているかを確認するテスト
• 「正しいものを作っているか」を検証
• ベリフィケーションテストと対比される

ピアレビュー

• 同僚同士でレビューを行うこと
• フォーマルなプロセスを持たない場合が多い
• 知識共有や相互学習に効果的

フィーチャートグル

• 機能のオン/オフを切り替えられる仕組み
• ダークローンチやA/Bテストで使用
• フィーチャーフラグとも呼ばれる

フォールトインジェクション

• 意図的に障害を発生させてシステムの挙動を確認するテスト
• エラーハンドリングの正当性を検証
• カオスエンジニアリングの一手法

フェイクオブジェクト

• 実際の動作を模倣するが、本物より単純化されたオブジェクト
• インメモリデータベースなどが例
• テストダブルの一種

ブランチカバレッジ

• 分岐網羅率
• テストの対象となるプログラムコードのうち、条件文の真/偽を実行した割合

ブルーグリーンデプロイメント

• 2つの本番環境（ブルーとグリーン）を用意し、切り替えることでダウンタイムなくリリースする手法
• 問題があれば即座に切り戻せる
• ゼロダウンタイムデプロイメントの一種

プロパティベーステスト

• プログラムが満たすべき性質（プロパティ）を定義し、ランダムな入力で検証する手法
• QuickCheckなどのツールが有名
• 想定外のバグを発見しやすい

ペアワイズ法

• すべての2要素の組み合わせを最低1回はテストする手法
• 全数テストに比べてテストケース数を大幅に削減できる
• 直交表やAll-Pairs法が使用される

ペネトレーションテスト

• 侵入テスト
• 攻撃者の視点からシステムの脆弱性を探すテスト
• ホワイトハット（倫理的ハッカー）によって実施される

ペンディング

• 保留状態のこと
• バグの対応を一時的に見送る場合などに使用
• 理由を明確にして記録する

ベリフィケーションテスト

• システムが仕様通りに作られているかを確認するテスト
• 「正しく作っているか」を検証
• バリデーションテストと対比される

ポストモーテム

• 障害や問題発生後に行う振り返り
• 原因分析、再発防止策の検討を行う
• ブレームレス（責任追及しない）文化が重要

マ行

マインドマップ

• 情報を視覚的に整理する手法
• テスト設計やアイデア出しに活用
• テスト観点の洗い出しに有効

マジックナンバー

• コード内にハードコーディングされた数値
• 可読性や保守性を下げる
• 定数として定義すべき

マニュアルテスティング

• 人間が手動でテストを実行すること
• 自動化が困難な領域で重要
• 探索的テストやユーザビリティテストで活用

ミューテーションテスト

• プログラムに意図的な変更（変異）を加え、テストが失敗するかを確認する手法
• テストの品質を評価できる
• テストコードの欠陥を発見できる

メトリクス

• 測定可能な指標
• バグ検出率、カバレッジ、テスト実行時間などがある
• プロセス改善のための基礎データ

モジュール結合度

• モジュール間の依存関係の強さ
• 結合度が低いほど保守性が高い
• 疎結合を目指す

モックオブジェクト

• テスト用に作成された模擬オブジェクト
• 呼び出しの検証を行う点がスタブと異なる
• テストダブルの一種

ヤ行

ユースケーステスト

• ユースケースを基にテストケースを作成する手法
• ユーザーの実際の使用シナリオを反映
• シナリオテストと似た概念

要件トレーサビリティ

• 要件からテストケースまでの追跡可能性
• どの要件がどのテストでカバーされているかを管理
• 要件の変更影響を把握できる

ラ行

ラウンドトリップエンジニアリング

• モデルとコードを相互に変換・同期する手法
• モデル駆動開発で使用
• 設計とコードの一貫性を保つ

リスクマトリックス

• リスクの発生確率と影響度を2次元で表現したもの
• リスクの優先順位付けに使用
• テスト計画の基礎となる

リリースノート

• リリース内容を記載した文書
• 新機能、修正バグ、既知の問題などを記載
• ユーザーへの情報提供として重要

リファレンス環境

• 標準となる環境
• テスト結果の比較基準として使用
• ゴールデンマスターとも関連

レスポンシブテスト

• 異なる画面サイズやデバイスでの表示を確認するテスト
• スマートフォン、タブレット、PCなどで検証
• ビューポートの変更をテストする

ローカライゼーションテスト

• ソフトウェアが特定の地域や言語に適合しているかを確認するテスト
• 翻訳の正確性、日付形式、通貨表示などを検証
• 多言語対応製品で必須

ロールバック

• システムを以前の状態に戻すこと
• デプロイに問題があった場合に実施
• 迅速なロールバックが障害対応の鍵

ロードバランサー

• 負荷分散装置
• 複数のサーバーにトラフィックを分散
• 高可用性と性能向上を実現

ワ行

ワークフローテスト

• ビジネスプロセスやワークフローが正しく動作するかを確認するテスト
• 承認フロー、ステータス遷移などを検証
• 状態遷移テストと関連

A-Z

A/Bテスト

• 2つのバージョンを比較して効果を測定する手法

再試行

ゆ

続ける

ユーザーをランダムに2グループに分けて異なるバージョンを提供

• コンバージョン率やユーザー行動の改善に活用

API Gateway

• APIへのアクセスを一元管理するサービス
• 認証、レート制限、ルーティングなどを提供
• マイクロサービスアーキテクチャで重要な役割

BDD（Behavior Driven Development）

• 振る舞い駆動開発
• ユーザーの振る舞いに焦点を当てた開発手法
• Given-When-Thenの形式でシナリオを記述
• Cucumber、SpecFlowなどのツールが使用される

CQRS（Command Query Responsibility Segregation）

• コマンドとクエリの責務分離パターン
• データの更新と参照を分離する設計
• 複雑なドメインモデルで有効

CVE（Common Vulnerabilities and Exposures）

• 共通脆弱性識別子
• セキュリティ脆弱性に一意の識別番号を付与
• CVE-2021-44228のような形式

DRY原則（Don't Repeat Yourself）

• 同じコードを繰り返し書かないという原則
• 保守性と再利用性を高める
• テストコードにも適用される

DSL（Domain-Specific Language）

• ドメイン固有言語
• 特定の領域に特化した言語
• テストフレームワークでよく使用される

E2E（End-to-End）テスト

• システム全体を通じたユーザーシナリオを実行し、実際の使用環境に近い状態で動作を確認するテスト
• フロントエンドからバックエンド、データベースまで含めた統合的な検証
• Selenium、Cypress、Playwrightなどのツールが使用される

FMEA（Failure Mode and Effects Analysis）

• 故障モード影響解析
• 潜在的な故障とその影響を系統的に分析
• リスクベースドテストの基礎となる

GraphQL

• APIのクエリ言語
• クライアントが必要なデータを指定できる
• RESTの代替として使用される

HATEOAS（Hypermedia As The Engine Of Application State）

• RESTアーキテクチャの制約の一つ
• レスポンスに次に実行可能なアクションのリンクを含める
• APIの自己文書化を実現

IDE（Integrated Development Environment）

• 統合開発環境
• コーディング、デバッグ、テストを一つの環境で実行
• Visual Studio Code、IntelliJ IDEAなどが代表的

INVEST原則

• 良いユーザーストーリーの特徴を表す頭字語
• Independent（独立）、Negotiable（交渉可能）、Valuable（価値がある）、Estimable（見積もり可能）、Small（小さい）、Testable（テスト可能）
• アジャイル開発で使用される

ISO/IEC 25010

• ソフトウェア品質モデルの国際規格
• 機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性の8つの品質特性を定義
• テスト計画の参考になる

JSON（JavaScript Object Notation）

• データ交換フォーマット
• 軽量で人間が読みやすい
• APIのレスポンス形式として広く使用される

JWT（JSON Web Token）

• JSON形式のトークンベース認証
• ステートレスな認証が可能
• ヘッダー、ペイロード、署名で構成される

KPI（Key Performance Indicator）

• 重要業績評価指標
• テストの進捗やバグ検出率などを測定
• プロジェクトの健全性を評価

MTBF（Mean Time Between Failures）

• 平均故障間隔
• システムの信頼性を示す指標
• 長いほど信頼性が高い

MTTR（Mean Time To Repair/Recovery）

• 平均修復時間／平均復旧時間
• 障害からの復旧にかかる平均時間
• 短いほど可用性が高い

OAuth

• 認可のためのオープン標準プロトコル
• サードパーティアプリケーションへのアクセス権限を付与
• OAuth 2.0が広く使用されている

OWASP（Open Web Application Security Project）

• Webアプリケーションセキュリティのオープンコミュニティ
• OWASP Top 10は最も重要なセキュリティリスクのリスト
• セキュリティテストの指針となる

OSコマンドインジェクション

• Webアプリケーションで、本来実行するコマンドと同時に別のOSコマンドを挿入する攻撃方法
• PHPのexecコマンドやPythonのsystemコマンド等のLinuxコマンドを実行するコマンドを悪用する
• 対策方法は、Linuxコマンドで使用する特殊文字をエスケープ処理する等

PoC（Proof of Concept）

• 概念実証
• アイデアや技術が実現可能かを検証するための試作
• 本格的な開発の前段階として実施

RBAC（Role-Based Access Control）

• ロールベースアクセス制御
• ユーザーの役割に応じてアクセス権限を管理
• セキュリティテストで検証される

RDBMS（Relational Database Management System）

• リレーショナルデータベース管理システム
• テーブル間の関係性でデータを管理
• MySQL、PostgreSQL、Oracle Databaseなどが代表的

REST（Representational State Transfer）

• Webアーキテクチャのスタイル
• HTTPメソッド（GET、POST、PUT、DELETEなど）を使用
• RESTful APIが広く普及

RPA（Robotic Process Automation）

• ロボットによる業務自動化
• 定型的な作業を自動化
• テスト実行の自動化にも応用される

SAML（Security Assertion Markup Language）

• セキュリティ認証情報を交換するためのXMLベースの標準
• シングルサインオン（SSO）で使用される
• エンタープライズアプリケーションで採用されることが多い

SLA違反

• サービスレベル契約で定められた基準を満たさないこと
• 応答時間超過、稼働率未達などが該当
• ペナルティが発生する場合がある

SOAP（Simple Object Access Protocol）

• XMLベースのメッセージングプロトコル
• Web サービスの通信に使用
• RESTに比べて厳密な仕様

SOLID原則

• オブジェクト指向設計の5つの原則
• Single Responsibility（単一責任）、Open/Closed（開放/閉鎖）、Liskov Substitution（リスコフの置換）、Interface Segregation（インターフェース分離）、Dependency Inversion（依存性逆転）
• テスト容易性を高める設計に貢献

SQL（Structured Query Language）

• データベース操作のための言語
• SELECT、INSERT、UPDATE、DELETEなどの命令がある
• テストデータの準備や検証で使用

SQLインジェクション

• 「インジェクション」とは、英語で「注入」を意味し、不正な「SQL」の命令を攻撃対象のウェブサイトに「注入する（インジェクションする）」サイバー攻撃の総称
• 身近な例：ウェブページによくあるログイン画面でIDのフォームに1'or'1'='1';--と入力するとパスワードがコメントアウトされたSQL文になり、パスワードなしでログインできてしまう
• 対策方法には「プレースホルダ」を使いSQL文を組み立てたり、エスケープ処理などを行う

SSO（Single Sign-On）

• シングルサインオン
• 一度の認証で複数のサービスにアクセスできる仕組み
• ユーザビリティとセキュリティの両立

TDD（Test-Driven Development）

• テスト駆動開発
• テストを先に書いてから実装する開発手法
• Red-Green-Refactorのサイクルを繰り返す
• コードの品質とテスト容易性が向上

TCP（Transmission Control Protocol）

• 信頼性の高い通信プロトコル
• コネクション型で順序保証とエラー訂正機能を持つ
• UDPと対比される

TLS/SSL（Transport Layer Security / Secure Sockets Layer）

• 通信の暗号化プロトコル
• HTTPSで使用される
• セキュリティテストで検証される

URL（Uniform Resource Locator）

• インターネット上のリソースの場所を示す
• スキーム、ドメイン、パス、クエリパラメータで構成
• テストケースでURLのバリエーションを検証

UUID（Universally Unique Identifier）

• 一意識別子
• 128ビットの値でほぼ一意性が保証される
• テストデータの生成に使用される

VPN（Virtual Private Network）

• 仮想プライベートネットワーク
• 公衆ネットワーク上で安全な通信を実現
• リモート環境からのテストで使用

WAF（Web Application Firewall）

• Webアプリケーションファイアウォール
• Webアプリケーションへの攻撃を防御
• SQLインジェクション、XSSなどをブロック

WCAG（Web Content Accessibility Guidelines）

• Webコンテンツアクセシビリティガイドライン
• アクセシビリティの国際標準
• レベルA、AA、AAAの3段階がある

WebSocket

• 双方向通信を実現するプロトコル
• リアルタイム性が求められるアプリケーションで使用
• チャット、ゲーム、株価表示などで活用

XML（eXtensible Markup Language）

• 拡張可能なマークアップ言語
• データの構造を記述
• SOAPやSAMLで使用される

XPath

• XML文書内の要素を指定するための言語
• SeleniumなどのテストツールでWebページの要素を特定する際に使用
• CSSセレクタと並んで重要

YAML（YAML Ain't Markup Language）

• 人間が読みやすいデータシリアライゼーション形式
• 設定ファイルやCI/CDパイプラインの定義で使用
• JSON のスーパーセット

Zero-Day脆弱性

• 発見されてから修正パッチが提供されるまでの脆弱性
• 攻撃者に悪用されるリスクが高い
• セキュリティテストで重要な観点

マニアックな専門用語集

ア行

アイソレーションレベル

• データベーストランザクションの分離レベル
• Read Uncommitted、Read Committed、Repeatable Read、Serializableの4段階
• 並行性とデータ整合性のトレードオフ

アクターベーステスト

• システムを利用する様々なアクター（役割）の視点でテストを設計する手法
• 管理者、一般ユーザー、ゲストなど役割ごとにテストケースを作成
• セキュリティテストで特に重要

アノマリー検出

• 正常なパターンから逸脱した異常を検出する手法
• 機械学習を活用することが多い
• セキュリティやパフォーマンスの監視で使用

イディオマティックテスト

• 言語やフレームワークの慣用的な使い方に沿ったテスト
• コミュニティのベストプラクティスに従う
• 可読性と保守性が向上

インメモリデータベース

• データをメモリ上に保持するデータベース
• 高速なアクセスが可能
• テストで使用すると実行速度が向上（H2、SQLiteなど）

エピックテスト

• 大きなユーザーストーリー（エピック）レベルでのテスト
• 複数のスプリントにまたがる機能を検証
• アジャイル開発で使用される概念

カ行

カスケード削除

• 親レコードを削除すると、関連する子レコードも自動的に削除される機能
• データベースの参照整合性に関連
• テストで意図しないデータ削除に注意が必要

キャパシティテスト

• システムが処理できる最大容量を測定するテスト
• 同時接続ユーザー数、トランザクション数などを評価
• 将来の拡張計画の基礎データとなる

クォーラム

• 分散システムで合意形成に必要な最小ノード数
• 過半数以上で決定することが多い
• データの一貫性を保証

契約ベーステスト

• APIの契約（スキーマ）を基にテストを実行する手法
• Pact、Spring Cloud Contractなどのツールが使用される
• マイクロサービスで重要

コンディションカバレッジ

• 条件網羅
• 各条件式の真/偽を個別に実行した割合
• デシジョンカバレッジより細かい粒度

コンフィデンスレベル

• テスト結果に対する信頼度
• 統計的テストで使用される概念
• 95%、99%などの値で表現

サ行

サーキットブレーカー

• 障害の連鎖を防ぐ設計パターン
• 一定回数失敗すると自動的に呼び出しを遮断
• マイクロサービスの耐障害性を高める

サブルーチンカバレッジ

• 関数やメソッドがテストで呼び出された割合
• 最も基本的なカバレッジ指標
• 実際には不十分な場合が多い

シャドーテスト

• 本番環境に影響を与えずに新機能をテストする手法
• 本番トラフィックを複製して新システムに送る
• リスクを最小化してテストできる

冗長化テスト

• システムの冗長構成が正しく機能するかを確認
• アクティブ/スタンバイ、アクティブ/アクティブ構成を検証
• 高可用性システムで必須

スライシング

• プログラムの特定の変数や出力に影響する部分だけを抽出する技法
• 静的スライシングと動的スライシングがある
• デバッグやテストケース削減に使用

セマンティックバージョニング

• バージョン番号の付け方の規約
• Major.Minor.Patch（例：2.3.1）の形式
• 後方互換性の有無を明示

前提条件違反

• テスト実行前の前提条件が満たされていない状態
• 環境構築の失敗、データの不足などが原因
• テストケースの実行がブロックされる

タ行

タイムアウトテスト

• 処理が一定時間内に完了するかを確認するテスト
• 長時間かかる処理のタイムアウト設定を検証
• レスポンス性能の保証に重要

ダックタイピング

• 型ではなく振る舞いで判断するプログラミング手法
• "アヒルのように歩き、アヒルのように鳴くなら、それはアヒルである"
• 動的型付け言語で使用される

データ駆動テスト

• 同じテストロジックを異なるデータセットで繰り返し実行する手法
• テストデータを外部ファイル（CSV、Excelなど）で管理
• パラメータ化テストとも呼ばれる

テストイソレーション

• 各テストが他のテストに影響を与えないようにすること
• テストの独立性を保証
• 並列実行を可能にする

テストスメル

• テストコードの悪い兆候
• 重複、過度な依存、脆弱なテストなどが該当
• リファクタリングが必要

テストピラミッド

• 理想的なテストの配分を示すモデル
• 単体テスト（多）、統合テスト（中）、E2Eテスト（少）
• コストと実行速度のバランスを考慮

テストフィクスチャ

• テスト実行前の準備と実行後の後処理
• SetUp/TearDownメソッドで実装
• テスト環境を一貫した状態にする

デッドコード

• 実行されることのないコード
• カバレッジ分析で検出できる
• 削除すべきコード

デバウンス

• 短時間に連続して発生するイベントを間引く処理
• 検索ボックスの入力などで使用
• パフォーマンス最適化の手法

トークンベース認証

• セッションではなくトークンで認証する方式
• JWTが代表的
• RESTful APIで広く使用

ナ行

ネットワークパーティション

• ネットワーク障害でシステムが分断される状態
• 分散システムで発生
• CAP定理に関連する概念

ハ行

パッチテスト

• 修正パッチが正しく適用され、問題を解決しているかを確認するテスト
• 副作用がないことも検証
• ホットフィックスの検証で実施

バウンダリバリューアナリシス

• 境界値分析の正式名称
• 入力範囲の境界付近でテストを行う技法
• 0、1、最大値、最大値+1などをテスト

ファジング

• ランダムなデータを大量に入力してバグを発見する手法
• セキュリティ脆弱性の発見に有効
• American Fuzzy Lopなどのツールが使用される

フラジャイルテスト

• 脆弱なテスト
• 環境の変化や実装の変更で頻繁に失敗する
• テストスメルの一種

フラグポール

• ビルドが正常に完了するかを確認するための最小限のテスト
• スモークテストよりもさらに簡易
• CI/CDパイプラインの最初のステップ

プリコミットフック

• コミット前に自動実行されるスクリプト
• リンターやテストを実行
• コード品質を保つ

ベースラインテスト

• パフォーマンスの基準値を測定するテスト
• 今後の比較基準となる
• リグレッション検出に使用

ボトムアップテスト

• 下位モジュールから順に統合していくテスト手法
• ドライバを使用
• トップダウンテストと対比

ポリグロットパーシステンス

• 複数の異なるデータストアを使い分けること
• 用途に応じて最適なデータベースを選択
• マイクロサービスで採用される

マ行

マスキング

• 機密データを隠蔽すること
• 本番データをテスト環境で使用する際に実施
• GDPR、個人情報保護法への対応

マルチテナントテスト

• 複数のテナント（組織）が同じシステムを使用する環境でのテスト
• データの分離、権限の隔離を検証
• SaaSアプリケーションで重要

メタモーフィックテスト

• 入力を変換して複数回実行し、結果の関係性を検証する手法
• オラクル問題の解決策の一つ
• 機械学習システムのテストで有用

モンキーテスト

• ランダムかつ無秩序な操作でシステムをテストする手法
• 予期しないバグを発見できる
• 自動化ツールで実施されることが多い

ヤ行

ユビキタス言語

• ドメイン駆動設計で使用される共通言語
• 開発者とビジネス側が同じ用語を使用
• テストケースの記述にも影響

ラ行

ラムダアーキテクチャ

• バッチ処理とストリーム処理を組み合わせたアーキテクチャ
• ビッグデータ処理で使用
• テスト戦略が複雑になる

リトライロジック

• 処理失敗時に自動的に再試行する仕組み
• 一時的な障害への対処
• 指数バックオフと組み合わせることが多い

レイジーロード

• 必要になるまでデータを読み込まない手法
• パフォーマンス最適化に有効
• テストで意図しない遅延が発生する可能性

レースコンディション

• 複数のプロセスやスレッドの実行順序によって結果が変わる状態
• 並行処理のバグの原因
• 再現が困難で検出しにくい

ロギングレベル

• ログの重要度を示すレベル
• TRACE、DEBUG、INFO、WARN、ERROR、FATALなど
• テスト環境ではDEBUGレベルを使用することが多い

A-Z

ACID特性

• データベーストランザクションの4つの特性
• Atomicity（原子性）、Consistency（一貫性）、Isolation（分離性）、Durability（永続性）
• トランザクションテストで検証

BASE特性

• 分散システムの特性
• Basically Available、Soft state、Eventually consistent
• ACIDと対比される概念

CAP定理

• 分散システムにおいて、一貫性（Consistency）、可用性（Availability）、分断耐性（Partition tolerance）の3つすべてを同時に満たすことはできないという定理
• システム設計とテスト戦略に影響
• 2つまでしか選択できない

CORS（Cross-Origin Resource Sharing）

• オリジン間リソース共有
• 異なるオリジンからのリクエストを許可する仕組み
• セキュリティテストで検証が必要

CRUD

• Create（作成）、Read（読み取り）、Update（更新）、Delete（削除）
• データ操作の基本的な4つの機能
• すべてのCRUD操作をテストすることが基本

DAST（Dynamic Application Security Testing）

• 動的アプリケーションセキュリティテスト
• 実行中のアプリケーションを外部から検査
• OWASP ZAP、Burp Suiteなどのツールが使用される

DDD（Domain-Driven Design）

• ドメイン駆動設計
• ビジネスドメインを中心とした設計手法
• テストもドメインの言葉で記述

DTD（Document Type Definition）

• XML文書の構造を定義
• バリデーションテストで使用
• XMLスキーマに置き換えられつつある

ETL（Extract, Transform, Load）

• データの抽出、変換、読み込みプロセス
• データウェアハウスで使用
• ETLパイプラインのテストが必要

gRPC

• Googleが開発した高性能RPCフレームワーク
• Protocol Buffersを使用
• マイクロサービス間通信で使用される

HSTS（HTTP Strict Transport Security）

• HTTPSを強制する仕組み
• セキュリティヘッダーの一つ
• セキュリティテストで確認

idempotent（冪等性）

• 同じ操作を複数回実行しても結果が変わらない性質
• PUT、DELETEは冪等、POSTは非冪等
• APIテストで重要な概念

MCP（Model-Context-Protocol）

• モデル、コンテキスト、プロトコルの分離パターン
• テスト容易性を高める設計
• 依存性注入と関連

NoSQL

• 非リレーショナルデータベースの総称
• MongoDB、Cassandra、Redisなどが代表的
• スキーマレスなのでテスト戦略が異なる

ORM（Object-Relational Mapping）

• オブジェクトとRDBのマッピング
• Hibernate、Entity Frameworkなどのツール
• N+1問題などのパフォーマンス問題に注意

PII（Personally Identifiable Information）

• 個人を特定できる情報
• テストデータで本物のPIIを使用してはいけない
• マスキングや匿名化が必要

SAST（Static Application Security Testing）

• 静的アプリケーションセキュリティテスト
• ソースコードを解析して脆弱性を検出
• SonarQube、Checkmarxなどのツールが使用される

SUT（System Under Test）

• テスト対象システム
• テストドキュメントで頻繁に使用される用語
• DUT（Device Under Test）とも呼ばれる

TTL（Time To Live）

• データの生存時間
• キャッシュやDNSレコードで使用
• 期限切れのデータが適切に削除されるかをテスト

WebDriver

• ブラウザを自動操作するためのAPI
• Seleniumの中核技術
• W3C標準として仕様が定義されている

こういった疑問に答えます。

【初級編】ソフトウェアテスト業界の用語まとめ

初級編では、対象者を以下に絞って用語をまとめました。

以下に当てはまる方は是非用語を覚えていただけたら幸いです。

用語を覚えることで、転職後もスムーズに業務に入っていくことができ、評価者から良い評価をされることは間違いありません。

ソフトウェアテスト業界未経験者にもわかりやすく解説します。

【初級編】ソフトウェアテスト業界の用語まとめ ア行

アジャイル開発

インテグレーションテスト

ウォークスルー

レビュー手法の一つで、レビューイが成果物の内容をレビューアに説明すること。

主な目的

欠陥の発見、ソフトウェアプロダクトの改善、異なる実装方法の検討、標準や仕様へ の準拠の評価

その他の目的

受け入れ基準

ユーザー、顧客、その他の認可団体が、コンポーネントやシステムを受け入れる場合、満たさねばならない基準

受け入れテスト

エンドユーザー

【初級編】ソフトウェアテスト業界の用語まとめ カ行

開発環境

キャッシュ

結合テスト

検証環境

【初級編】ソフトウェアテスト業界の用語まとめ サ行

サブスクリプション

システムテスト

スクラム

セッション

総合テスト

ソフトウェア

ソフトウェアテスト

【初級編】ソフトウェアテスト業界の用語まとめ タ行

単体テスト

デグレーション

デプロイ

結合テスト

【初級編】ソフトウェアテスト業界の用語まとめ ハ行

バッチ処理

バリデーション

ビルド

品質

品質管理

品質保証

負荷テスト

本番環境

【初級編】ソフトウェアテスト業界の用語まとめ マ行

モーダル

【初級編】ソフトウェアテスト業界の用語まとめ ヤ行

ユニットテスト

【初級編】ソフトウェアテスト業界の用語まとめ ラ行

リグレッションテスト

レビューア

レビューイ

【初級編】ソフトウェアテスト業界の用語まとめ A-Z

API

Cookie

develpment環境

Hotfix

JSTQB

modal

N/A

NT

production環境

QA

QC

SDK

staging環境

UDID

UDP

【中級-上級編】ソフトウェアテスト業界の用語まとめ

以下の用語に関しては、用語そのものや用語の意味が難しく、初めは理解できない部分も多々あると思います。

ですが、ライバルに差をつけるためにもしっかりと覚えておくことが大切です。

誰でも理解できるようなことはライバルも理解出来ていることがほとんどですが、誰もが理解しにくいようなものはライバルも理解していないことが多いです。

ですので、そのライバルと差をつけるためにも、しっかりと学習を進めてください。

【中級-上級編】ソフトウェアテスト業界の用語まとめ カ行

カバレッジ

クロスサイトスクリプティング

クロスサイトリクエストフォージェリ

【中級-上級編】ソフトウェアテスト業界の用語まとめ サ行

ステートメントカバレッジ

【中級-上級編】ソフトウェアテスト業界の用語まとめ タ行

ディレクトリトラバーサル攻撃

デシジョンカバレッジ

【中級-上級編】ソフトウェアテスト業界の用語まとめ ハ行

ブランチカバレッジ

【中級-上級編】ソフトウェアテスト業界の用語まとめ A-Z

OSコマンドインジェクション

SQLインジェクション

【失敗しない方法】転職する前にソフトウェアテスト用語を覚えるべき理由

転職する前にソフトウェアテスト業界の用語を覚えるべき理由としては以下の3点です。

経験者なら出来るのはわかるのですが、未経験者入社で業界のことを熟していれば先輩や上司たちの間で以下のような会話がなされます。

うさ子A

未経験者入社って聞いてたけどいったい何者？

ゆい

これなら中級者と言っても通じるね。

テス子B

そこまでできるならチームリーダーとしてチームをまとめてもらおう！

ゆい

何でも仕事熟してくれてほんと助かる。次の昇給候補にしよう！給料上げよう！

そして、管理職および評価者に一目置かれるようになり、次の昇給候補になる場合がほとんどです。

ですので、最短でのキャリアアップのため、必要最低限の準備をしておくことはとても大切なのです。

ソフトウェア業界で主に使用する用語について覚えておきましょう。

【未経験者】キャリアアップで転職エージェントを活用する方法

転職エージェントとコミュニケーションを取る際、キャリアアップを見越したコミュニケーションを取る必要があるということです。

多くの方は転職活動のゴールを転職においています。

そのため、転職した後のギャップに苦しめられることが多々あります。

その失敗を最小限に抑えるためにも、転職活動時点で将来のキャリアアップを見越した形で転職エージェントとコミュニケーションを取っておくことが必要です。

具体的には以下の事柄をコミュニケーションの中に盛り込めば問題ないです。

もちろん上記の全てが転職エージェントの方でわかるわけではありません。

ただ、相談をしないと話になりません。

相談はいくらしても問題ありませんので、これらのことも踏まえて相談するべきということです。

もし転職エージェントには不明なところがあったとしても、調べてもらえることがほとんどになります。

ですから、将来の自らのキャリアアップのためにもと転職エージェントとコミュニケーション取り、しっかりと準備しておくことが大切です。

また、そのオススメの転職エージェントについては、以下の記事で詳しく書いていますので、こちらからご覧ください。

ソフトウェアテスト未経験者が抑えておくべきポイント3選

ソフトウェアテスト未経験者がはじめに抑えておくべきポイントとして以下の3点が挙げられます。

転職してロケットスタートできるかどうかは、転職前に事前準備をしているかしていないかによって変わってきます。

転職した直後にロケットスタートをするためには、上記の3点を全ておこなうことで可能となるのです。

詳しくは以下の記事でまとめていますので、こちらをご覧ください。

【保存版】ソフトウェアテスト現役管理職が教える失敗しない面接対策（ポイント3選） 迷える転職者 テスター未経験からでも採用されることってあるのかなぁ。 迷える転職者 採用される確率を上げるために知ってお…