* パイロット プロジェクトとは、テスト自動化ツールを大規模に実装する前に、その実現可能性、有効性、適合性を評価するために実施される小規模な実験または試験です1。
* パイロット プロジェクトの目的は、テスト自動化イニシアチブのコンテキストと範囲によって異なる場合がありますが、一般的な目的は次のとおりです2。
* ツールの機能とオプションに慣れるため
* ツールが既存のテストプロセスと環境にどのように適合するかを確認する
* ツールの使用による利点と課題を評価する
* ツールの実装と使用に関する標準とガイドラインを決定する
* ツールの導入と保守に必要なコストとリソースを見積もる
* したがって、オプションCはパイロットプロジェクトの有効な目標ではありません。この段階では、すべてのテスターにツールの使用方法をトレーニングする必要はないからです。すべてのテスターにツールの使用方法をトレーニングするのは、ツールが選定され、本格的な導入が承認され、標準とガイドラインが確立された後に行う方が適切です。パイロットプロジェクト中にすべてのテスターにツールの使用方法をトレーニングすることは、ツールが本来の目的に適していない、または効果的でない可能性があり、あるいは後日別のツールに置き換えられる可能性があるため、非効率的でコストがかかり、時期尚早です。
参考文献:
* 1: ISTQB認定テスター基礎レベルシラバス2018、バージョン4.0、p.82
* 2: ISTQB認定テスター基礎レベルシラバス2018、バージョン4.0、p.83
* : ISTQB 認定テスター Foundation Level シラバス 2018、バージョン 4.0、p. 84
* : ISTQB 認定テスター Foundation Level シラバス 2018、バージョン 4.0、p. 85

プロジェクトリスクとは、スコープ、スケジュール、コスト、品質といったプロジェクト目標に影響を与える可能性のある不確実性や脅威のことです。ISTQB Certified Tester Foundation Level (CTFL) v4.0のシラバスによると、プロジェクトリスクに寄与する要因には以下のようなものがあります。
* スキルと人員不足：この要因は、プロジェクトのタスクを遂行するのに十分な、あるいは資格のある人材が不足していることを指します。これは、遅延、エラー、手戻り、生産性の低下につながる可能性があります。
* 適切な要件定義における問題：この要因は、プロジェクトの要件の抽出、分析、仕様策定、検証、または管理における困難さや曖昧さを指します。これにより、要件の不整合、矛盾、ギャップ、または変更が生じ、プロジェクトのスコープと品質に影響を与える可能性があります。
* 契約上の問題：この要素は、クライアント、サプライヤー、ベンダー、下請け業者など、プロジェクト関係者間の契約上の合意から生じる可能性のある課題や紛争を指します。これは、法的、財務的、または倫理的なリスクにつながり、プロジェクトの成果と満足度に影響を与える可能性があります。
他のオプションは、プロジェクト リスクではなく製品リスクに寄与する要因をリストしているため、正しくありません。
製品リスクとは、ソフトウェア製品またはシステムの品質や機能に影響を及ぼす可能性のある不確実性や脅威のことです。製品リスクに寄与する要因には、以下のようなものがあります。
* ソフトウェア品質特性の低さ：この要因は、信頼性、ユーザビリティ、セキュリティ、パフォーマンス、保守性といったソフトウェア製品またはシステムの品質特性または基準が遵守されていないことを指します。これは、欠陥、障害、またはユーザーや利害関係者の不満につながる可能性があります。
* ソフトウェアが意図した機能を実行しない：この要因は、ソフトウェア製品またはシステムの期待される動作または出力と実際の動作または出力との間の偏差または不一致を指します。これにより、
* ソフトウェア製品またはシステムのエラー、障害、または誤動作。
参考資料 = ISTQB Certified Tester Foundation Level (CTFL) v4.0 シラバス、第 1 章: テストの基礎、セクション 1.5: リスクとテスト、14 ～ 16 ページ。

プログラムがテストで 100% の判定カバレッジを獲得した場合、すべての実行文がカバーされることが保証されます。判定カバレッジ (分岐カバレッジとも呼ばれます) は、構造カバレッジ (ホワイトボックス カバレッジとも呼ばれます) の一種で、テスト スイートによって実行された判定結果の数を測定します。判定結果とは、プログラム コード内の判定ポイント (if-then-else 文など) の考えられる結果です。判定カバレッジでは、各判定ポイントで true と false の両方の結果がテスト スイートによって少なくとも 1 回実行されている必要があります。判定カバレッジはステートメント カバレッジを暗黙的に含みます。ステートメント カバレッジは、テスト スイートによって実行された実行文の数を測定する、別の種類の構造カバレッジです。ステートメント カバレッジでは、各実行文がテスト スイートによって少なくとも 1 回実行されている必要があります。したがって、プログラムがテストで 100% の判定カバレッジを獲得した場合、そのテストではステートメント カバレッジも 100% になり、すべての実行文がカバーされていることを意味します。プログラムがテストで 100% の判定カバレッジを獲得した場合、他のオプションが真であるとは保証されません。プログラムがテストで100%の判定カバレッジを達成したとしても、すべての出力同値クラスがテスト済みであり、すべての入力同値クラスがテスト済みであることは保証されません。これは、同値クラスがコード構造やロジックではなく、機能要件または仕様に基づいているためです。同値クラスは、テスト対象システムの内部構造や実装を考慮しないテストの一種である仕様ベーステスト（ブラックボックステストとも呼ばれます）で使用されます。
決定カバレッジは、テスト対象システムの内部構造や実装を考慮したテストの一種である構造ベーステスト（ホワイトボックステストとも呼ばれる）で使用されます。したがって、
100%の判定カバレッジは、100%の同値クラスカバレッジを達成することを意味するものではありません。プログラムがテストで100%の判定カバレッジを達成したとしても、「デッド」コードがカバーされていないという保証はありません。デッドコード（到達不能コードとも呼ばれる）とは、論理エラーや設計上の欠陥のために実行できないコードだからです。デッドコードはコードの可読性と保守性を低下させ、複雑さとサイズを増加させる可能性があります。判定カバレッジは、実行可能な判定結果のみを考慮するため、デッドコードは考慮されません。したがって、100%の判定カバレッジを達成したとしても、デッドコードがカバーされていないという保証はありません。検証済みの参考文献：A Study Guide to the ISTQB® Foundation Level 2018 Syllabus - Springer、36ページ。

