・ソフトウェアテストとは欠陥を取り除いて、ユーザーの要求を満たす、品質（使いやすいUI/UX）のよいソフトウェアを作ること
・欠陥とは誤動作の原因がソフトウェアと特定されたもの
・不具合とは原因が特定される前の欠陥も思われる現象
・ソフトウェアを搭載した製品が多機能化してきている、一方で開発期間の短縮化も進み、エンジニアの負担として重くのしかかっている
・ソフトウェアの品質特性規格のISO/IEC25010によると8つの特性に分類される

①機能適合性
②性能効率性
③互換性
④使用性
⑤信頼性
⑥セキュリティ
⑦保守性
⑧移植性

・ユーザーの嗜好が多様化している中で、テスト担当者がユーザーの求めていることを完全に把握把握することは不可能であり、この実態に有効な品質モデルに狩野モデルがある
・狩野モデルの3つの品質
①当たり前品質：ユーザーの基本要求（これだけは絶対満たしてほしいと考える）を満たす品質
②一元的品質：充足されていると満足し、不充足だと不満に感じる機能
③魅力的品質：充足されていると満足し、不充足だと「仕方がない」と感じる機能
・テストを行う際には、品質とユーザー満足度の関係を理解した上で対象ソフトウェアの各機能を狩野モデルの品質要素に分類しておくと良い　
・魅力的品質よりも当たり前品質の機能テストに多くの時間を割くなどテストの時間配分もできる
・開発仕様書には欠陥と分類されていないものも、ユーザーが不満に感じると考えられるものは欠陥として拾い上げ品質を高める働きかけも重要

◼️テスト視点
①V&V（検証と妥当性確認）
・Verification（検証）とは仕様書通りにソフトウェアが作成されているかを確認すること
・ソフトウェアを実際に動作させて確認する
・Validation（妥当性確認）とはユーザーの要求どおりにソフトウェアが作成されているから確認すること
・ソフトウェアを動作させるだけでなく、仕様書の妥当性もチェックする
・常にユーザーの要求はなにか、ユーザーにとって問題にならないかといった疑問を持つ

②Never、Must、Want
・Never（あってはならないこと）、Must（できなければならないこと）、Want（できたらよいこと）
・テストを実施する際はテストケースを実行することに意識が行きがちですが、「仕様通りだが改善した方が良い点」「ユーザビリティへの気付き」などがあれば積極的発信すると良い

①ウォーターフォール型開発モデル
・一つの工程が完了してから次の工程が始まる
・テスト工程は一つの工程として表されるが、実際は要求定義からコーディングまでの全行程に対応したテストを実施する必要がある
・中でも上流の各工程に対応させてテスト工程を分割したものをV字モデルとよぶ
・テスト工程は単体→結合→機能→システムの順に進む

◼️開発の流れ
1、要求定義
・ユーザーのニーズや企画担当が頭に描く要望を製品企画書やヒアリングによって引き出したうえで、わかりやすく整理し、最終的に要求として定義する
エアロバイクの例）
ユーザー環境：ジムの一般ユーザー→運動が目的なので複雑な操作にすべきでない
機能要求：運動中のペースを維持したい。運動に疲れてしまうとペースを維持できない
→解決策（要求仕様）、ペダルを漕ぐペースに合った音楽を流す
　制約条件：同じ時間内でより効率よく運動したい
→解決策（要求仕様）、ペダルを漕ぐペースよりも少し早いペースの音楽に自動で切り替える

2、基本設計（概要設計）
・要求項目を実現するために必要なソフトウェアの機能や構成といった基本的な仕様をまとめる
・その要求をソフトウェアシステムとして実現する方法まで落とし込む
・エアロバイクの例の場合、画面をどのような構成にするか、何種類の音楽を準備するかなど決定する

3、詳細設計
・基本設計で定義した仕様をもとにコーディングに必要な各処理の詳細な仕様を決定する
・連携方法（モジュール間のデータ授受など）も決定する

