ゼロから始める「JSTQB認定テスト技術者資格」（１日目）
本日は、「1.1 テストの必要性」について学びます。
◆いきなりまとめ
ソフトウェアシステムが期待通りに動かないと、色々な不都合が発生することがわかりました。
例えば「経済的な損失」「時間の浪費」「信用の失墜」「障害や死亡事故」などです。
これらの原因はソフトウェアの欠陥が原因です。
欠陥にも分類があって、「エラー（誤り）」「フォールト（fault）」「故障（failure）」「インシデント」の４つに分類できるそうです。
そこで、テストの役割とは「システム稼働前にテストを行い、欠陥を検出して修正することで問題が発生するリスクを減らすこと」とのことです。
因みに「ソフトウェアシステムリスク」には、以下のようなものがあるそうです。
・リリース後の致命的な欠陥で全品回収
・稼働中システムの低性能のため、業務に支障
話は変わって、ソフトウェアシステムの品質には「当たり前品質」と「魅力的品質」があるとのことです。そして、ソフトウェアテストと品質は、下記３点の関連があるとのことです。
・品質の確保・・テストで欠陥が見つかれば修正
・品質の計測・・欠陥や故障を計測して品質に対して定量的判断をする
・プロセス改善のための情報提供・・テストを品質保証活動に結合して、欠陥分析を開発プロセスに取り込むこと
また、テストの十分性について。どこまでテストすべきかは以下の要因を考慮するとのこと。
・技術面、安全面からみたプロダクトリスクの度合い（テストカバレッジ(注1)、故障率など）
・プロジェクトリスク（テストを含む開発全体の進捗など）
・開発期間や予算などプロジェクトの制限（納期やコストに対する遵守度合い）
最後に、テスト結果をもとにした将来のための情報提供として、ステークホルダへプロダクトの品質に関して情報を提供し、次の開発ステップや次回リリースにおける戦略を決められるように情報を提供すべきとのことです。具体的には、未対応インシデント一覧の提示や、欠陥原因の分析などが考えらるそうです。
1.1_テストの必要性
1.1.1_ソフトウェアシステムの状況
・ソフトウェアシステムが期待通りに動かない事による不都合は以下の４点
(1)経済的な損失・・サポートコスト、機会損失など
(2)時間の浪費・・・修正作業による開発者の時間圧迫、マネジメント(スケジュール)調整など
(3)信用の失墜・・・製品競争力の低下など
(4)障害や死亡事故・正しく動作しないことによる事故など
1.1.2_ソフトウェアの欠陥の原因
・欠陥に関する４用語
(1)エラー（誤り・error）
「間違った結果を生み出す人間の行為」
原因としては、納期のプレッシャー、コードの複雑さ、内部構造の複雑さ、技術の変更、他システムとの通信ミスなど
(2)フォールト（fault）
「要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシステム内の不備」
エラー（誤り）によってプログラムにフォールト（バグ・欠陥）を埋め込んで実装すること
(4)故障（failure）
「コンポーネントやシステムが、期待した機能、サービス、結果を提供できないこと」環境条件によって発生することもある
(4)インシデント
「ソフトウェアシステムを実際に使うユーザーやテスト担当者が期待する動きと、実際の動きが一致しない事象」「インシデント」＝「故障」とはならない
1.1.3_ソフトウェアの開発、保守、運用におけるテストの役割
・ソフトウェアシステムのリスク例
◇リリース後の致命的バグで、全品回収
◇稼働中システムの性能が低いことによる、顧客業務支障
・ソフトウェアシステムが期待通りに動かない事による不都合（経済的損失・時間浪費・信用失墜・障害や死亡事故）へつながる確率を下げるためにもテストを行う
・使い勝手などの非機能要件にかかる課題をテストで発見し、修正することで製品の魅力向上
・契約や法律上の適格要件や業界標準合致の証明
1.1.4_テストと品質
・品質は、大きく「当たり前品質」と「魅力的品質」と捉えられる
「当たり前品質」とは、機能そのものが意図したとおりに動くこと
「魅力的品質」とは、その製品を使いたくなるような特徴
二つの品質は、トレードオフが存在する
・ソフトウェアテストと品質は、次の３点で関係がある
(1)品質の確保
ソフトウェアテストでは、期待する結果と実際の結果の差異をインシデント（不具合）として報告し、リリースする前に欠陥を減らし、品質を確保することが主な仕事となる。テストで欠陥が見つかった場合、その欠陥を修正すれば、システムの品質を確保できる。
(2)品質の計測
欠陥や故障を計測することにより、品質に対して定量的な判断が可能となる。
指標に使うデータは、ソフトウェアの機能要件/非機能要件の両面、品質特性（機能性、信頼性、使用性、効率性、保守性、移植性）の観点などから定義した上で計測する。
（計測例）
◇要件ごとのテストカバレッジと故障発生件数
◇テスト実施時間の経過と故障発生件数の推移
◇システムの性能（応答時間やスループットなど）に関するデータ収集
(3)プロセス改善のための情報提供
「テストを開発標準、教育、欠陥の分析と並ぶ活動の一つとして品質保証活動に結合」
「開発標準におけるテスト位置の見直し、欠陥分析を開発プロセスに取り込むなど」
1.1.5テストの十分性
・どこまでテストすべきかは、以下要因を考慮
◇技術面、安全面、ビジネス面からみたプロダクトリスクの度合い（テストカバレッジ、故障率など）
◇プロジェクトリスク（テストを含む開発全体の進捗など）
◇開発期間や予算などプロジェクトの制限（納期やコストに対する順守度合い）
・テストをもとにした将来のための情報提供
「テストは、ステークホルダへプロダクトの品質に関して十分な情報を提供すべき」
「次の開発ステップや次回リリースにおける戦略決定の品質関連情報を提供」
「未対応インシデント一覧の提示、欠陥原因の分析」
(注１)テストカバレッジ
ソフトウェアテストにおいて、テスト対象となるソフトウェア全体のうち、テストした部分／しようとしている部分が占める割合のこと。
情報システム用語事典：テストカバレッジ（てすとかばれっじ） - ITmedia エンタープライズ
（補足）
なお、当ブログ記事は「ソフトウェアテスト教科書 JSTQB Foundation 第3版」をもとに記載しております。独自の解釈にて記載されていますので、詳細に関しましては、教科書をご購入、参照して頂くことをお勧めいたします。
最後までお読み頂きありがとうございました。
