# Chap1 テストプロセス
## テスト計画
### テストアナリストの責任
- 全てのテストの種類を検討する(特に機能テスト、使用性テスト)
- テスト見積もりする
    - テスト環境調達、UATの時間含む
- 構成テスト、ドキュメントテスト、インストール手順テスト、修正確認テスト、回​帰テストを​計画する
- ソフトウェアライフサイクル(開発プロセス)​に沿って計画する
- リスクマネジメントセッションの活動に積極的に関与する必要がある(編成責任はない。それはテストマネジャーの仕事)

### インプット
- テスト戦略??
- 同時並行で行われてそうなリスク分析結果(独自解釈)

### アウトプット
- テストプロジェクトのスコープ
- 使用するテスト設計技法(? howをこのタイミングで決める？)
- (テスト終了基準)(独自解釈)

## テスト分析
- テスト条件は、テスト設計仕様に記述します。テスト対象→テストアイテム→テスト条件→テストケースのトレーサビリティが必要
- トレーサビリティマトリクスを別に作成しない場合、テストケース仕様においてもテスト条件を参照できるようにしておく必要があります。

## テスト設計
- 次の条件が満たされる場合、具体的テストケースが良い。そうでなければ論理的テストケースでおk
    1. 要件が適切に定義されている
    2. 監査などテストの外部検証がある
    3. 公式なドキュメントが必要
    4. テスト担当者(アナリスト含む)がテストとプロダクトいずれかに精通していない

### テストケースの作成
#### インプット
- テストケースの詳細度合い(高位/低位)
- テストオラクル
- テストベース
- 特定分野の専門知識、またはそれにアクセスできること

#### アウトプット
1. 目的
2. 事前条件(e.g. テスト環境要件, 受領計画、システムの状況)
3. テストデータ要件(テストケース実行用の入出力データ、システム内に必要なデータ)
4. 期待結果
5. 事後条件(e.g. 影響を受けるデータ、システムの状態、後続処理のためのトリガー)
6. (必要な追加ツール? e.g. コンポーネントテストならドライバやスタブ)

#### すべてのテストレベルで適用可能
- 要求仕様、ユースケース、定義済みのビジネスプロセス -> ユーザ受け入れテスト
- 低位レベルの設計仕様、ユーザストーリー、コード自体 -> コンポーネントテスト

## テスト実装
### アウトプット
- 自動テストの作成
- テストデータ
- テスト環境
- テスト実行計画(独自解釈)
- テスト(手動と自動の両方)実行順序
- リソース割り当てしたテスト実行スケジュール
- テスト手順も？

### テストレベルまたはテストプロセスの手順のいずれかの終了基準を省略した場合
- 次の問題が発生することがある
1. 実装作業がスケジュール遅延
2. 不十分な品質
3. 予期しない余分な作業の影響

## テストのモニタリングとコントロール
- ベースラインを定義し、このベースラインに関して進捗を追跡する必要がある。
- テストアナリストは、データが正確で、タイムリーであり、客観的であるようにする必要がある。

# Chap2 テストマネジメント: テストアナリストの責任
## テストの進捗モニタリングおよびコントロールするもの
1. プロダクト(品質)リスク
2. 欠陥
3. テスト
4. カバレッジ
5. 確信度合い
6. テストにより軽減されたリスク
7. まだ軽減されていないと考えられるリスク

## テストアナリストの責任範囲外
- 計画、モニタリングとコントロール、終了基準の評価とレポート、終了作業
    - TMが主体の作業
    - コンティンジェンシー計画はリスクが実際に発生した場合の行動を記述したものです。

# Chap3 テスト技法
## 同値分割法
- 複数のクラスを組み合わせたテストをする場合、最大カバレッジを取れるテストケース数はワンワイズ法で計算する

## ユースケーステスト
- 代替パスは個別にテストしたほうがいい。まとめてやってしまうとエラーを隠してしまう場合がある

