QA・バグ用語辞典｜テスト現場の用語の意味・使いどころ一覧【無料】

テストの基本

テストの種類と土台になる言葉

テストケースてすとけーす基本

「どの条件で・何をして・どうなれば正解か」を1件ずつ書き出したもの。前提条件・操作手順・期待結果で構成する。

テスト観点てすとかんてん基本

「何を確認すべきか」の切り口。境界値・権限・異常系など。観点が漏れるとケースも漏れる。

→ TESTパターン集に観点を多数収録

単体テストたんたいてすと / UT基本

関数や画面部品など、最小単位が単体で正しく動くかを確認するテスト。Unit Test。

結合テストけつごうてすと / IT基本

複数の部品・画面・APIをつないだときに正しく連携するかを確認するテスト。Integration Test。

システムテストしすてむてすと基本

実際の利用に近い状態で、システム全体が要件を満たすかを通しで確認するテスト。

受入テストうけいれてすと / UAT基本

発注者・利用者の立場で「納品物が要件どおりか」を確認する最終テスト。

回帰テストかいきてすと基本

修正・追加によって既存の機能が壊れていないかを確認するテスト。リグレッションテストとも。

スモークテストすもーくてすと基本

主要機能がとりあえず動くかをざっと確認する最小限のテスト。詳細テストに入る前のゲート。

探索的テストたんさくてきてすと基本

事前のケースに縛られず、操作しながら気づいた点をその場で掘り下げるテスト。

ブラックボックステストblack box基本

内部構造を見ず、入力と出力だけに注目するテスト。「仕様どおり動くか」を外側から確認する。

ホワイトボックステストwhite box基本

コードの中身（分岐・経路）を見ながら、論理が正しく通るかを確認するテスト。

性能・負荷テストせいのう / ロードテスト基本

大量アクセス・大量データを与え、速度や安定性が保てるかを確認するテスト。限界を探るのはストレステスト。

ユーザビリティテストusability基本

実際のユーザーに使ってもらい、迷わず操作できるか・分かりにくい所がないかを確認するテスト。

モンキーテストmonkey test基本

無秩序に操作してアプリを壊そうとするテスト。連打・乱暴な入力で想定外の落ち方を探す。

同値分割どうちぶんかつ / EP技法

入力値を「同じ扱いを受けるグループ」に分け、各グループから1件だけテストする手法。Equivalence Partitioning。

境界値分析きょうかいちぶんせき / BVA技法

入力範囲の境目（最小値・最大値・その前後）を重点的に確認する手法。バグが集中しやすい場所。

デシジョンテーブル決定表技法

条件の組み合わせと結果を表にまとめてケースを洗い出す手法。条件が複数絡む機能に向く。

ペアワイズpairwise / 直交表技法

全組み合わせを試さず、任意の2因子の組み合わせを網羅するようにケースを絞る手法。

シナリオテストしなりおてすと基本

「ユーザーがAしてBしてCする」という実際の利用シーンを通しで確認するテスト。導線の抜けを見つけやすい。

異常系テストいじょうけい基本

エラー・例外・不正入力など、正常ではないケースを確認するテスト。正常系だけでは足りない。

境界系テストきょうかいけい基本

文字数上限・数値の最大最小など、限界値付近の動作を確認するテスト。オフバイワンバグを見つける。

リスクベーステストrisk-based testing基本

リスクの高い箇所から優先的にテストを実施する考え方。時間が限られる現場で特に有効。

静的テストせいてきてすと基本

コードや仕様書を実行せずにレビュー・検査するテスト。コードレビューや仕様書レビューがこれにあたる。

動的テストどうてきてすと基本

実際にプログラムを動かして確認するテスト。手動実行・自動テスト双方が含まれる。

アルファテストalpha test基本

開発チームや社内ユーザーが行う公開前テスト。実際のユーザーに見せる前の最後の社内確認。

ベータテストbeta test基本

一般ユーザーの一部を対象に公開前に行うテスト。実環境・実ユーザーの反応を本番前に得る。

テスト駆動開発TDD基本

コードを書く前にテストを先に書き、そのテストを通すようにコードを実装するサイクル。

サニティチェックsanity check基本

修正後に「その修正が意図どおり効いているか」だけを素早く確認する最小限のテスト。スモークテストより狭い。