4、コーディング

◼️テスト工程の流れ
1、単体テスト
・モジュールごとに行うテスト
・多くの場合、コーディングを行ったプログラマ自身が担当

2、結合・機能テスト
・複数のモジュールを組み合わせて動作するテスト
・詳細設計で定義したモジュール間の連携方法が実現されているか確認
・モジュールの動作順やタイミングも確認する
・機能テストは組み合わせたモジュールを一つの機能としてテストする
・本書では結合・機能テストの両方を基本設計に対応するテスト工程としているが、単体テストのあとに機能テストのみの場合もある

3、システムテスト
・個々のモジュールや機能を統合した状態で要求定義の内容が実現されているかを確認するテスト
・最終的に製品やサービスとして出荷される状態に近い形で実施する

◼️テストの分類（P26）
・分類の軸として
1、ソフトウェアの内部構造に注目するか/しないか
・ホワイトボックステスト、ブラックボックステストとして分ける
2、ソフトウェアを動作させる/させないか
・静的テストと動的テストとして分ける
3、ソフトウェア開発の工程か否か
・開発工程とテスト工程に分ける

◼️テスト計画、テスト設計の流れ
①テスト計画
１、テストの目的を確認する
・テストの範囲（対象とする機能）、概要、方法を定めるテストのアプローチを決定する
2、機能一覧表を作成する
・テスト範囲におけるテスト対象が持つすべての機能を洗い出す
3、テスト観点（切り口）を抽出する
・例として
　画面に表示される計算結果の正しさを確認する（表示確認、計算結果の観点）
　入力項目のチェック機能を確認する（入力確認の観点）
　処理時間を確認する（レスポンスタイムの観点）

②テスト設計
4、テスト観点を機能へ割り当てる
・機能とテスト観点を配置したテストマップ（P36）を作成し、テストが必要な機能とテスト観点の組み合わせ表を作る
5、テスト技法の検討と適用
・テストマップに対して一つひとつの組み合わせに対してテスト設計を進める
6、その他の検討事項
・1〜5のステップで理想的なテストアプローチは定まるが、実際にはリソースやスケジュールといったことを勘案したうえで実現可能なテストのアプローチを定める　
★テスト観点一覧表の作り方（P 38〜40）

・ソフトウェアの中身を意識せずに行うテスト「ブラックボックステスト」
・ソフトウェアの中身を理解してそれを意識しながら行うテスト「ホワイトボックステスト」
・ホワイトボックステストはモジュールの一つひとつの単体テストで用いられる
・ホワイトボックステストには
①制御フローテスト：命令文の処理順序の確認
②データフローテスト：データの流れの確認
・メリットは「モジュール内部の処理（命令文）単位で動作確認でき、検出された欠陥はモジュール内部に限定されるため、モジュールの調査と変更だけで修正を完了できる

◼️論理構造
・モジュールに含まれる処理の流れや実行順序を「論理構造」と呼ぶ
・本書の割り勘計算システムの順番を間違えると0除算が発生するなどの状態を「モジュールの論理構造に誤りがある」という
・フローチャートを利用することで論理構造を視覚化できる
・フローチャートを描いたり修正したりするのは手間だがホワイトボックステストをするためには確実に作っておくべき

A）制御フローテストの実施方法
・モジュールを構成する「命令文」「分岐した、経路」「条件」のいずれかに着目し、これらが全て実行されるかを確認する（P57に詳細例）
1、ソースコードをもとにフローチャートを描く
2、カバレッジ基準を決める
・着目する要素「命令文」「分岐した経路」「条件」をカバレッジ基準という
3、カバレッジ基準を網羅する経路を抽出する
4、抽出した経路を通るようにテストする
5、結果を確かめる

