1.1

テストの必要性

どうしてテストが必要なのか？
・経済的な損失
人員配置
・時間の浪費
その原因究明や解決に思った以上の時間をかけることになる。

・信用の失墜
もうあそこには頼まない
・損害や死亡事故
ブレーキが聞かないなど。まぁWebでそれはないと思うけど。

■エラーの原因
エラー（誤り）
「間違った結果を生み出す人間の行為」人間というのが大事。
勘違い
思い込み
納期のプレッシャー
コードの複雑さ
内部構造の複雑さ
技術の変更
他システムとの連携ミス

フォールト（fault)
「要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシステムの中の不備」
エラーによってfaultを埋め込むことに。
※バグ・欠陥・フォールトは同義

故障(failure)
｢コンポーネントやシステムが、期待した機能、サービス、結果を提供できないこと」
欠陥があっても、そのコードが動かなければ故障とはならない。

インシデント　（不具合・障害）
テストの際に記載するのが「インシデントレポート」
「ソフトウエア・システムを実際に使うユーザー（テスト担当者）が
期待する動きと実際の動きが一致しない事象」

1.1.3

リスクとは「悪い結果になってしまう可能性」

1.1.4　テストと品質
ソフトウエアの品質→「顧客の満足度」
「顧客が喜ばなければ品質は高いとはいえない」

「当たり前品質」と「魅力的品質」
場合によっては互いにトレードオフ

品質の確保のためには、まず品質を計測すること。
計測例として
・要件ごとのテストカバレッジと故障発生件数
・テスト実施時間の経過と故障発生件数の推移
・システムの姓のう(応答時間やスループットなど）のデータ収集

1.1.5 テストの十分性
どこまでテストをするのかは、以下を考慮して
・技術的、ビジネス的なプロダクトリスクの度合い（テストカバレッジ、故障率など）
・プロジェクトリスク（テストを含む開発全体の進捗）
・工程（スケジュール）や予算などプロジェクトの制限