## 原因結果グラフ
- if (C) then E1 else E2 の関係は、原因結果グラフでは、因果関係とnot関係で表現されます。

## 探索的テスト
- チャータ(charter)には貸し切りという意味があるように、テストチームやテスト担当者に対して貸し切りを宣言するものです。チャータには目的と最低限のやるべきこと(作業と成果物)が明示します。さらに探索的テストセッションで用いる場合には、フォーカスする領域、使用するリソース、スコープが記述されます。
- 探索的テストセッションで利用するタイムボックスは、誰が、いつ、どのセッションを行うかを決めたものです。セッションは複数のテスト担当者で同時に並行して行われる場合があります。その時間割がタイムボックスであり、各セッションの担当者に手渡す指示書がチャータです。
- 形式的なテストの前後に仕込むものでもある
- さらにもう一段階進化したのが手続き化されたセッション(scripted session)
    - これは、TMのシラバスに記述のある自律的テストセッション(self-directed session)を日常的なテストの一環として、形式的なテストの前後に組み込んで行うものです。
    - 計画されて行うのではなく、定型的な作業として探索的テストを自主的に行うということです。
    - 形式的なテストの前に行うものはスモークテストの位置づけであり、形式的なテストの後に行うものは、補完の目的です。
    - 自律的テストセッションとは、事前設計したテストセッションをテスト担当者が自律的かつ自発的にテストの手順、入力、期待結果を変更することを許可したものです。

## ドメイン分析
- Binderのテストマトクックスドメイン分析は outを利用しない
- 境界条件式1つをON/OFF評価する際は、それ以外の境界条件式をINに設定する

## ユーザストーリーテスト
- User stories describe functional and non-functional characteristics of a specific small part of a system that must be tested and demonstrated by the team.

## クラシフィケーションツリー
- クラシフィケーションツリーはグラフィカルで説明しやすい

## 状態遷移テスト
- The coverage of valid sequences of N+1 transitions that have been exercised by a test suite.

## 欠陥分類法の作成手順
1. ゴールを作成し、期待する度合いの詳細を定義する
2. 基準として使用する特定の分類法を選択する
3. 値と、組織内または外部での実践で発生した一般的な欠陥を定義する

## 欠陥ベースおよび経験ベースの技法の最適な適用状況
1. 利用できる仕様書がない
2. テスト対象のシステムに関するドキュメントが乏しい
3. テストを詳細に設計および作成するための十分な時間がない
4. テスト担当者は、ドメイン、技術、またはその両方に十分な経験を持つ
5. 手続き化されたテストを基にさまざまテストを行うことが、テストカバレッジを最大化するためのゴールである
6. 操作故障を分析する必要がある

# Chap4 ソフトウェア品質特性のテスト
## 機能テスト
### マトリクス

ソフトウェア品質特性 | 典型的欠陥 | 使用テスト技法 | テストタイミング
--- | --- | --- | ---| ---
正確性 | データや状態の誤った処理 | 多くのテスト技法を使用 | ライフサイクルのすべて
合目的性 | システムやユーザの要求を受け入れられないこと | ユースケースに基づくことができる | システムテスト、統合テストの後半
相互運用性 | 相互作用するコンポーネント間の誤ったデータ交換 | デシジョンテーブル、状態遷移図、ユースケース、及び組みわわせテストなど | コンポーネント統合テスト及びシステムテスト

## 使用性テスト
- 一部では人的リソース、広範な計画、専用のラボ、特定のツール、専門的なテストスキル、ほとんどの場合には膨大な時間が必要になる。
- 状況によっては、使用性またはユーザエクスペリエンスを専門にする別のグループが行う場合もある

## テストの種類

### 発達的使用性テスト
- 使用性設計の欠陥を識別して、設計をガイドする（または「形成」していく）ために、設計およびプロトタイプの段階で繰り返し実施するテスト
    - インスペクション、評価またはレビュー: 要求仕様及び設計における問題を早期に発見する
    - プロトタイプを使用した動的な操作: 完成品のルックアンドフィールがユーザの期待通りであるか早期に確認する