カバレッジ基準①：ステートメントカバレッジ
・着目する要素に命令文を選択した場合
　→すべての命令文を最低一度は通るテスト
カバレッジ基準②：デシジョンカバレッジ
・着目する要素に分岐した経路を選択した場合
　→分岐の起点となるステートメント後の全ての経路を最低一度は通るようにテスト
カバレッジ基準③：複合条件カバレッジ
・着目する要素に条件を選択した場合
　→条件に含まれるすべての条件パターンを満たすようなテスト
　→対象のモジュール内にANDやORで結ばれた複合条件に利用できる

・カバレッジ基準①②③の順にテスト回数も増える
・3種類のカバレッジは上位（③）が下位（①）のカバレッジを包含する関係にある

B）データフローテストの実施方法
・ソフトウェアの中で使われるデータや変数が「定義」→「使用」→「消滅」の順に正しく処理されているかを確認するテスト

・ブラックボックステストは膨大な数に及ぶテスト項目を効率的に絞り込む方法としてさまざまなテスト技法がある（P26参照）

・ソフトウェアテストでは通常すべての入力値と条件を一つひとつのテストすることはできない

①同値分解テスト
・同値パーティション（同じ動作をする条件の集まり）ごとにテストを行うテスト技法
・同じ処理結果となる入力値の集まり、同じ処理結果となる時間の集まり、同じ入力値から処理される出力結果の集まりなど
・本書のパスワードの例の場合パスワードの仕様は4文字以上15文字以下なので、4〜15文字の設定完了メッセージは同じで、3文字以下または16文字以上の場合はエラーメッセージが表示される
・4〜15文字の同値パーティションはパスワードとして設定可能なので「有効同値パーティション」
・3文字以下または16文字以上の同値パーティションは「無効同値パーティション」
・同値パーティションの範囲が連続した値になる場合もあればそうならない場合もある
例えば判読性の低い「大文字のアイ：I」、「小文字のエル：l」、「数字のイチ：1」がパスワードに使用できない文字として指定されている場合はなど

◼️同値分割テストの実施方法（パスワードの例）
1、各同値パーティションから最低１つの代表値を選ぶ
・有効同値パーティションの代表値：9文字
・無効同値パーティションの代表値：2文字
2、同値テストの考え方
・代表値でテストした結果、欠陥が見つかれば同値パーティション内の他の値でも同じ欠陥が見つかるだろう
・欠陥が見つからなければ、同値パーティション内の他の値でも同じ欠陥は見つからないだろう
・本当にそれだけで大丈夫か？と疑問が湧くと思うが、代表値だけでは欠陥の可能性を全て払拭はできない
・ただしテスト技法の目的はテストの効率化なので疑問や不安を突き詰めてしまうと結局全部テストしないといけなくなる
3、開発仕様書から読み取れる同値パーティションと内部構造が常に一致しているわけでないことを理解しておく

②境界値テスト
・仕様条件の境界となる値と隣接する値に対してテストを行う技法
・欠陥は境界に潜んでいる可能性が高い
・境界には「以上」「以下」「未満」「より大きい・小さい」「〜まで」などさまざまなものがあり誤解の要因になる

◼️境界値テストの実施方法
1、テスト対象の項目を確認
・その他の技法も含めてテスト設計を考え、境界値テストが適用できるか確認する
2、境界を見つける
3、境界値を決める
4、テストする値を決める
・境界値、境界値の1つ下、１つ上の値など
・境界値には開発仕様書から読み取ることのできないソフトウェア内部にある境界値である隠れた境界値がある
・隠れた境界値は開発期間中の仕様変更によって生じる（プログラマが元の仕様に戻されるかもしれないと考え残すことがある）

・デシジョンテーブルとは複数の条件によって決定されるソフトウェアの動作の一覧表
・動作が変わる条件に着目してテストするという点においては同値分割テストや境界値テストに似ているが、これらのテストは単一条件に着目しているがデシジョンテーブルは複合条件に着目している点で異なる
・表の上半分には条件、下半分には条件によって生じるアクションが記述される

