超(個人)訳JSTQB Foundation Level シラバス Part3
はじめに
前回はテストの目的とテストとデバッグの違いについて説明したが、今回は1.2 なぜテストが必要か？の部分についてシラバス解釈を進めていく。
引用元について
テーマにある通り、ISTQBが提供するFoundation Levelシラバスを引用させて頂く。
1.2 なぜテストが必要か？
テストをすることは品質コントロールの形式の 1 つであり、設定された範囲、時間、品質、予算の制約の中で、合意されたゴールを達成するために役立つ。成功に向けたテストによる貢献は、テストチーム
の活動に限定されるべきではない。ステークホルダーであれば、誰でもプロジェクトを成功に近づける
ためにテストスキルを活かすことができる。コンポーネント、システム、および関連するドキュメント
をテストすることは、ソフトウェアの欠陥を識別するのに役立つ。
ここでいう所の「成功」とは何を意味するか？
自分なりに考えた結果、限られたリソースの中で効率よく欠陥を修正し、目標とする品質に達することができた状態が「成功」と解釈した。仮にそう定義するのであれば、テストの必要性は強く訴求できるものである。
テスト活動はテスト工程内だけで終わらせず、ソフトウェア開発の各プロセスにおいてもテストの知見を活用する機会があり、開発プロセスで作成されるドキュメントのレビュー等が適用しやすい例となる。
1.2.1 成功に対するテストの貢献
テストをすることは、欠陥を検出するためのコスト効果のある手段を提供することになる。この欠陥は、（テスト活動ではないデバッグによって）取り除くことができるため、テストをすることが間接的
にテスト対象の品質向上に貢献することになる。
テストをすることは、SDLCのさまざまな段階において、品質を直接評価する手段を提供する。これらの測定結果は、より大きなプロジェクトマネジメント活動の一部として使用し、リリースの判定など、SDLCの次のステージに移行するための判定に貢献する。
テストを行うことは間接的に品質向上へ貢献すると書いているが、これを読んでふと思ったのは、直接的な品質向上の手段は何か？
テストはあくまで欠陥修正に必要な情報提供の方法の1つで、直接的に品質向上の手段としては、欠陥を修正すること(デバッグ？)やソフトウェア開発プロセスの改善や開発のコード品質向上の取り組みが考えられる。
ざっくりとした解釈だけど、字面通りに読んでも非常に分かりづらいなと。
テストをすることは、開発プロジェクトにおいて間接的にユーザーが利用した場合の状況を提供することになる。テスト担当者は、開発ライフサイクルを通じて、テスト担当者自身が理解するユーザーのニーズが考慮できていることを確認する。別の方法としては、代表的な複数のユーザーに開発プロジェクトへ関与してもらう方法があるが、コストが高く、適切なユーザーを確保できないため、通常不可能である。また、テストは、契約上または法律上の要件を満たすため、あるいは規制基準に準拠するために必要となる場合がある。
テストは間接的にユーザーが利用した時の状況を提供する意図があり、テストはユーザーが望む品質を作り上げるには必要となる手段である。
テストの目的にもあったように、テストはユーザーのニーズを満たしているかを確かめる妥当性確認の側面があり、ユーザーが望む要件が全て満たしていたとしても、ユーザーのニーズを満たせないと不満を抱く可能性がある。だからテストはシラバスで言うところの成功、言い換えるとユーザーが満足する品質を作り上げるための重要な手段である。
1.2.2 テストと品質保証（QA）
「テスト」と「品質保証」（QA）という用語を同じように使う人が多くいる。しかし、テストと品質保証は同じではない。テストは品質コントロール（QC）の形式の1つである。
QCは、適切な品質の達成を支援する活動に焦点を当てた、プロダクト指向の是正アプローチである。テストは品質コントロールの主要な形式であり、その他に形式的手法（モデル検査や定理証明）、シミュレーション、プロトタイピングなどがある。
QAは、プロセスの実装と改善に焦点を当てた、プロセス指向の予防的アプローチである。よいプロセスが正しく行われれば、よいプロダクトを作ることができるという考えに基づいている。QAは、開発プロセスとテストプロセスの両方に適用し、プロジェクトに参加するすべての人が責任を持つ。
テスト結果は、QAとQCで使用する。QCでは欠陥の修正に使い、QAでは開発とテストプロセスがどの程度うまくいっているかについてのフィードバックに使う。
テストはQCを実現するための具体的な方法の1つである。
テストとQAをごちゃ混ぜにして語ることがあるかもしれないが、そもそもの活動目的が異なるため、言葉の意味を理解することがポイントになる。
QAの具体的な活動に開発プロセスやテストプロセスの改善とあるが、プロセスの改善って何をするかと問われると正直ピンと来ていない人もいるだろう。
一言で表せば、「良い品質を作り上げるために、開発プロジェクト全体を通した改善提案を行う」かしっくり来るかもしれない。
イメージしやすいのは、テスト完了後に今回のテストで手動テストの準備に時間と確認がリリースのボトルネックとなったため、次回以降同じテストをする場合を一部を自動化してみるとか、が思い浮かぶ。
シラバスの読解から話は逸れるが、第三者検証の企業は発注側が自社でテストを行うリソースを確保できず、テスト設計〜実行の部分のみ外注する経緯もあり、QC寄りの業務が多い。
付き合いが長くなってくればQA寄りの業務も依頼されることもあるだろうが、発注する会社目線で見ると、仕様から何をテストするかを考え、実際に行うというのは専門的な知見が必要になるため、自分たちでテストを行うより外注した方が最善なのかと考えている。
1.2.3 エラー、欠陥、故障、および根本原因
人間はエラー（誤り）を起こす。そのエラーが、欠陥（フォールト、バグ）を生み出し、その欠陥は、故障につながることもある。人間は、時間的なプレッシャー、作業成果物、プロセス、インフラ、相互作用の複雑度、あるいは単に疲れていたり、十分なトレーニングを受けていなかったりなど、さまざまな理由でエラーを起こす。
ソフトウェアテストを行うと、どうしても動かした結果だけに着目しがちだが、事象そのものより、その背景に何があったのかを抑えておくことで同じミスを防ぐきっかけになる。
シラバスの内容から以下の流れでプログラムの不具合が発生する。
人間が何らかの理由で誤りを引き起こす（エラー）
↓
エラーが原因でプログラムの内部に欠陥が入り込む（欠陥）
↓
プログラムを動かした結果、正しく動作しない（故障）
シラバスから少し外れるが、自分の解釈をいれると実務上ではこんな流れがよくある。
ステークホルダーが検討した要求や要件に何らかの不備(考慮漏れや矛盾)がある
↓
不備のある要件や要求を基に、開発担当がソフトウェアの開発を進める
↓
出来上がった作業成果物をテスト担当が動かした結果、正しく動作しない
実際は要件や設計書のドキュメントレビューは挟んでいるが、根本の問題が最上流にある場合、開発後半になって気づくのと前半で気づくのとでは修正コストに大きな開きが出てくる。
自分で組み立てる家具の工程をイメージしてみると、早い段階で手順のミスに気づくのと出来上がりギリギリに気づいてしまうのとではやり直しにかかる時間に大きな開きが生じる。
早期テストを行う必要があるのは、こうした事象に対して早い段階でフィードバックを行うことで開発後半に大幅な修正を行うリスクを回避するためである。
欠陥は、要件仕様書やテストスクリプトのようなドキュメント、ソースコード、またはビルドファイルのような補助的なアーティファクトの中から発見できる。SDLC の初期に作成されたアーティファクトの欠陥は、もし検出されなければ、しばしばライフサイクルの後半で欠陥のあるアーティファクトにつながる。コードの欠陥が実行されると、システムがすべきことをしない、またはすべきでないことをしてしまうことがあり、故障の原因となる。欠陥の中には、実行すれば必ず故障になるものもあれば、特定の状況下でしか故障にならないもの、絶対に故障にならないものもある。
シラバスにもあるように、欠陥はプログラムに限らず人間が目視で評価できる全ての作業成果物で入り込む余地がある。ドキュメントで言えば、実装時に開発担当者が認識齟齬や誤った解釈を引き起こす表現や内容であれば、それも欠陥とみなされてしまう。
故障の原因は、エラーや欠陥だけではない。例えば、放射線や電磁波によってファームウェアに欠陥が生じる場合など、環境条件によっても故障が発生することがある。
根本原因とは、問題（例えば、エラーにつながる状況）が発生する根底の理由のことである。根本原因は、根本原因分析によって特定される。根本原因分析は、故障が発生したときや欠陥が確認されたときに行われるのが一般的である。根本原因を取り除くなどの対処をすることで、さらに同様の故障や欠陥を防止したり、その頻度を減らしたりできると考えられている。
故障が発生した際は、根本のある要因を取り除かなければ、後続の開発で似たような故障や欠陥が発生しかねない。なぜ故障や欠陥が入り込んでしまったかについて、例えば要件や設計の不備によって欠陥が生じた場合であれば、レビュープロセスの見直し等の改善策を打ち出すことで根本原因の減らすきっかけととなる。
おわりに
次回はテストの7原則を中心に取り上げていく。
(この内容も自分が勉強していた時から内容が少し変わっていたりする)
Discussion