静的解析ツールは、プログラムを実行せずにそのソースコードを検査するソフトウェアツールです。構文エラー、コーディング規約違反、セキュリティの脆弱性、潜在的なバグなど、さまざまな種類の問題を検出できます12。ただし、静的解析ツールでは、非常に低い MTBF (平均故障間隔)3 など、プログラムの実行時の動作やパフォーマンスに依存する問題を特定することはできません。MTBF は、システムまたはコンポーネントの信頼性の尺度です。総稼働時間を故障数で割って計算されます。MTBF は、システムまたはコンポーネントが予想される寿命中に故障する頻度を反映します。静的解析ツールはプログラムを実行したり故障を観察したりしないため、MTBF を測定できません。MTBF は、さまざまな条件下でプログラムを実行し、故障に関するデータを収集する動的テストによってのみ推定できます4。したがって、非常に低い MTBF は、静的解析ツールでは特定できない問題です。
その他の選択肢、たとえば無限ループの可能性、未定義値を持つ変数の参照、セキュリティ上の脆弱性などは、静的解析ツールで特定できる問題です。静的解析ツールは、プログラムの制御フローとデータフローを解析し、決して偽にならない可能性のある条件をチェックすることで、無限ループの可能性を検出できます5。静的解析ツールは、変数のスコープと初期化をチェックし、初期化されていない変数の使用を報告することで、未定義値を持つ変数の参照を検出できます6。静的解析ツールは、バッファオーバーフロー、SQLインジェクション、クロスサイトスクリプティング、弱い暗号化など、安全でないコードの一般的なパターンをチェックすることで、セキュリティ上の脆弱性を検出できます。参考資料 = 静的解析とは? 静的コード解析ツール - Perforce ソフトウェア、静的コード解析の仕組み | Perforce、静的コード解析: テクニック、主な 5 つの利点と 3 つの課題、MTBF とは? 平均故障間隔の説明 | Perforce、静的解析ツール - ソフトウェアテスト MCQs - CareerRide、ISTQB_Chapter3 | Quizizz、[セキュリティ脆弱性の静的コード分析 | Perforce]。

このレポートに対する正当な批判は、アプリケーションのバージョンが欠落しているというものです。アプリケーションのバージョンは、ソフトウェア製品のどのリリースまたはビルドに欠陥が含まれているかを識別するのに役立つため、欠陥レポートに含めるべき重要な情報です。また、バージョンが異なると動作や機能が異なる場合があるため、アプリケーションのバージョンは欠陥の再現とデバッグにも役立ちます。その他の選択肢は、このレポートに対する正当な批判ではありません。優先度、修正の説明、開発者名は欠落しているのではなく、このレポートには該当しません。優先度は、欠陥をどれだけ緊急に修正する必要があるかを示す尺度であり、欠陥を報告したテスターではなく、プロジェクト マネージャーまたは欠陥追跡システムによって割り当てることができます。修正の説明と開発者名は、欠陥が報告されたときではなく、欠陥が解決された後に追加される情報です。適用可能な要件（トレーサビリティ）へのリンクがないことは、このレポートに対する正当な批判ではありません。トレーサビリティは、欠陥レポートの必須属性ではなく、オプション属性だからです。トレーサビリティとは、2つ以上のエンティティ（要件、テストケース、欠陥など）間の関係性であり、それらがどのように関連または依存しているかを示します。トレーサビリティは、テストケースと欠陥が要件を満たしていることの検証に役立ちますが、欠陥の報告に必須ではありません。説明が問題の原因を明確にしていないことは、このレポートに対する正当な批判ではありません。問題の原因を明確にすることは、欠陥を報告したテスト担当者の責任ではなく、欠陥を修正した開発者の責任だからです。説明には、入力値、期待される結果、実際の結果、エラーメッセージ、スクリーンショットなど、欠陥が発生したときに何が起こったかを説明するのに十分な情報が含まれている必要がありますが、なぜ、どのように発生したかを説明する必要はありません。検証済み参考文献：A Study Guide to the ISTQB Foundation Level 2018 Syllabus - Springer、140ページ。