はじめに
何度もシラバスを読むのは大変なので、要点だけまとめたい気持ちです。
シラバス
1.1 テストとは何か？
1.1.1 テスト目的
- 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
- 故障を引き起こし、欠陥を発見する。
- 求められるテスト対象のカバレッジを確保する。
- ソフトウェア品質が不十分な場合のリスクレベルを下げる。
- 仕様化した要件が満たされているかどうかを検証する。
- テスト対象が契約、法律、規制の要件に適合していることを検証する。
- ステークホルダーに根拠ある判断をしてもらうための情報を提供する。
- テスト対象の品質に対する信頼を積み上げる。
- テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をする。
テストの目的は、テスト対象のコンポーネント、ソフトウェア開発ライフサイクルモデル（SDLC）、ビジネスコンテキストによって異なる場合がある。
1.1.2 テストとデバッグ
テストとデバックは別です、という内容。
テスト・・・ソフトウェアの欠陥によって引き起こされる故障を発生させたり（動的テスト）、テスト対象の欠陥を直接発見したりすること
デバック・・・、故障の原因（欠陥）を発見し、その原因を解析し、原因を取り除くこと
1.2 なぜテストが必要か？
1.2.1 成功に対するテストの貢献
テストをするということは・・・
- 欠陥を検出するためのコスト効果のある手段を提供することになり、テスト対象の品質向上に貢献することになる
- 品質を直接評価し、大きなプロジェクトマネジメント活動の一部として使用できる
- 開発プロジェクトにおいて間接的にユーザーが利用した場合の状況を提供するこ
とになる
1.2.2 テストと品質保証（QA）
QC は、適切な品質の達成を支援する活動に焦点を当てた、プロダクト指向の是正アプローチである。テストは品質コントロールの主要な形式であり、その他に形式的手法（モデル検査や定理証明）、シミュレーション、プロトタイピングなどがある。
QA は、プロセスの実装と改善に焦点を当てた、プロセス指向の予防的アプローチである。よいプロセスが正しく行われれば、よいプロダクトを作ることができるという考えに基づいている。QA は、開発プロセスとテストプロセスの両方に適用し、プロジェクトに参加するすべての人が責任を持つ。
1.2.3 エラー、欠陥、故障、および根本原因
一緒くたにされそうな単語の詳細な定義たち。
| ステップ | 用語 | 定義（何が起きたか） |
|---|---|---|
| ステップ 0 | 根本原因 (Root Cause) | 問題の根底にある理由。人間系の要因が多い（例：トレーニング不足、ツールの不備、コミュニケーション不足）。 |
| ステップ 1 | エラー (Error) | 根本原因によって引き起こされた人間の行為上の誤り（例：設計ミス、コーディングミス）。 |
| ステップ 2 | 欠陥 (Defect) | エラーの結果、成果物（ドキュメントやコード）に作り込まれた不備や間違い。 |
| ステップ 3 | 故障 (Failure) | 欠陥のあるコードが実行された結果、システムが期待通りに動かない現象。 |
1.3 テストの原則
1.テストは欠陥があることは示せるが、欠陥がないことは示せない
そのまま
2.全数テストは不可能
全網羅はできません。
テスト技法、テストケースの優先順位付け、リスクベースドテストを用いて実施すべき。
3.早期テストで時間とコストを節約
上流で欠陥を見つけたほうがよい。
早い段階で欠陥を見つけるために、静的テストと動的テストの両方をなるべく早い時期に開始すべき。
→具体的にどのようにテストを適用したらよいのか調べる
4.欠陥の偏在
そのまま
5.テストの弱化
同じリグレッションテストは、新規欠陥を見つけるには効果は薄れる。
ただ、自動化テストのように「同じテストを繰り返す」ことに意味がある場合もある。
6.テストはコンテキスト次第
具体的なシチュエーション↓
たとえば、短い開発を繰り返すアジャイル開発の場合には、効率よくテストを実施するためにテストの自動化が必要です。開発期間が長いウォーターフォール開発の場合には、基本設計、詳細設計での静的テストを重点的に行うことで手戻りを減らせます。
コスト最優先のプロジェクトでは、限られた工数を最大限に生かすことを考えなければなりませんし、納期最優先のプロジェクトでは、厳密なスケジュールの管理が重要となるでしょう。
このように、それぞれの状況にあった適切なテスト計画を進めていく必要があります。
https://service.shiftinc.jp/column/9681/
7.「欠陥ゼロ」の落とし穴
指定された要件のテストを実施しても、妥当性確認（ユーザーのニーズや期待を満たしているか？顧客のビジネスゴールの達成に役立つか？）を実施しないと意味がない。
1.4 テスト活動、テストウェア、そして役割
1.4.1 テスト活動とタスク
テスト活動は、シーケンシャル（順次的な）ではなく、イテレーティブ（反復的な）にまたは並行して実施されることが多い。
ソフトウェアテストの主要な活動の概要
| 活動 | 目的/役割 |
|---|---|
| テスト計画 | テストの目的を定義し、全体の制約下で目的を最も効果的に達成するアプローチを選択する。 |
| テストモニタリング | すべてのテスト活動を継続的にチェックし、実際の進捗をテスト計画と比較する。 |
| テストコントロール | テストの目的を達成するために必要な行動をとる。 |
| テスト分析 | テストベースを分析して、テスト可能なフィーチャーと関連するテスト条件を定義・優先順位付けし、関連するリスクとリスクレベルを分析する。 |
| テスト設計 | テスト条件をテストケースやその他のテストウェアに落とし込み、テストデータ要件、テスト環境の設計、必要なインフラストラクチャを識別する。 |
| テスト実装 | テスト実行に必要なテストウェア（テストデータ、テストスクリプト）を作成・取得し、テストケースをテストプロシジャー/テストスイートに編成し、実行スケジュール内で優先順位を付け、テスト環境を構築・検証する。 |
| テスト実行 | テスト実行スケジュールに従ってテストを走らせ、実際のテスト結果を期待結果と比較し、不正を分析して、観察された故障に基づいて不正を報告する。 |
1.4.2 コンテキストに応じたテストプロセス
テストとは、以下のようなコンテキストに依存していることになる
- ステークホルダー（ニーズ、期待、要件、協力の意思など）。
- チームメンバー（スキル、知識、経験レベル、空き状況、トレーニングの必要性など）。
- ビジネスドメイン（テスト対象の重要性、識別したリスク、市場ニーズ、特定の法的規制など）。
- 技術的要因（ソフトウェアの種類、プロダクトのアーキテクチャー、利用技術など）。
- プロジェクトの制約（スコープ、時間、予算、リソースなど）。
- 組織的要因（組織構造、現行のポリシー、使用する実践例など）。
- ソフトウェア開発ライフサイクル（エンジニアリングの実践例、開発手法など）。
- ツール（利用可能な状況、使用性、標準適合性など
1.4.3 テストウェア
テストウェアとは・・・
テストプロセスを通じて作成される、テストの計画、設計、実行に不可欠なもの。たとえば、ドキュメント、スクリプト、入力、期待結果、セットアップとクリーンアップの処理手順、ファイル、データベース、環境、その他、テストで使用する付加的なソフトウェアやユーティリティなど
https://istqb-glossary.page/jp/%E3%83%86%E3%82%B9%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2-testware/
| 作業成果物の区分 | 含まれるもの・構成要素 | 備考・補足 |
|---|---|---|
| テスト計画の作業成果物 | ・テスト計画書 ・テストスケジュール ・リスクレジスター ・開始基準と終了基準 |
リスクレジスターの内容： リスクの可能性、影響、軽減策 ※スケジュール等は計画書の一部であることが多い |
| テストのモニタリングと コントロールの作業成果物 |
・テスト進捗レポート ・コントロールのための指示の文書化 ・リスク情報 |
5.3節、5.2節などを参照 |
| テスト分析の作業成果物 | ・テスト条件（優先順位付き） ・欠陥レポート（テストベース内の欠陥） |
テスト条件の例： 受け入れ基準など |
| テスト設計の作業成果物 | ・テストケース（優先順位付き） ・テストチャーター ・カバレッジアイテム ・テストデータ要件 ・テスト環境要件 |
|
| テスト実装の作業成果物 | ・テストプロシジャー ・自動テストスクリプト ・テストスイート ・テストデータ ・テスト実行スケジュール ・テスト環境 |
テスト環境の例： スタブ、ドライバー、シミュレーター、サービス仮想化 |
| テスト実行の作業成果物 | ・テスト結果記録 ・欠陥レポート |
5.5節を参照 |
| テスト完了の作業成果物 | ・テスト完了レポート ・アクションアイテム（改善用） ・得られた教訓のドキュメント ・変更要求 |
変更要求の例： プロダクトバックログアイテムとして追加 |
1.4.4 テストベースとテストウェアとの間のトレーサビリティ
- テストケースと要件のトレーサビリティにより、要件がテストケースでカバーされていることを検証することができる。
- テスト結果とリスクのトレーサビリティは、テスト対象にある残存リスクのレベルを評価する
ために利用できる
→ 「何のために、何をテストし、その結果どうなったか」 この一本線を切らさないことが、正しいカバレッジ計測とリスク判断（モニタリングとコントロール）の鍵となる
1.4.5 テストの役割
以下二つの役割に分かれる。
| 役割 | 主な責任 | 重点を置く活動 | 実施方法・備考 |
|---|---|---|---|
| テストマネジメント |
リーダーシップと管理 （プロセス、チーム、活動全体） |
・テスト計画 ・モニタリングとコントロール ・テスト完了 |
状況により変動する 例：アジャイルではチーム全員で分担、組織横断タスクは専任マネージャーが担当など。 |
| テスト（実務） |
エンジニアリング（技術面） （技術的側面への責任） |
・テスト分析 ・テスト設計 ・テスト実装 ・テスト実行 |
実際のテスト作成や実行などの技術タスクに集中する。 |
1.5 テストに必要不可欠なスキルとよい実践例
1.5.1 テストに必要な汎用的スキル
- テスト知識（テスト技法の活用などによりテストの有効性を高めるため）
- 徹底さ、慎重さ、好奇心、細部へのこだわり、理路整然さ（特に発見しにくい欠陥を識別するため
- 優れたコミュニケーションスキル、積極的な傾聴、チームプレーヤーとなる（すべてのステークホルダーと効果的にやりとりするため、他者に情報を伝えるため、理解してもらうため、欠陥を報告し議論するため）
- 分析的思考、批判的思考、創造性（テストの有効性を高めるため）
- 技術的な知識（適切なテストツールの使用によりテストの効率性を高めるため）
- ドメイン知識（エンドユーザー/ビジネス側代表者を理解し、コミュニケーションできるように
なるため）
1.5.2 チーム全体アプローチ
【チーム全体アプローチの核心】
全員で品質に責任を持つ : 特定の役割に縛られず、必要なスキルを持つメンバーなら誰でもタスクを遂行し、チーム全員が品質に対して責任を負います。
コラボレーションの強化 : 物理的・仮想的に同じワークスペースを共有することで、コミュニケーションと相乗効果（シナジー）を高めます。
1.5.3 テストの独立性
各テストの実施者と作業成果物の開発担当者とを切り分けることで、経歴、技術的視点、バイアスが異なるようになり、異なる種類の故障や欠陥を認識する可能性が高くなる。
| 実施者 | 独立性 | 詳細 |
|---|---|---|
| 作成者本人 | なし | 作成者が自分でテストを行う。 |
| 同じチームの仲間 | ある程度あり | 作成者と同じチームのメンバーが行う。 |
| チーム外（組織内）の担当者 | 高い | 同じ組織内だが、チーム外のテスト担当者が行う。 |
| 組織外のテスト担当者 | とても高い | 組織外の人間（外部委託など）が行う。 |