JSTQBFL6章 まとめ
JSTQB FL6章を読みました。
シラバスの文章が長いので引用して大事だと思うところ、テス友で出題された部分を太字にしてまとめてみます。
🐰JSTQBFL1章 まとめ
🐱JSTQBFL2章 まとめ
🦊JSTQBFL3章 まとめ
🐶JSTQBFL4章 まとめ
🐧JSTQBFL5章 まとめ
🐷JSTQBFL6章 まとめ
■シラバス内容抽出/解釈
✔ テスト支援ツール
テストツールの考慮事項
テストツールを使用して、1つ以上のテスト活動を支援できる。
以下のようなツールを利用できる。
テストに直接利用できるツール
ex) テスト実行ツールやテストデータ準備ツールなど要件、テストケース、テスト手順、自動化テストスクリプト、テスト結果、テストデータ、欠陥などを上手く取り扱うツール、およびテスト実行のモニタリングとレポートのためのツール
分析と評価に利用できるツール
テストに役立つあらゆるツール（この意味では表計算ソフトウェアもテストツールである）
✔ テストツールの分類
手動で行うと大量のリソースを必要とする反復作業を自動化することによって、テスト活動の効率を改善する（テスト実行、リグレッションテスト）。
テストプロセス全体を通して、手動で行うテスト活動を支援することによって、テスト活動の効率を改善する。
テストの一貫性や欠陥の再現性を高めることで、テスト活動の品質を改善する。
手動では実行できない活動（例えば、大規模な性能テスト）を自動化する。
（例えば、大量のデータの比較を自動化、または動作のシミュレーションをすることにより、） テストの信頼度を向上させる。
！）テストツールの中には、テストの実行結果に影響を及ぼすものがある。
例えば、性能テストツールによ って実行される余分な命令のせいで、アプリケーションの応答時間が実際とは異なってしまうかもしれないし、あるいは、達成したコードカバレッジの量がカバレッジツールを使用したせいで変わってしまうかもしれない。
このようにツールが結果に影響を及ぼすことを、プローブ効果と呼ぶ。
テストツールの中には、一般的に、テスト担当者より開発担当者に効果の高いものもある（例えば、コンポーネントテストやコンポーネント統合テスト時に使用されるツールなど）。
その種のツールは、（D）の印を付けて以下に列挙した。
■ テストとテストウェアのマネジメントの支援ツール
ソフトウェア開発ライフサイクル全体であらゆるテスト活動に適用 できる。
テストマネジメントツールとアプリケーションライフサイクルマネジメントツール（ALM）
要件マネジメントツール（テスト対象へのトレーサビリティなど）
欠陥マネジメントツール
構成管理ツール
継続的インテグレーションツール（D）
■ 静的テストの支援ツール
静的解析ツール（D）
※コードを書いた後のコンパイル（人間が書いたソースコードを機械語(バイナリコード)に翻訳する作業）と同じタイミングで使用することが多いため、テスト担当者向けのツールというよりは開発者向けのツールである
■ テスト設計とテスト実装の支援ツール
テストの設計と実装で保守性の高い作業成果物（例えば、テストケース、テスト手順、テストデータ）を作成できるように支援する。
モデルベースドテストツール
テストデータ準備ツール
※ツールによっては、テストの設計と実装を支援するだけでなく、テスト実行や結果記録を支援したり、 テスト実行や結果記録を支援する他のツールに出力結果を提供したりすることができる。
■ テスト実行と結果記録の支援ツール
テスト実行と結果記録の活動を支援する多くのツールがある。
テスト実行ツール（例えば、リグレッションテストの実行）
カバレッジツール（例えば、要件カバレッジ、コードカバレッジ（D））
テストハーネス（D）
■ 性能計測と動的解析の支援ツール
性能テストとロードテストは手動では効果的に実行できないため、これらのテスト活動では性能計測ツールと動的解析ツールが必須になる。
性能テストツール
動的解析ツール（D）
※ソフトウェアを実行しないと見つけられない欠陥、例えば時間に依存するものやメモリリークのような欠陥を検出するためのツール。単体テストや結合テストレベルで使用するため、テスト担当者よりは開発担当者向けのツールである。
■ 特定のテストに対する支援ツール
全般的なテストプロセスを支援するツールに加えて、非機能特性のために特定のテストの問題を支援す るツールも存在する。
↓
✔ テスト自動化の利点とリスク
テストでツールを使うことは潜在的に利点があり、使うのに適した機会も多いが、リスクもある。
テスト実行を支援するツールを使う潜在的な利点は以下の通りである。
反復する手動作業の削減と時間の節約ができる（例えば、リグレッションテストの実行、環境の準備/復旧タスク、同じテストデータの再入力、コーディング標準準拠のチェックなど）。
一貫性や再実行性が向上する（例えば、整合性のあるテストデータ、同じ頻度と順序でのテスト実行、要件からの一貫したテストケースの抽出など）。
評価の客観性が向上する（例えば、静的な計測、カバレッジなど）。
テストに関する情報へのアクセスの容易性が向上する（例えば、テスト進捗、欠陥率や性能計測結果の集計、およびグラフの作成など）。
テストを支援するツールを使う潜在的なリスクは以下の通りである。
テストツールの効果を過大に期待する（例えば、ツールの機能や使いやすさなど）。
テストツールを初めて導入する場合に要する時間、コスト、工数を過小評価する（例えば、教育や、外部の専門家の支援など）。
大きな効果を継続的に上げるために必要な時間や工数を過小評価する（例えば、テストプロセス の変更、ツールの使用法の継続的な改善など）。
ツールが生成するテスト作業成果物をメンテナンスするために必要な工数を過小評価する。
ツールに過剰な依存をする（テスト設計またはテスト実行と置き換えられると考える、または 動テストの方が適したケースで自動テストを利用できると考えるなど）。
ツール内にあるテスト作業成果物のバージョン管理を怠る。
重要なツール間での関係性と相互運用性の問題を無視する。例えば、要件マネジメントツール、 構成管理ツール、欠陥マネジメントツール、および複数のベンダーから提供されるツールなど。
ツールベンダーがビジネスを廃業したり、ツールの販売から撤退したり、別のベンダーにツールを売ったりするリスクがある。
ツールのサポート、アップグレード、欠陥修正に対するベンダーの対応が悪い。
オープンソースプロジェクトが停止する。
新しいプラットフォームや新規技術をサポートできない。
ツールに対する当事者意識が明確でない（例えば、助言や手助け、および更新など）。
✔ テスト実行ツールとテストマネジメントツールの特別な考慮事項
組織にてテスト実行ツールとテストマネジメントツールを選択および統合する際には、実装を支障なく正常に完了するために、多くの事項を考慮する必要がある。
■ テスト実行ツール
自動化テストスクリプトを使ってテスト対象を実行する。
この種類のツールで大きな効果を出すには、大量の工数をかけねばならないことが多い。
テストをキャプチャーするアプローチ：
手動テストの担当者の操作をそのまま記録することでテストの実行手順をキャプチャーするのは魅力的である。
しかし、このやり方は大量のテストスクリプトを活用するよう拡張できない。テストをキャプチャーしたときのスクリプトは、特定のデータや動作で線形表現した、各スクリプトの一部にすぎない。
この種のスクリプトは、予期しな い事象が起きると、動作が不安定になる。システムのユーザーインターフェースには常に更新がかかるため継続的なメンテナンス作業が必要である。データ駆動テストアプローチ：
このテストアプローチでは、テスト入力と期待結果をスプレッドシートに記述してスクリプトから分離する。
そして、入力データを読み込み、異なるテストデー タで同じテストスクリプトを実行する汎用的なテストスクリプトを使う。キーワード駆動テストアプローチ：
このテストアプローチでは、実行する動作を定義するキーワ ード（アクションワードとも呼ぶ）を汎用スクリプトが処理し、その後、キーワードスクリプトを呼び出して付随するテストデータを処理する。
※どのようなスクリプト技術を使用したとして も、各テストの「期待結果」は、テストの実行結果と動的に比較するか、蓄積しておいて実行後に比較する必要がある。
モデルベースドテスト（MBT）ツールでは、機能仕様をアクティビティ図などモデルの形式として表すことができる。
↑この作業は主にシステム設計担当者が行う。
MBTツールはモデルを解釈してテストケース仕様を作成する。
これらのテストケースは、テストマネジメントツールに格納し、そして/またはテスト実行ツールを使用して実行する。
テスト実行ツールの考慮事項
テストスクリプトやテストデータの作成のコストが大きくなる可能性がある
テストケースやテストデータのメンテナンスコストや構成管理が必要となる
■上記の対策データ駆動方式
テストデータとテストスクリプトを切り分ける
テストデータはスプレッドシートで準備し、テストスクリプトは汎用化する
キーワード駆動方式
テストスクリプトをキーワード化し関連付けておくことで、キーワードによるテストスクリプトの作成を可能にする
モデルベースドテストツールによる、テストケースの生成
■ テストマネジメントツール
テストマネジメントツールは、以下に示すさまざまな理由により、他のツールやスプレッドシートとのインターフェースが必要である。
組織が必要とするフォーマットで利用できる情報を作成する
要件マネジメントツールで要件に対する一貫したトレーサビリティを維持する
構成管理ツールでテスト対象のバージョン情報と同期する
※これは、テストマネジメントモジュールに加えて、組織内の異なるグループが使用する他のモジュール （例えば、プロジェクトスケジュールや予算情報）を含む統合ツール（例えば、アプリケーションライフサイクルマネジメント）を使用する場合に特に重要になる。
✔ ツールの効果的な使い方
ツールを選択する際の基本原則
組織向けにツールを選択する際の基本原則は、以下の通りである。
自分たちの組織の成熟度、長所と短所を評価する。
ツールを活用するためにテストプロセスを改善する機会を識別する。
テスト対象で使用する技術を理解して、その技術と互換性のあるツールを選択する。
組織内で既に使用しているビルドツールや継続的インテグレーションツールを理解して、互換性と統合の可否を明らかにする。
明確な要件と客観的な基準を背景にツールを評価する。
無料試行期間があるかどうか（およびその期間）を確認する。
ツールベンダー（トレーニングや、サポートメニュー、ビジネス的な要素も含む）、もしくは無料ツール（オープンソースツールなど）のサポートを評価する。
ツールを使用するためのコーチングおよびメンタリングに関する組織内での要件を識別する。
ツールに直接携わる担当者のテスト（およびテスト自動化）スキルを考慮して、トレーニングの必要性を評価する。
さまざまなライセンスモデル（有料、オープンソースなど）の長所と短所を考慮する。
具体的なビジネスケースに基づいて、費用対効果を見積る（必要に応じて）。
最後に、「コンセプトの証明（proof-of-concept）」を行う。
つまり、テスト対象のソフトウェアに対して、現在のインフラストラクチャーの中で効果的に使用できるツールなのかを立証する。
■ ツールを組織に導入するためのパイロットプロジェクト
コンセプトの証明が成功し、ツールの選定が完了した後、一般的には、組織へのツール導入をパイロットプロジェクトから始める。
パイロットプロジェクトには以下のような目的がある。
📝パイロットプロジェクト
機能範囲や対応範囲、ユーザー数などを制限して実行する先行的/試験的プロジェクトのこと。
ツールに関する知識を深め、強みと弱みを理解する。
現状のプロセスや実践しているやり方にツールをどのように適用するかを評価する。そして何を変更する必要があるかを特定する。
ツールやテスト作業成果物の標準的な使用方法、管理方法、格納方法、メンテナンス方法を決める（例えば、ファイルやテストケースの命名規約の決定、コーディング規約の選択、ライブラリーの作成、およびテストスイートをモジュール化した際の分割度合いの良し悪しの定義など）。
期待する効果が妥当なコストで実現可能かどうかを見極める。
ツールによって収集およびレポートをさせたいメトリクスを理解し、メトリクスを確実に記録し レポートするようにツールを設定する。
✔ ツール導入の成功要因
組織内でツールの評価、実装、導入、日々のサポートを成功させるには、以下が必要になる。
ツール未使用の部署にツールを順々に展開する。
ツールが適用できるよう、プロセスを調整、改善する。
ツールのユーザーに対し、トレーニング、コーチング、メンタリングを行う。
利用ガイドを定める（例えば、組織内の自動化標準）。
ツールを実際に使用する中で得られる情報の集約方法を実装する。
ツールの利用状況や効果をモニタリングする。
ツールのユーザーサポートを提供する。
すべてのユーザーから、得られた教訓を集める。
開発とは別の運用に責任を持つ組織および/またはサードパーティのサプライヤーなども巻き込んで、ツールが技術的にも組織的にもソフトウェア開発ライフサイクルに統合できることを確認することも重要である。