バグ・起票まわり

不具合を見つけて伝えるための言葉

バグばぐ / 欠陥バグ

仕様や期待する動作と異なる不具合。defect とも呼ぶ。

デグレ / リグレッションでぐれバグ

今まで動いていた機能が、修正の影響で動かなくなること。「デグレった」と言う。

再現手順さいげんてじゅんバグ

バグを再現させるための操作の順番。これが曖昧だと「再現しません」で突き返される。

→ これってバグなの？で起票内容を自動生成

期待結果 / 実際の結果きたいけっかバグ

「本来こうなるべき」と「実際にこうなった」。両方書いて初めてバグとして伝わる。

重要度Severityバグ

バグがシステムに与える影響の大きさ。クラッシュ＝高、軽微な表示崩れ＝低など。

優先度Priorityバグ

どれだけ早く直すべきか。重要度が低くても多発・目立つなら優先度は上がる。重要度と別物。

起票きひょうバグ

バグや課題をチケット（Backlog・Jira など）に登録すること。

→ これってバグなの？で起票内容を自動生成

仕様ですしようですバグ

「不具合ではなく意図した挙動」という回答。安易な「仕様です」は後でトラブルのもとに。

トリアージtriageバグ

溜まったバグを重要度・優先度で仕分けし、「今直す／後で／直さない」を決める作業。

ワークアラウンド回避策バグ

根本修正の前に、ユーザーが問題を避けて使えるようにする暫定の回避手段。

既知の不具合Known Issueバグ

把握済みだが、今回は直さずリリースすると判断したバグ。リリースノートに明記することが多い。

再現率さいげんりつバグ

同じ手順で何回中何回バグが出るか。「10回中2回」のように書くと原因調査の手がかりになる。

ブロッカーblockerバグ

これがあると先のテストが進められない致命的なバグ。最優先で対応される。

横展開よこてんかいバグ

同じバグが他の画面・機能にも潜んでいないか確認すること。1件見つけたら類似箇所を全部チェックする。

根本原因分析RCA / 原因分析バグ

「なぜそのバグが生まれたか」を掘り下げる分析。表面の修正だけで終わらず、再発を防ぐために行う。

一時対応 / 恒久対応いちじ / こうきゅうバグ

「今すぐ被害を止めるための応急処置」と「根本から直す本対応」の区別。両方を管理しないと漏れる。

フォールトfaultバグ

バグの原因となるコード上の欠陥。バグ（外から見た異常）とフォールト（内側の原因）は厳密には別物。

エラー / 障害error / 障害バグ

エラーは人間のミス、フォールトはそのミスがコードに混入した状態、バグは実行時に現れた不具合という整理がある。

バグステータスOpen / Fixed / Closedバグ

バグチケットの状態管理。Open→対応中→Fixed（修正済）→確認待ち→Closedと流れる。チーム内での定義統一が重要。

Critical / High / Medium / Low重要度の分類バグ

バグ重要度の4段階分類。「サービスが止まる」がCritical、「一部機能が使えない」がHigh、「軽微な表示崩れ」がLow。

再テスト / 確認テストリテストバグ

修正後に「そのバグが本当に直ったか」を確認するテスト。リテスト（retest）とも。

環境・リリース

どこで動かす・どう出すかの言葉

本番環境ほんばん / Prod環境

実際のユーザーが使う稼働環境。Production。ここでの不具合は影響が一番大きい。

ステージング環境STG環境

本番とほぼ同じ構成で最終確認するための環境。Staging。リリース前テストの定位置。

開発環境Dev環境

開発者がコードを書いて動かすローカルの環境。本番とは設定・データが異なることが多い。

QA環境QA / Test環境環境

テスト専用に用意された環境。本番相当のデータを置いてテストを回す。STGと分けて管理する現場も多い。

デプロイでぷろいリリース

作ったコードをサーバーに反映して、実際に動く状態にすること。

ロールバック切り戻しリリース

デプロイ後に問題が出たとき、ひとつ前の状態に戻すこと。誰が・どう戻すかを事前に決めておく。

ホットフィックスhotfixリリース

本番で起きた緊急の不具合を、通常リリースを待たずに即修正すること。

フィーチャーフラグfeature flagリリース