◼️デシジョンテーブルの法則
・条件の一行目は左半分にYes、右半分にNo
・条件の二行目は表の長さの1/4にYes、同じ長さで交互にNo、Yesを記入
・条件の三行目は表の長さの1/8にYes、同じ長さで交互にNo、Yesを記入

・デシジョンテーブルを作成する中で条件の組み合わせは存在するが実現不可能な条件があったりする。こうした場合は実現が不可能なものとしてN/Aとしてアクション欄に表現する
・デシジョンテーブルは見やすくするために、同じ条件になるものなど探してなるべくコンパクトにしていくと良い
・デシジョンテーブルが完成した時点でテスト設計はほぼ終了している
・デシジョンテーブルのルール数＝テストケース数というわけではない。実際のテストでは1つのルールから複数のテストを作成する場合もある
・デシジョンテーブルは「発見した欠陥の原因分析」や「静的テスト」でも利用できる
・静的テストとは、ソフトウェアを動作させることなく開発仕様書に誤りや不備がないかを確認する作業

・状態遷移図や状態遷移表を用いたテスト
・ソフトウェアの動作中にさまざまな変化する状態に着目
・状態とは「一定の同じ動作を続けている様子」「動作後に異なる動作を開始しない様子」
・状態やイベントを開発仕様書から抽出してまとめたフロー図や一覧表が状態遷移図・表

◼️状態の詳細（3種類）
①部位の状態：
例）プリンタを構成している部位の状態
印刷中→UIという部位の場合はディスプレイに「印刷中」と表示したりすること

②処理の状態：
例）プリンタで動作しているソフトウェアの処理の状態
印刷中→PCから送られてきたデータを処理して給紙装置やインク射出部に指示を出している状態

③モードの状態：
例）プリンタ全体でのモードの状態
印刷中→給紙装置はインク射出部の動きやスピードに合わせて印刷用紙を送るなど、各部位とそれを制御するソフトウェアが適切に処理され、プリンタ全体として動作している状態

◼️状態遷移図の作り方
・開発仕様書から状態とイベントを抽出
・状態遷移図の表記方法（P 124）に倣って遷移図を作成する
・最近のソフトウェアは複雑な構成のものが多いため、仕様書に従うと状態遷移図が巨大なものになってしまうため、見やすくするために機能ごとに分割すると良い

◼️状態遷移図からテストケースを作る
・状態遷移図を基にテストケースを作成するには
1、全ての状態を一回は通る
・遷移前の状態、発生させるイベント、期待結果を並べて記載する
2、全てのイベントを一回は発生させる
・発生させるイベントをすべて遷移前の状態と期待結果と並べて記載する
3、全ての遷移を一回は通る
・状態遷移図の矢印の開始（遷移前の状態）と終了（期待結果）を発生させるイベントと並べて記載する

・1、2、3のうちどれが優れているかはそれぞれの特徴を理解したうえで段階的にそれぞれのテストケースをテストすることが必要
・状態遷移図の目的はテストケースを効率的に作ることでなく、「ソフトウェアの動きを網羅的に確認すること」
・状態遷移図が完成したら、ユーザーのシナリオに沿って見直し、全ての遷移が正しく定義されているか確認する
・状態はソフトウェアの出来ることを表す方法であり、テストとしては「できないはずのことが本当に出来ない」ことも確認する必要があるので、不十分

◼️状態遷移表の作り方
・できないことを網羅的に書き表すには状態遷移表が必要
・a）縦軸に「状態」、横軸に「イベント」（状態×イベント）
　b）縦軸と横軸共に状態（状態×状態）
を設定する方法がある
・状態×イベント型のほうが、状態やイベント。漏れなく網羅的に確認できる
・状態遷移図を先に説明したが、状態遷移図を作ってから表を作るわけではない
・状態遷移図と状態遷移表は相互に確認しながら同時に作成する
・状態遷移表が大きくなりすぎた時は、図と同様に機能ごとに分ける