### 総括的使用性テスト
- 開発が完了したコンポーネントまたはシステムの使用性を測定し、問題を識別するために、実装後に実施するテスト
    - 実際の実装の検証と妥当性確認: 要件で指定されたソフトウェアの使用性が実装されているか
    - 調査及びアンケートの実施: システムを操作するときのユーザの振る舞いに関する所見やフィードバックを収集するため
        - SUMI(Software Usability Measurement Inventory): シラバスでは「ソフトウェア使用性測定一覧表」
        - WAMMI(Website Analysis and Measurement Inventory): シラバスでは「Webサイト解析と測定一覧表」

# Chap5 レビュー
## ユースケースレビューのチェックリスト(レビュー項目とレビュー観点)
- メインパス（シナリオ）は明確に定義されているか？
    - 「アクターは〜をする」の形式で書かれていること
- すべての代替パス（シナリオ）は識別されており、エラー処理は完全に備わっているか？
    - ユーズケースに紐づくビジネス／マーケティング要件が満たされない場合がすべて識別されていること
    - すべての代替パスに対してエラー処理／エラー処理完了時の状態が定義されていること
- ユーザインターフェースメッセージは定義されているか？
    - ユーザインタフェースメッセージがユースケースシナリオ内に記載されていること
- メインパスは1つだけ存在するか？複数存在する場合、複数のユースケースが存在するか？
    - メインパスが1つだけ定義されていること
- 各パスはテスト可能か？
    - 定量評価が可能であること。OK/NGの二値で評価できること

# Chap6 欠陥マネジメント
## 欠陥を分類する目的
1. 欠陥のグループ化
2. テストの有効性の評価
3. 開発ライフサイクルの有効性の評価
4. 注目すべき傾向の検出

## 使い方
- 欠陥データを分類しておくと、リスク分析、根本原因分析、ベンチマークにも有効に利用できます。
- 欠陥が集中している／偏在している部分を見極めてテストを集中させることもできますし、信頼性成長曲線を描いて品質の推移を予測することもできます。

## 欠陥分析の目的
- 欠陥の原因を分析すること
- 欠陥やその修正の影響範囲を分析すること
- 欠陥の集合から、欠陥の傾向を分析すること

# Chap7 テストツール
## テストデータ準備ツール
1. カバレッジレベルを達成するのに必要なデータセットの決定
2. 本番環境から取得したデータセットの「選別」「匿名化」(データ整合性を保持しつつ)
3. 特定の入力をもとにテストデータの生成
4. データベース構造を分析して、テストアナリストから必要とされる入力を決定する

## キーワード駆動テスト
- テストアナリストはキーワード駆動自動テストで使用するための正確なデータとキーワードを提供する

## トラブルシューティング
- キーワード、入力データ、自動化スクリプト自体、SUTのどれが原因かの切り分けをする
1. 同じテストを手動で実行する
2. テストの順序をレビューする(おそらく先行する手順で発生している)

# 単語集
- configuration testing(portability testing, 構成テスト)
    - Testing to determine the portability of a software product.
- interoperability(相互運用性)
    - The degree to which two or more components or systems can exchange information and use the information that has been exchanged.
- verify
    - If you verify something, you check that it is true by careful examination or investigation.
- validate
    - To validate a person, state, or system means to prove or confirm that they are valuable or worthwhile.

# その他
- 通常、顧客やユーザーの行うテストシナリオでは、必要最低限の組み合わせのみが取り上げられます
    - 組み合わせテストは単調なテストケースが非常に多くなるので、取り上げられることは少ない
- リスク識別の技法(TMのシラバスから)
    - 専門家へのインタビュー
    - 第三者によるアセスメント
    - リスクテンプレート
    - プロジェクトの振り返り
    - ワークショップ
    - ブレインストーミング
    - チェックリスト
    - 過去の経験