Terms related to Advanced Test Automation Engineer 2016

アプリケーションのプログラミングインターフェースを直接使用し、テスト対象のソフトウェアにコマンドを発行して行うテスト。
専用のコマンドラインインターフェースを使用してテスト対象のソフトウェアにコマンドを発行して行うテスト。
GUIを使用してテスト対象のソフトウェアを操作するテスト。
グラフィカルユーザインターフェース(Graphical User Interface)の頭字語。
ある特定のシステムと同じ入力を受け入れ、同じ出力を作り出す装置、コンピュータプログラム、またはシステム。
特定のカバレッジアイテムをテストスイートが遂行した度合。パーセンテージで表す。
階層的な順番で同値分割を示したツリーであり、クラシフィケーションツリー法でテストケースを作成するときに使う。
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
データもしくはプログラムコンポーネントの設計の特性を示す、もしくは設計の説明をした標準の1つ。
テストスイートが、ソフトウェアのどの部分を実行(網羅)し、どの部分が未実行かを判定する分析手法。たとえば、ステートメントカバレッジ、デシジョンカバレッジ、条件カバレッジ。
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
テストで使われる装置、コンピュータプログラム、システムで、ある入力のセットに対し、特定のシステムのような振る舞いや動作をするもの。
特定のコンポーネント(仮にAと呼ぶ)をテストするため、Aに呼び出される(特定目的のための最小限度の)コンポーネント。スタブがないと、実物ができるまで、開発やテストを待たねばならない。スタブは、最終的には、呼び出されるコンポーネントで置き換える。
予測または特定した負荷、若しくはメモリやサーバなどのリソースの可用性が低減したときの限界、または、それを超えた条件でシステムやコンポーネントを評価するために行なわれる性能テストの一種。
定義・計画した全テストケースのサブセット。プログラムの必須機能が正常に動作することを確認するのが目的で、コンポーネントやシステムの主要機能を網羅し、細かな点は無視する。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性(たとえば、信頼性、使用性、設計上の制約など)。
ソフトウェア開発の各段階で実行する活動と、それらの活動が論理的および時系列的にどのように関連しているかを表現したもの。
コンピュータのプログラムやプロシージャのこと。コンピュータシステムの運用に関連したドキュメントやデータも含む場合もある。
(1)テスト組織に対して、テスト組織と他の分野との関連について、ガイダンスと戦略的指針を提供する人。(2)特定のシステム用にテストを構造化する方法を定義する人。テストツールやテストデータのマネジメントなどのトピックも定義する。
テストプロセスを通じて作成される、テストの計画、設計、実行に不可欠なもの。たとえば、ドキュメント、スクリプト、入力、期待結果、セットアップとクリーンアップの処理手順、ファイル、データベース、環境、その他、テストで使用する付加的なソフトウェアやユーティリティなど。
特定のカバレッジアイテムをテストスイートが遂行した度合。パーセンテージで表す。
特定のテスト設計技法を使用している際に、テストベースのサイズが大きくなるにつれて、テストケースの数が過度に増加すること。テストケースの爆発的増加は、テスト設計技法を初めて体系的に適用した際に発生することもある。
一般的にテスト手順仕様を指して用いられる。特に自動化時のスクリプトを指す。
一つ以上のテスト活動を支援するソフトウェア製品。たとえば、計画とコントロール、仕様化、初期ファイルやデータの構築、テスト実行とテスト分析を支援する。
コンポーネントやシステムをコントロールしたり呼び出したりする上位コンポーネントの代わりとなるソフトウェアコンポーネントやテストツール。
テスト実行に必要なスタブやドライバからなるテスト環境。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
カスタマイズしたソフトウェアインターフェース。テスト対象のテスト自動化を可能にする。
テストプロセスのマネジメントとコントロールを支援するツール。テストウェアマネジメント、テストスケジューリング、結果の記録、進捗管理、インシデントマネジメント、テスト報告等の能力を持つことが多い。
テストの活動とリソースのマネジメント、テスト対象の評価に責任を持つ個人。テストプロジェクトを指揮、コントロール、運営し、テスト対象の評価を計画し統制する。
テスト対象のコンポーネントまたはシステムをテストするために使用するテストウェアを規定するモデル。
テスト実行の情報を記録するプロセス。
テスト活動からデータを収集して分析し、その後、データをレポートにまとめてステークホルダに情報を提供する作業。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
汎用テスト自動化アーキテクチャのレイヤーの一つ。テンプレートまたはガイドラインを提供してテストスイートまたはテストケースの定義作業を支援し、テスト実装を行いやすくする。
指定されたテストアイテムに対してテストを実行し、期待結果と事後条件を評価するテストツール。
汎用テスト自動化アーキテクチャのレイヤーの一つ。テストスイートまたはテストケースの実行をサポートする。
テスト対象のコンポーネントやシステムでテストを実行し、実行結果を出力するプロセス。
test objectを参照のこと。
汎用テスト自動化アーキテクチャのレイヤーの一つ。テストスイートまたはテストケースの手動設計または自動設計をサポートする。
テストを設計、実行する理由や目的。
テスト実行の情報を記録するプロセス。
テスト実行後の成果。画面への出力、データの変化、レポート、外部へ送信するメッセージを含む。
汎用テスト自動化アーキテクチャをインスタンス化したもの。テスト自動化ソリューションのアーキテクチャ(レイヤー、コンポーネント、サービス、およびインターフェース)を定義する。
テスト自動化アーキテクチャの設計、実装、および保守を担当する人。作成したテスト自動化ソリューションを技術的に進化させる役割も担う。
テスト自動化アーキテクチャを具現化または実装したもの。特定のテスト自動化要素を実装するコンポーネントの組み合わせで構成される。それらのコンポーネントには、市販のテストツール、テスト自動化フレームワーク、テストハードウェアなどが含まれることがある。
テストを自動化するための環境を提供するツール。通常、テストハーネスとテストライブラリで構成される。
テスト自動化ソリューションの開発と進化を計画および監督する役割を担う人。
特定の境界条件の下で、テスト自動化の長期目標を達成するための高位レベルの計画。
ソフトウェアを使って、テストマネジメント、テスト設計、テスト実行、結果チェックなどのテスト活動の実行や支援をすること。
テスト自動化アーキテクチャのレイヤー。抽象レベルのテストスクリプトをSUTのさまざまなコンポーネント、構成、またはインターフェースに適合させるために必要なコードを提供する。
全てのライフサイクルを通じて実施する静的、動的なプロセスにおいて、成果物が特定の要件を満足するかを判定し、目的に合致することを実証し、欠陥を見つけるため、ソフトウェアプロダクトや関連成果物に対し、計画、準備、評価をすること。
ソフトウェアの故障の原因を見つけて、分析して、取り除くプロセス。
スクリプト作成技法の1つ。テスト入力と期待結果をテーブルやスプレッドシートに格納し、1つの制御スクリプトでテーブル中の全テストを実行するもの。キャプチャ/プレイバックツールのような、テスト実行ツールのアプリケーションで使うことが多い。
2つのエンティティ(たとえば、要件とテストケース)を関係付ける2次元の表。この表を使用すると、エンティティ間の関係を前工程および後工程の双方向に追跡できるので、達成したカバレッジを測定でき、変更点の影響を評価できる。
コンポーネントやシステムをコントロールしたり呼び出したりする上位コンポーネントの代わりとなるソフトウェアコンポーネントやテストツール。
実行結果が期待結果と一致した場合、テストは「合格」とみなす。
コンポーネントやシステムで、開始点から終了点へ至るイベント(たとえば、実行ステートメント)の順列。
欠陥を識別して修正するため、プロダクト開発を担当している同僚がソフトウェア成果物をレビューすること。たとえばインスペクション、テクニカルレビュー、ウォークスルー。
情報システムの機能規模を測定する手法。FPAでの測定は、対象技術に依存しない。生産性測定、必要リソースの見積り、プロジェクトコントロールのベースとして利用できる。
要求仕様ドキュメントで、明示的、暗示的に規定したコンポーネントやシステムの属性(たとえば、信頼性、使用性、設計上の制約など)。
システムが欠陥を検出し、欠陥から復旧できることを確認する目的で、意図的に欠陥をシステムに追加するプロセス。フィールドで発生する可能性のある故障を模倣することを目的とする。
合意に基づく見積り技法の一つ。アジャイルソフトウェア開発で、ユーザストーリーの作業量または相対規模を見積るのに使用される。ワイドバンドデルファイ方法の一つの種類で、チームが見積る単位を表す一組のカードを使用する。
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。
開始日および終了日を持ち、調整され、管理された一連の活動からなり、時間、コストおよび資源の制約を含む特定の要求事項に適合する目標を達成するために実施される特有のプロセス。JSTQB訳注)JIS Q 9000:2006より引用
スクリプト作成技法の一つ。テスト対象ソフトウェアのユースケースを表すシナリオとなるように、スクリプトを構造化する。テストデータを使用してスクリプトをパラメータ化できる。
テスト対象に直接関係するリスク。
測定尺度、および、測定手法。
モデルに基づく、またはモデルを活用するテスト。
適切なスタブやドライバを併用した状態、または独立した状態でコンポーネントをテストできるユニットテストまたはコンポーネントテスト用の環境を提供するツール。デバッグ機能など、開発者を支援するその他の機能もある。
アクターとコンポーネントまたはシステムとの間の対話における一連のトランザクション。視覚できる結果を伴う。アクターは、ユーザまたはシステムと情報交換するあらゆるものになりうる。
リスクのレベルを決定するために、特定のプロジェクトリスクまたはプロダクトリスクを識別し、その後分析するプロセス。一般的に発生確率と影響度を割り当てることによって行なう。
特定のレベルまでリスクを減らす(あるいは、リスクレベルを維持する)ために、判定を下したり、対策したりするプロセス。
特定のレベルまでリスクを減らす(あるいは、リスクレベルを維持する)ために、判定を下したり、対策したりするプロセス。
将来、否定的な結果を生む要素。
ソフトウェア製品の頑健性(堅牢性)を判定するテスト。JSTQB訳注)この「テスト」は実行とそのための一連の活動を意味している。
コンポーネントやシステムの要件、設計、振る舞い、その他の特性を(理想としては完全で的確、かつ検証可能な方法で)詳細に記述したドキュメントであり、記述内容が満足できるものであることを明らかにする手順を示したものも多い。
テスト対象を試験性のために調整した変更度合。
修正のしやすさに関するソフトウェア製品の能力。修正は、是正若しくは向上、または環境の変化、要求仕様の変更および機能仕様の変更にソフトウェアを適応させることを含めてもよい。JSTQB訳注)JIS X 0129-1:2003より引用
リリース後のソフトウェア製品を変更すること。欠陥の修正、性能や他の特性の改善、変更した環境への製品適合などを目的とする。
ソフトウェア製品の信頼性を判定するテスト。JSTQB訳注)この「テスト」は実行とそのための一連の活動を意味している。
修正が成功したかを検証するために、前回不合格に終わったテストケースを再実行するテスト。
コンポーネントやシステムで、開始点から終了点へ至るイベント(たとえば、実行ステートメント)の順列。
テストを手動で実行する工数。
コンポーネント、システム、プロセスが、特定の要件、ユーザ、顧客のニーズ、期待を満たす度合。
変更により、ソフトウェアの未変更部分に欠陥が新たに入り込んだり、発現したりしないことを確認するため、変更実施後、すでにテスト済みのプログラムに対して実行するテスト。ソフトウェアや、実行環境が変わる度に実施する。
実行結果が期待結果と一致しない状態。この場合、テストは「失敗」とみなす。
コンパイル時にオブジェクトコードに翻訳され、プログラムが走るときに手順に沿って実行されて、データに対して動作を行なうステートメント。
テスト対象を試験性のために調整した変更度合。
リソースにアクセスすることを可能にする、人、またはプロセスに付与される権限。
プロジェクトチームのメンバーでプロジェクトを評価し、次のプロジェクトに適用することができる教訓を学ぶために行なうプロジェクト終了時のミーティング。
客観的証拠を提示することによって、規定要求事項が満たされていることを確認すること。JSTQB訳注)JIS Q 9000:2006より引用
スクリプト作成技法の一つ。再使用なスクリプトまたはその一部のライブラリを構築し活用する。
公式であり、場合によっては必須となる要件のセットで、ガイドラインを提供するため、または作業の方法に一貫性のあるアプローチを規定するために、開発、使用するもの。(たとえば、ISO/IEC標準、IEEE標準や団体による標準)
テスト自動化アーキテクチャのレイヤー、コンポーネント、およびインターフェースを表現したもの。構造化されたモジュール形式のアプローチを使用してテスト自動化を実装できる。
修正が成功したかを検証するために、前回不合格に終わったテストケースを再実行するテスト。
ある環境から他の環境に移すためのソフトウェア製品の能力。備考:環境には組織、ハードウェアまたはソフトウェアの環境を含めてもよい。
テストスクリプト内に制御構造を含まない単純なスクリプト技法。
テスト自動化コードのコンポーネントの欠陥密度。
修正したソフトウェアの妥当性確認ができるソフトウェア製品の能力。JSTQB訳注)JIS X 0129-1:2003より引用
ユーザや顧客のサイトにインストールしたハードウェアやソフトウェア製品。この環境で、テスト中のコンポーネントやシステムを動作させる。運用環境のソフトウェアには、オペレーティングシステム、データベースマネジメントシステム、その他のアプリケーションを含むこともある。