◼️状態遷移表からテストケースを作る
・状態遷移表が出来たら
1、状態遷移が起きるテストケース
2、－（発生しても処理が起きないイベント）のテストケース
3、N/A（発生させることができないイベント）のテストケース

・組合せテストは複数の条件を組み合わせてソフトウェアの動作を確認するテスト技法
・単一の条件だけでは発生しないが、複数の条件が組み合わさった際に発生する欠陥

◼️2因子間網羅
・「因子」とはテスト対象の機能名や設定項目名など
・「水準」とは因子が持つ選択肢や設定値など
・2因子間網羅とは「２つの因子間の組合せをすべて網羅する」ことで、その組合せを作成する手法には「直交表」や「All-Pairs法」などがある
・なぜ2因子間網羅で3や4などではないのかという、ソフトウェアテストにおいて「多くの欠陥は2因子間までで見つかる」という定説がある
・All-Pairs法は因子水準表から組合せ表の作成を行っていく
・All-Pairs法で組み合わせ表をつくるツールはいくつかある
※本書ではQumias Plus、PictMasterを紹介

◼️直交表
1、因子水準表をもとに適切な直交表を選択する
2、選んだ直交表テンプレートに因子と水準を割り付ける

◼️All-Pairs法と直交表の違い
・2因子網羅を満たすことだけ考えた場合、一般的にAll-Pairs法の方が組合せ数は少なくなる
・この理由は直交表のテンプレートが2の累乗の大きさに定型化されていること、All-Pairs法では2因子間を満たす組合せが追加されないことなどが起因している（＝直交表には余分な組合せが含まれている）
・3因子以上が原因の欠陥の発生率は高くないが、直交表は3因子以上が条件になる欠陥も発見できる可能性がある（All-Pairs法ではできない）

・適切な因子と水準を選択することが重要だが慣れるまでは難しい
・選択にはテストの目的や役割を理解しておく必要がある
・何をテストするのかを考えて、不要な因子がないかを考えることが重要

・ここでは「現状の悩み」、「テスト対象の仕様の特徴」を軸に、最適なテスト技法を選択出来るチャートを紹介
◼️チャートの使い方（P195）：★本書参照（重要）

◼️テストフェーズで作られるドキュメント
・テスト計画：テスト全体計画書、テスト計画書
・テスト設計：テスト設計仕様書
・テストケース：テストケース、テストデータ
・テスト実施：テストログ、不具合報告書
・テスト報告：テストサマリレポート
※テスト設計〜テスト実施までに進捗管理表も必要

◼️テストケース作成のための中間成果物
1、機能動作確認一覧
・狙いは「テスト対象から検証すべき機能を抽出する（目的機能）」と「目的機能に対してテストの大まかな内容を案出する（確認内容）」
・出来る操作をMust系、できない操作をNever系
・テスト設計する上でNever系が特に重要
・なぜならNever系は機能仕様書に記載されていないためNever系の方に不具合が多く残る
2、テストマップ
・機能動作確認一覧とテスト観点を用いたマトリクス（横軸がテスト観点、縦軸が機能）
3、テストケース
・事前情報、具体的な入力値、テスト実施手順、期待結果、テスト実施結果を記述
4、テストログ
・テスト実施結果、テスト実施環境、テスト対象ソフトウェアバージョン、ソフトウェアのビルド番号、担当者・実施日、テストデータなどを記述
5、不具合報告書
6、進捗管理表
・進捗管理表はテストケースの数だけでなく発見された不具合について以下のような視点の確認も行う
＋想定した不具合に対して実際の不具合数の多少
＋発見された時期に問題ないか
＋大きな影響を与える不具合が多く発見されていないか
＋前のテストで発見されているべき不具合はないか
など単に進捗管理するだけでなく品質状態も把握する

