JSTQBFL1章のまとめ
はじめに
3章5章に引き続き１章を読んでみました。シラバスの内容について「これ大事だな」と思うもの独断と偏見で記述し、「特に大事だな」と思うものboldにしています。また筆者独自の認識を記載しています。
JSTQBFL5章テストマネジメントでの学び - 徒然なるままに
JSTQB FLのシラバス第3章:静的テストでの学び - 徒然なるままに
シラバス内容抽出/解釈
テストの基礎
テストとは何か?
ソフトウェアテストはソフトウェアの品質を評価し、運用環境でソフトウェアの故障が発生するリスクを低減する1つの手段である。
よくある誤解
- テストはソフトウェアを実行し結果を確認するだけだというもの。
- テストプロセスとして、計画、分析、設計、実装、進捗と結果の報告、対象の品質評価などの作業が含まれる。
- テストは要件、ユーザーストーリー、またはその他の仕様の検証に重点を置くことが全てだというもの。
- 検証だけでなく、ユーザーやステークホルダーのニーズを運用環境でシステムが満たしていることを確認する妥当性確認も行う。
テストに共通する目的
- 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価することによって欠陥を防ぐ。
- 明確にしたすべての要件を満たしていることを検証する。
- テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする。
- テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
- 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する。
- ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。
- 契約上、法律上、または規制上の要件や標準を遵守する、そして/またはテスト対象がそのような要件や標準に準拠していることを検証する。
テスト対象のコンポーネント、システム、テストレベル、ソフトウェア開発ライフサイクルモデルといった要因により異なり、テストの目的が追加変更されることもある
テストとデバッグ
- テスト
- 実行することでソフトウェアに存在する欠陥に起因する故障を示す。
- デバッグ
- 故障の基となる欠陥を見つけて、解析し、取り除く一連の開発の活動。
テストとデバッグは異なる。通常、テスト担当者はテスト対象の初回のテストと最終的な確認テストに責任を持ち、開発担当者はデバッグ、関連するコンポーネントテスト、およびコンポーネント統合テスト(継続的インテグレーション)に責任を持つことになる。
テストの必要性
コンポーネントやシステム、およびドキュメントを厳しくテストすれば、運用環境で問題が発生するリスクを低減できる。
→稼働後に修正することはコストが高くなってしまう。
成功に対するテストの貢献
適切なテストレベル、適切なテストの専門知識の適用、適切なテスト技法を使用することで問題を含むリリースの頻度を低減できる。以下がその例の抜粋。
- テスト担当者が要件レビューやユーザーストーリーの洗練作業に関与することにより、これらの作業成果物の欠陥を検出できる。
- 要件に対する欠陥の検出と除去を行うことにより正しくない、またはテストできないフィーチャーが開発されるリスクを低減できる。
- コード開発時にテスト担当者が開発担当者と密接に連携して作業することにより、両者がコードとそのコードをどうテストするかに対する理解を深めることができる
- コードとテストケースに欠陥が混入するリスクを低減できる。
品質保証とテスト
品質保証(または単にQA)とテストは、関連してはいるが同じではない。さらに大きな範囲を表す品質マネジメントという概念 が両者を結び付けている。
- 品質マネジメント
- 品質保証
- 一般的に、品質が適切なレベルに確実に到達するよう、適切なプロセスを遵守することに重点を置く。プロセスを適切に遂行すると、これらのプロセスで作成される作業成果物は一般的に高い品質を持つ。これにより、欠陥の混入を防止できる。
- 品質保証の有効性を高めるためには、根本原因分析を使用して欠陥の原因の検出と除去を行い、プロセスを改善するために振り返りでの発見事項を適切に利用することが重要。
- 品質コントロール
- テスト活動を含め、適切なレベルの品質を達成するために役立つさまざまな活動が含まれる。テスト活動は、ソフトウェア開発またはメンテナンスプロセス全体の一部を構成する。
- 品質保証では、テストを含むプロセス全体を適切に実行することが必要となるため、適切なテストを支援する。テストはさまざまな方法で品質の達成に貢献する。
※以下のイメージ図(雑)のように捉えている。
エラー、欠陥、および故障
人間はエラー(誤り)を犯す。そのエラーがソースコードや他の関連する作業成果物の欠陥(フォールトまたはバグ)となる。 コードの欠陥が実行されると、故障が起きることがあるが、すべての状況で故障が起きるわけではない。
エラーは以下のものを含むさまざまな理由によって発生する。※属性を付けた。
- 納期のプレッシャー
- 組織的要因
- 人間の誤りを犯しやすい性質
- 人的要因
- プロジェクト参加者の経験不足または技術不足
- 人的要因、組織的要因
- プロジェクト参加者間の誤ったコミュニケーション
- 人的要因、組織的要因
- コードの複雑さ、設計の複雑さ、アーキテクチャーの複雑さ、解決すべき根本的な問題の複雑さ、使用する技術の複雑さ
- 技術的要因
- システム内またはシステム間のインターフェースに関する誤解
- 人的要因
- 新しく不慣れな技術
- 技術的要因
期待通りではないテスト結果がすべて故障であるとは限らない。テスト実行方法のエラー、テストデータやテスト環境、その他のテストウェアの欠陥などの理由により、偽陽性(誤検出)をしてしまうことがある。状況によっては、類似のエラーまたは欠陥が偽陰性(検出もれ)となることもある。
欠陥、根本原因、および影響
欠陥の根本原因とは、欠陥を埋め込んだ最初の行為または条件のことである。欠陥を分析して根本原因を識別し、類似の欠陥が今後発生しないようにしなければならない。最も重大な根本原因に焦点をあてることはプロセス改善につながり、今後に大量の欠陥が作りこまれるのを防止できる。
テストの7原則
- 1.テストは欠陥があることは示せるが、欠陥がないことは示せない
- 2.全数テストは不可能
- 3.早期テストで時間とコストを節約
- 4.欠陥の偏在
- 5.殺虫剤のパラドックスにご用心
- 6.テストは状況次第
- 7.「バグゼロ」の落とし穴
テストプロセス
テストプロセスとは、テストの目的を達成する確率を高くする、汎用的なテスト活動のセット。
テストの活動とタスクと作業青果物
テストプロセスを構成する主な活動のグループは以下の通りである。論理的にはシーケンシャルに行われるが、繰り返されることが多い。
- テスト計画
- テストの目的と、状況により課せられる制約内でテストの目的を達成するためのアプローチを定義する。
- 例えば、適切なテスト技法とタスクを指定し、納期に間に合うようにテストスケジュールを作成するなど。
- 作業成果物の例
- テスト計画書
- テストのモニタリングとコントロールで使用する終了基準
- テストのモニタリングとコントロール
- テストモニタリング
- テスト活動に関する情報を収集して可視化し、フィードバックをかけること
- テストコントロール
- 収集、報告されたテストの実施結果を基にガイドや補正のアクションをすることである。
- 例えばテストの優先度を見直すことやテストスケジュールを変更するなど。
- 成果物の例
- テスト進捗レポート
- テストサマリーレポート
- テストモニタリング
- テスト分析
- テスト設計
- テスト分析は「何をテストするか」を決定し、テスト設計は「それをどうテストするか」を決定する。
- タスクの例
- テストケースおよびテストケースのセットを設計し、優先度を割り当てる。
- テスト条件とテストケースを支援するために必要なテストデータを識別する。
- テスト環境を設計し、必要なインフラストラクチャーやツールを識別する。
- 作業成果物の例
- テスト分析で決定したテスト条件を実行するためのテストケースとテストケースのセット
- テスト実装
- テスト実行
- テスト実行スケジュールに従ってテストスイートを実行する。
- タスクの例
- テストアイテムまたはテスト対象、テストツール、テストウェアのIDとバージョンを記録する。
- 故障を観察し、観察に基づいて欠陥を報告する
- 作業成果物の例
- テストケースまたはテスト手順のステータスに関するドキュメント
- 欠陥レポート
- テスト完了
- 完了したテストの全活動のデータを集め、プロジェクトから得たこと、テストウェア、およびその他の関連する情報すべてをまとめる。
- タスクの例
- すべての欠陥レポートがクローズしていることを確認する。または、テスト実行の終了時に未解決として残されている欠陥について変更要求またはプロダクトバックログアイテムを作成する。
- 完了したテストの全活動のデータを集め、プロジェクトから得たこと、テストウェア、およびその他の関連する情報すべてをまとめる。
- テストサマリーレポートを作成して、ステークホルダーに提出する。
- 作業成果物の例
テストベースとテスト作業成果物との間のトレーサビリティ
- トレーサビリティ
- テストベースの各要素とそれに関連するテスト作業成果物の紐付け。テスト作業成果物が何を根拠にどの様に作られたかを判別するもの。
テストカバレッジの評価に加えて、優れたトレーサビリティが役に立つことは以下の通りである。
- 変更の影響度を分析する。
- テストを監査可能にする。
- テストベースの要素のステータス(例えば、テストが合格となった要件、テストが不合格となった要件、テストを保留している要件)を含めることで、テスト進捗レポートとテストサマリーレポートの理解しやすさを向上する。
テストの心理学
ソフトウェア開発は、ソフトウェアテストを含めて人が行うため、人の心理がソフトウェアテストに重要な影響を及ぼす。
人の心理とテスト
欠陥や故障を見つけることはプロダクトおよび開発担当者に対する非難と解釈されることがある。 確証バイアスと呼ばれる人の心理の要素は、持っている信念に合わない情報を受け入れがたくする。例えば、開発担当者は、コードは正しいという思い込みがあるので、確証バイアスにより、コードが正しくないということを受け入れがたい。 さらに、テストからの情報は悪いニュースを含んでいることが多く、悪いニュースをもたらす人は非難される傾向がある。
テストはプロジェクトの進捗とプロダクトの品質に大きく貢献するが、これらの心理的要因により、破壊的な活動と見られる場合がある。これらの心理的傾向を軽減するためには、欠陥や故障に関する情報を建設的な方法で伝えるべきである。テスト担当者およびテストマネージャーは、欠陥、故障、テスト結果、テストの進捗、リスクの情報を効果的に伝えることができ、建設的な関係を構築するための優れた対人スキルが必要となる。コミュニケーションを適切に行う方法には以下のものがある。
- 対決ではなく、協調姿勢で開始する。全員のゴールは、高品質のシステムであることを再認識するとよい。
- テストの利点を強調する。例えば、開発担当者に対しては、欠陥情報は、作業成果物の品質向上と開発担当者のスキル向上に役立つ。組織に対しては、欠陥をテストで検出して修正すると、時間と経費の節約になり、プロダクト品質の全体的なリスクも減る。
- テスト結果や他の発見事項は、中立な立場で、事実に焦点をあてて伝え、欠陥を作りこんだ担当者を非難しないようにする。客観的かつ事実に基づいた欠陥レポートを書いたり、発見事項をレビューしたりする。
テスト担当者も個人的偏見を最小限にして、これらの目的に忠実であることが重要である。
テスト担当者と開発担当者のマインドセット
- 開発担当者
- 主目的：プロダクトを設計して構築すること。
- マインドセット：解決策に問題があるかを考えるよりも、解決策の設計と構築により大きな関心がある。また、確証バイアスが、自分自身の犯したエラーに気づくことを困難にする。
- テスト担当者
感想
○○テストやテスト○○って単語が多く、この意味何だっけ？となってしまっています。テストオラクルとかテストハーネスあたりが特によくわからなくなってます。試験までに覚えなきゃ...
テストプロセスを意識することで、「自分が今これをするためには何が必要なんだっけ？」と明確になった気がします。いきなりテストを実装するのではなく、設計や分析といった作業が必要で、その作業は何をすべきかがわかるので。
開発する方から見ると、確証バイアスはかかりがちだなって改めて思います。そして間違ってると指摘されると嫌な気分になるのもわかりますね。開発担当者も確証バイアスがかかりやすくなることは知っておくべきですね。