機能をコードに入れつつ、スイッチでオン/オフ切り替えできる仕組み。段階公開や緊急停止に使う。

CI / CDしーあい / しーでぃーリリース

コードの変更を自動でテスト（CI）し、自動でリリース（CD）する仕組み。手作業の事故を減らす。

カナリアリリースcanaryリリース

まず一部のユーザーだけに新版を出し、問題なければ全体へ広げる段階的な公開方法。

ブルーグリーンデプロイblue-greenリリース

本番と同じ環境を2つ用意し、切り替えでリリースする方式。問題時は瞬時に元へ戻せる。

マイグレーションmigrationリリース

データベースの構造やデータを新しい形に移行する作業。順番・後戻りの可否を要確認。

フィーチャーブランチfeature branch開発

機能ごとに分けて開発するGitブランチ。mainブランチを汚さず、レビュー後にマージする。

プルリクエストPR / Pull Request開発

ブランチの変更をmainに取り込む前にレビューを依頼する仕組み。差分とコメントでレビューできる。

リリースノートrelease notesリリース

リリース内容・修正バグ・既知の不具合などをまとめた文書。ユーザーや運用チームへの連絡に使う。

リリース判定Go / No-Goリリース

テスト結果をもとに「リリースしてよいか」を判断するミーティングまたは意思決定。GoかNo-Goを明確にする。

ABテストA/B testリリース

2つのバージョンを同時に一部ユーザーに出し、効果を比較する手法。UIの改善効果を数字で測れる。

インシデントincidentリリース

本番でサービスに影響が出る問題が発生している状態。対応完了後に原因分析（ポストモーテム）を行う。

品質・進め方

品質をどう測る・どう残すか

QAQuality Assurance品質

品質保証。テストだけでなく、プロセス全体で品質を作り込む活動全般を指す。

QCQuality Control品質

品質管理。成果物を検査して不良を見つける活動。QAの中の一部にあたる。

テストカバレッジcoverage品質

テストが対象のどれだけを網羅できているかの割合。高ければ安心とは限らない点に注意。

エビデンスえびでんす品質

テストを実施した証拠。スクリーンショット・ログ・実行結果など。

トレーサビリティtraceability品質

要件 → テストケース → 結果が辿れる状態。どの要件をどのテストで確認したか追跡できる。

テスト計画テストけいかく品質

何を・どこまで・どの環境で・誰がテストするかをまとめた計画。テストの地図にあたる。

DoD（完了の定義）Definition of Done品質

「この作業はどうなったら完了か」をチームで決めた基準。テスト済み・レビュー済みなどを含む。

品質ゲートQuality Gate品質

次の工程へ進む前に満たすべき品質の関門。「重大バグ0件ならリリース可」など。

バグ密度ばぐみつど品質

規模あたりのバグ件数。多すぎる箇所は設計の見直し、少なすぎる箇所はテスト不足を疑う材料に。

V字モデルV-model進め方

開発工程とテスト工程を対応させたモデル。要件定義→基本設計→詳細設計がUT→IT→STと対応する。

アジャイルAgile進め方

短いサイクル（スプリント）で開発とテストを繰り返す進め方。変化に素早く対応できる。

スプリントsprint進め方

アジャイル開発での1〜2週間の開発サイクル。スプリントの終わりに動くものをデモする。

レビューreview進め方

コードや設計・テストケースを他者が確認する作業。実行前に問題を見つけられる静的テストの一形態。

テスト報告書テストほうこくしょ品質

テスト結果・実施件数・バグ数・カバレッジなどをまとめた報告文書。リリース判定の根拠になる。

バグ改修率修正完了率品質

検出バグのうち修正済みのものの割合。リリース判定時に「未修正バグが何件残っているか」を見る指標。

テスト設計テストせっけい進め方

「何を・どう確認するか」をケースに落とし込む作業。観点→条件→手順→期待結果の順に整理する。

→ 仕様書なしテスト設計パック

シフトレフトshift left進め方

テストを開発の早い段階から実施する考え方。後工程での手戻りを減らし、修正コストを下げる。

テストオラクルtest oracle品質

「正しい動作はこれだ」という判断基準の出どころ。仕様書・プロトタイプ・旧バージョンなどがオラクルになる。