本サイトで使用する用語の定義をまとめます。
これらの単語は必ずしも「標準」となっている言葉ではなく、筆者の経験からよく使われる言葉たちを定義しています。
実際に現場で使われる言葉多く、使いやすい単語集を目指します。
はじめに
本サイトでは「ソフトウェア業界」を主とした情報を発信しています。
業界によっては言葉の意味が変わってくる部分もあると思いますが、
ご了承の上ご覧いただければと思います。
QA職の種類
QA(Quality Assurance)エンジニア
品質保証/測定を目的とした、各種活動を行うエンジニア・職種のこと。
品質保証するためのWhat・Why・Howを考え、推進する。
手段としてテストを用いることが多く、テストエンジニアを兼ねて作業する場合も多い。
テストエンジニア
テスト活動全般を行うエンジニア・職種のこと。
テスト計画、テスト設計、テスト実施、テスト終了作業を主に担当する。
また、そのテスト活動の推進を行う。
テスター
テスト活動におけるテスト実施を主に人・職種のこと。
テストケースの消化、不具合起票、テストケースを用いないテスト実施を行う。
※探索的テスト/アドホックテスト/モンキーテスト参考
テスト用語
テスト活動
テスト業務における、テスト計画 / テスト設計 / テスト実施 / テスト終了作業までの一連の作業のこと。
システムテストレベルで用いることが多い。
テスト計画
テストの目的や、テストの対象、スケジュールなど、テスト活動を推進するために必要な情報をまとめる作業のこと。
まとめたドキュメントをテスト計画書と呼ぶ。
テスト設計
テスト計画書を元にどのような観点でテストを行うべきか、テスト観点を洗い出す作業のこと。
テスト設計技法を用いたり、過去の経験からテストするべき対象を考えたり、どのようにテストをするのかを考える。
アウトプットとしては、箇条書きで書いたドキュメントや、Excelやスプレッドシートなどでまとめたもの、他にもマインドマップで整理することも多い。
テスト実装
テスト設計で洗い出した観点を元に、「テスト実施」で使う「テストケース(テスト項目書)」の作成を行うこと。
実際の業務の中では設計と実装を合わせてやることが多いため、テスト実装とわざわざ呼ばずに、テスト観点を考えて、テストケースを作成するところまでを「テスト設計」として呼ぶことも多い。
テスト実施
品質担保の活動で最も行われている手法。
会社によっては検証、試験とも呼ぶ。
テスト「実施」まで言わず、「テスト」と呼ぶことも多い。
基本的にはテスト設計で作成された「テストケース」を用いて、手順通りに操作をして期待値通りになっているかを確認する。
テスト終了作業
一連のテスト活動が終了した後に行う作業全般のこと。
サービスや会社によって様々な取り組みがあるが、主にテスト活動の振り返りを行い今後のテスト活動に活かすものを整理したり、発生したバグを分析したりする。
テスト計画書
テスト計画のフェーズで作成されるアウトプット。
テストの目的や、テストの対象、スケジュールなど、テスト活動を推進するために必要な情報がまとまっている。
PowerPointなどのスライドで作成されることや、Wordなどのドキュメンテーションソフトで作成されることが多い。
テストケース
テスト実施する際に使用するドキュメント。
入力値/前提条件/期待結果などが記述されており、テスト結果を入力していくドキュメント。
専用ツールを用いて作成することもあるが、Excelやスプレッドシートが使われることも多い。
正式には「テスト仕様書」という言葉の方が正しく、テストケースというとテスト仕様書の1つの項目を指すことも多い。
別名：テスト項目書、テスト仕様書
機能テスト
システムテストレベルで行われることが多いテスト。
要件仕様や機能仕様、つまり仕様書通りにサービスが動いているかを確認するテスト。
モンキーテスト
使用方法を考慮せず、ランダムに操作を行うテスト。
「アドホックテスト」と非常に似ており、現場レベルでは同義として使われている所も多い。
使い分けについて強いていうならば、正常な使い方を考慮せずに、何も考えずランダムにボタンを押したり、連打したりするテストがモンキーテストと呼ばれる。
そのため、アプリケーションのクラッシュやエラーの発生がないかなどを確認することが多い。
アドホックテスト
テスト準備をせず、テスト結果も予測しないで行うテスト。
モンキーテストと非常に似ており、現場によってどちらかの言葉で使われている。
モンキーテストほぼ同義として扱われるが、アドホックテストではある程度知識や経験のあるテスターがテストケース外でテストを行うことでバグや問題点を発見する目的で使われる。
アドホックテストでもモンキーテスト同様、ランダムな操作を行うシチュエーションもあるが、基本的には正常な使い方を想定して行われることが多い。
探索的テスト
テストケースをあらかじめ決めず、テスト対象のシステムを実際に使いながら、その場でテストケースを作成しテストを進めるテスト技法のこと。
ある種の探索作業と言えることから「探索的テスト」と呼ばれる。
モンキーテスト、アドホックテストと似た文脈で使う方もいるが、探索的テストは設計技法となるため、モンキーテストやアドホックテストといった「テスト手法」は明確に違うものとなる。
探索的テストは、単にテストをするだけでなく、アプリケーションに対する深い理解が重要。
ブラックボックステスト
テスト対象のソフトウェアやシステムの内部構造やコードの詳細を知らずに行うテストのこと。
テスト対象をブラックボックス(黒い箱)に例え、システムの振る舞いを確認する。
自動販売機に例えるとわかりやすく、お金を入れてボタンを押したらジュースがでてくる。
この事象だけを確認するのがブラックボックステストとなる。
投入した100円が100円のポケットに入ること といったジュースが買えるまでに内部で行われていることには関心がない。
ホワイトボックステスト
テスト対象の内部構造や実装を知っている状態で、それを加味して行うテストのこと。
ソースコードを見たり、処理の流れを把握することでテスト設計を行ったり、テスト実施を行う。
テストレベル
ソフトウェアの開発ライフサイクルの中で、テスト範囲を表す概念のこと。
主に「単体テスト」「結合テスト」「システムテスト」「受け入れテスト」の4つのテストレベルが使われる。
それぞれのレベルでどのようなテストを行うか、どのようなアウトプットを作成するかなどテスト活動の基礎にもなる。
ユニットテスト
テストレベルの1つ。
プログラムの最小単位で確認するテストのこと。
単体テストとも呼ばれることも多い。
モジュール(関数やメソッド)を個別でテストをし、モジュールが正しく動くかどうかを検証する。
開発者自身が実装実施をし、CIなどで自動化されていることが一般的。
結合テスト
テストレベルの1つ。
複数のモジュールやコンポーネントを組み合わせて行うテストのこと。
ユニットテストで個別で確認したモジュールやコンポーネントがシステム全体で正しく連携して動作するかを確認する。
システムテスト
テストレベルの1つ。
開発されたシステム・サービスが要件・仕様を満たしているかを確認するテストのこと。
一般的に、テストエンジニア、テスターの方々がメインで作業するフェーズでもある。
要件や仕様に基づいて、システムがユーザーの要求を満たすかどうかを確認する。