◼️ISO/IEC/IEEE29119（P236）
・これらを参考にして各ドキュメントを作成するのも良い

・P292にテストの状況を把握するための指標の一覧

◼️アジャイル開発の概要
・大まかな流れ
1、リリース計画の立案
・開発プロセスにおいて全体としてどのように開発していくかを定めたもの

2、ユーザーストーリーと受け入れ基準の作成
・ユーザーの要求を示したもので、受入基準（合格基準や品質目標）と合わせて事前に考える
・事前に洗い出すことが良いがイテレーションのの合間に追加や変更、詳細化を行う

3、イテレーション（反復）計画の立案と実行
・一回のイテレーションでどのユーザーのどのユーザーストーリーに対応しいつリリースするのかを定めるもの
・テスト担当者は受け入れ基準と照らし合わせてテストを検討し手動のテストを実施する
・イテレーションの期間はとにかく短い

4、何度かのイテレーションを繰り返して製品完成
・短い時間の中で「要求分析→設計→テスト→リリース可能な成果物の作成」

◼️ウォーターフォールとの違い
1、ユーザーの要求を考える部分は同じ
2、要求のまとめ方は異なる
・ウォーターフォールの場合、ユーザー要求は要件定義のフェーズでまとめ上げ、これ以降のフェーズでは要求の分析はしない
・アジャイルの場合は最初のリリース計画でユーザーストーリーを分析し同時に受け入れ基準を定める
・このとき開発対象となるユーザーストーリーは最初に分析した要求の全てではなく優先度にしたがってイテレーションごとに部分的に開発していく
・アジャイル開発のメリットとしてイテレーション間で要求の追加や仕様変更に対応しやすい
3、開発の進め方は違う
・ウォーターフォールは基本設計と詳細設計のそれぞれで作り込みが行われレビューを経て次のフェーズに行く
・アジャイル開発ではイテレーションの中で要求分析、設計、コーティング、テスト、成果物のリリースまで行うため、イテレーションごとに開発プロセスを行う
4、テストの全体計画は同じ
5、テストの設計は同じ
・アジャイル開発の場合は「どんなテストをするのか」「それで抜け漏れがないか」を押さえることが重要
6、テスト実施方法は「異なる」
・ウォーターフォールは各フェーズでテストケースにしたがってテストを行い、仕様整理や画面遷移などの中間資料も作成される
・アジャイル開発はイテレーション期間が短いため、テストケースなどドキュメント化する時間が取れない
・そのため全てをドキュメント化せずに情報を絞ってテストを行う（ただしテスト設計は行う）
7、テスト自動化の導入度合いが違う
・アジャイル開発では単体テストは自動化ツールを使うことが前提
・回帰テストも自動化が進められている
8、テスト担当者の役割は同じ
9、リリースのタイミングは異なる
・アジャイル開発はイテレーションごとにリリースするため、ある程度動作するものを作る必要がある
・イテレーションごとにユーザーや顧客に確認してもらう必要があるため、小まめにユーザーに協力してもらう必要がある
10、不具合の管理方法が違う
・ウォーターフォールでは不具合報告書で管理する
・アジャイル開発の場合は、詳細な不具合報告書は残さず口頭のコミュニケーションで修正することもある
・ただし分析のために必要な不具合項目はアジャイル開発でも残しておくべき
・またイテレーションを跨いで修正することもあるのでデグレ（不具合修正と合わせて元は動いていたものが動かなくなること）

◼️テスト駆動型開発（TDD：Test-Driven Development）
・TDDとはコーディングする際に単体テストの自動化ツールを使い、テストケースを先に作成し、テストがPassedになるようにコーディングする
・TDDの進行ステータス
1、RED：まだテストに合格していない状態
2、Green：ソースコードがテストに合格した状態
3、Refactoring：Greenのソースコードを最適化した状態