JSTQBFL5章 まとめ
JSTQB FL5章を読みました。
シラバスの文章が長いので引用して大事だと思うところを太字にしてまとめてみます。
🐰JSTQBFL1章 まとめ
🐱JSTQBFL2章 まとめ
🦊JSTQBFL3章 まとめ
🐶JSTQBFL4章 まとめ
🐧JSTQBFL5章 まとめ
🐷JSTQBFL6章 まとめ
■シラバス内容抽出/解釈
✔ テストマネジメント
■ 独立したテスト
テストタスクは、
・テストに特化した役割を持つ人たち
または
・別の役割を持つ人たち（例えば、顧客）
が行う場合がある。
ある程度の独立性を確立すると、開発者とテスト担当者の間の認知バイアスの違いによって、テスト担当者はより効果的に欠陥を発見できる。
ただし、独立性は熟知していることの代わりにはならない。
開発担当者は自分のコードにある多くの欠陥を効率的に検出できる。
テストにおける独立性の度合いを以下に示す（独立性の低いレベルから高いレベルの順に列挙）。
独立したテスト担当者不在
※開発担当者が自分のコードをテストするのみ開発チーム、またはプロジェクトチーム内に所属する、独立した開発担当者、またはテスト担当者
※開発担当者が同僚の成果物をテストすることもある組織内にある独立したテストチームまたはグループで、プロジェクトマネージャーや上位管理者の直属組織
顧客またはユーザーコミュニティから派遣された独立したテスト担当者、または、使用性、セキュリティ、性能、規制/標準適合性、移植性など、ある特定のテストタイプを専門に行う独立し たテスト担当者。
組織外の独立したテスト担当者。オンサイト（インハウス）またはオフサイト（アウトソーシン グ）で作業する。
！）下から順に独立性が高い↑
📝オンサイト（インハウス）
「現地」「現場」
📝オフサイト（アウトソーシング）
「現地から離れた場所」「遠隔地」
独立したテストの利点を以下に示す。
独立したテスト担当者は、開発担当者とは異なる背景、技術的視点、バイアスを持つため、開発 担当者とは異なる種類の故障を検出する可能性が高い。
独立したテスト担当者は、ステークホルダーが行った仮定について、検証、説明の要求、または 反証を仕様作成時および実装時に行うことができる。
ベンダーの独立したテスト担当者は、契約元の会社にある（政治的な）圧力なしに、テスト中の システムについて正直に客観的な態度で報告できる。
独立したテストの欠点を以下に示す。
開発チームから隔絶されると、協力関係の欠落、開発チームへのフィードバック提供の遅延、開発チームとの対立を招くことがある。
開発担当者の品質に対する責任感が薄れることがある。
独立したテスト担当者は、ボトルネックとして見られることがある。
独立したテスト担当者にテスト対象の情報などの重要な情報が伝わらないことがある。
📝ボトルネック
業務の停滞や生産性の低下といった悪影響を与えている工程・箇所のことを指す
✔ テストマネージャーとテスト担当者のタスク
テストマネージャーのタスク：
テストプロセスに対して全体的な責任を持ち、テスト活動においてリーダーシップを適切に発揮すること
テストマネジメントの役割：
プロのテストマネージャー や、プロジェクトマネージャー、開発マネージャー、品質保証マネージャーなどが担う
大きなプロジェクトや組織では、複数のテストチームが 1人のテストマネージャー、テストコーチ、またはテストコーディネーターの下で作業し、各チームはテストリーダーまたはテスト担当者のリード役が率いることがある。
【マネージャー】
テストマネージャーの典型的なタスクは以下の通りである。
組織のテストポリシーやテスト戦略を開発もしくはレビューする。
プロジェクトの背景を考慮した上で、テスト目的とリスクを理解してテスト活動を計画する。
※これにはテストアプローチの選択、テストにかかる時間/工数/コストの見積り、リソースの獲得、 テストレベルやテストサイクルの定義、欠陥マネジメントの計画を含む。テスト計画書を作成し更新する。
プロジェクトマネージャー、プロダクトオーナーなどの間でテスト計画書の内容を調整する。
テスト側の考え方を、統合計画などの他のプロジェクト活動と共有する。
テストの分析、設計、実装、実行の開始を宣言し、テスト進捗とテスト結果をモニタリングし、 終了基準（または完了（done）の定義）のステータスを確認し、そしてテスト完了活動をファシリテートする。
テスト進捗レポートとテストサマリーレポートを、収集した情報に基づいて準備し配布する。
（テスト進捗レポートおよび/またはプロジェクトで既に完了しているテストのテストサマリー レポートで報告済みの）テスト結果やテスト進捗に基づいて計画を修正し、テストコントロール のために必要なあらゆる対策を講じる。
欠陥マネジメントシステムのセットアップと、テストウェアの適切な構成管理を支援する。
テスト進捗の計測、およびテストや対象プロダクトの品質の評価のために、適切なメトリクスを導入する。
テストプロセスで使うツールの選択と実装を支援する。
※これには、ツール選択（および、購入および/またはサポート）のための予算の提案、パイロットプロジェクトのための時間と工数の割 り当て、継続的なツール使用支援の提供を含む。構築するテスト環境を決定する。
組織内のテスト担当者、テストチーム、テスト専門職を昇格および支持する。
テスト担当者のスキルアップとキャリアアップを促す（トレーニング計画、業績評価、コーチン グなどを使用）。
※アジャイル開発では、前述のタスクのいくつかはアジャイルチームが行う。特にチーム内で行われる日々のテストに関連するタスクは、チーム内のテスト担当者が行うのが一般的である。
※複数のチームや組織全体にまたがるタスクや、人事に関連するタスクは、開発チーム外のテストマネージャーが行うことが多い。
このようなテストマネージャーはテストコーチとも呼ばれる。
【テスト担当者】
テスト担当者の典型的なタスクは以下の通りである。
テスト計画書のレビューによって貢献する。
試験性のために、要件、ユーザーストーリーと受け入れ基準、仕様、モデル（すなわち、テスト ベース）を分析し、レビューし、評価する。
テスト条件を識別して文書化し、テストケース、テスト条件、テストベースの間のトレーサビリティを確立する。
テスト環境（システムアドミニストレーションやネットワークマネジメントと協調する場合が多い）を設計、セットアップし、検証する。
テストケースとテスト手順を設計し実装する。
テストデータを作成、および入手する。
詳細なテスト実行スケジュールを作成する。
テストケースを実行し、結果を評価して、期待結果からの逸脱を文書化する。
適切なツールを使用して、テストプロセスを円滑にする。
必要に応じてテストを自動化する（開発担当者や、テスト自動化の専門家の支援が必要な場合が ある）。
性能効率性、信頼性、使用性、セキュリティ、互換性、移植性などの非機能特性を評価する。
他の人が開発したテストケースをレビューする。
📝シラバスでよく目にする「トレーサビリティを確立する」とは？
テスト担当者のタスクにも「テスト条件を識別して文書化し、テストケース、テスト条件、テストベースの間のトレーサビリティを確立する。」とある。
つまり、「テスト条件を識別して文書化し、テストケース、テスト条件、テストベースの関連性等を後から見ても分かるように（追跡できるよう）にする。」ということだと自分なりに解釈‥🤔
テスト分析、テスト設計、特定のテストタイプ、テストの自動化は、各分野のスペシャリストが担うこ とがある。
・コンポーネントテストレベル
・コンポーネント統合テストレベル：
⇒ 開発担当者がテストを担当することが一般的
・受け入れテスト：
⇒ ビジネスアナリスト、特定の分野の専門家、ユーザーがテストを担当することが一般的
・システムテストレベルやシステム統合テストレベル：
⇒ 独立したテストチームがテストを担当することが一般的
・運用受け入れテスト
⇒ 運用担当者 および/またはシステムアドミニストレーターがテストを担当することが一般的
✔ テストの計画と見積り
プロジェクトやテスト計画が進行するに従い、入手できる情報が多くなり、具体的な情報をテスト計画 書に含めることができる。
テスト計画は継続する活動であり、プロダクトのライフサイクル全体を通し て行う（プロダクトのライフサイクルはプロジェクトの範囲を超えて、メンテナンスフェーズまで延長されることに注意する）。
計画作業は、
・マスターテスト計画書
・テストレベル（システムテストや受け入れテストなど）
・テストタイプ（使用性テストや性能テストなど）
ごとの個別テスト計画書として文書化できる。
📝各計画書の概要
・マスタテスト計画書・・・プロジェクト全体のテストの計画
・テストレベル毎のテスト計画書・・・テストレベル毎のテストの計画（システムテスト計画書、統合テスト計画書など）
・テストタイプ毎のテスト計画書・・・テストタイプ毎のテストの計画（セキュリティテスト計画書など）
※
マスターテスト計画においての開始基準：各テストレベルを開始していいかどうかの条件
レベルテスト計画においての開始基準：テスト実行を開始していいかどうかの条件
テスト計画に含まれる活動には以下があり、そのいくつかはテスト計画書として文書化する場合がある。
テストの範囲、目的、リスクを決定する。
テストに対する包括的なアプローチを定義する。
テスト活動をソフトウェアライフサイクルでの活動に統合し、協調させる。
何をテストするか、さまざまなテスト活動でどのような人的リソースとその他のリソースが必要であるか、どのようにテスト活動を進めるかを決める。
テスト分析、設計、実装、実行、評価の活動を、特定の日付（例えば、シーケンシャル開発）または各イテレーションの状況（例えば、イテレーティブ開発）でスケジューリングする。
テストのモニタリングとコントロールのためのメトリクスを選ぶ。
テスト活動の予算を決定する。
テストドキュメントの詳細レベルと構造を決定する（例えば、テンプレートやサンプルドキュメントを提供する）。
✔ テスト戦略とテストアプローチ
テスト戦略の一般的な種類は以下の通りである。
■ 分析的：
いくつかの要因（要件やリスクなど）の分析に基づく。
ex) リスクのレベルに基づいてテストを設計し優先度付けするリスクベースドテストがある。
■ モデルベースド：
プロダクトで必要な特性を表すモデル、例えば、機能、ビジネスプロセス、内部構造、非機能特性（信頼性など）などに基づいて、テストを設計する。
ex) ビジネスプロセスモデル、状態モデル、信頼度成長モデルなどがある。
■ 系統的：
事前に定義した一連のテストケースまたはテスト条件を体系的に使用する。
テストケースまたはテスト条件には、一般的または可能性の高い故障を体系的に分類したリスト、重要な品質特性のリスト、モバイルアプリケーションや Webページに対する企業全体のルックアンドフィール標準などがある。
📝ルックアンドフィール
ソフトウェアの表示や操作が利用者に与える印象の総体
特に、画像や図形による表示と位置指定による操作を多用するグラフィカルユーザーインターフェース （GUI）における使用感のこと
■ プロセス準拠（または標準準拠）
外部のルールや標準を使用してテストの分析、設計、実装を 行う。
使用する外部のルールや標準には、業界固有の標準、プロセスドキュメント、テストベー スの厳密な識別や使用、組織によって課せられるプロセスや標準などがある。
■ 指導ベース（コンサルテーションベース）：
テストチームの外部または組織自体の外部のステークホルダー、ビジネスドメインの専門家、技術的専門家からの助言、ガイダンス、指示に基づいてテストを行う。
■ リグレッション回避：
既存では実現されていた能力のリグレッションを避けることを目的とする。このテスト戦略には、既存のテストウェア（特にテストケースやテストデータ）、高度に自動化されたリグレッションテスト、および標準テストスイートの再利用が含まれる。
■ 対処的：
テスト対象のコンポーネントやシステム、テスト実行時に発生するイベントに対して対処的にテストを行う。
他の戦略とは異なり、テストは事前に計画されない。先に実行したテスト の結果により得られた知識に応じて、テストを設計および実装し、多くの場合、即座に実行する。
ex) 探索的テストを一般的に使用する。
✔ 開始基準と終了基準（準備完了（ready）の定義と完了（done）の定義）
ソフトウェアおよびテストの品質を効果的にコントロールするために、特定のテスト活動をいつ開始し、いつ完了するかを定義する基準を設ける。
開始基準（アジャイル開発では、準備完了 （ready）の定義と呼ぶ）は、
特定のテスト活動を開始するための事前条件を定義する。
⇒開始基準が満たされないままにテスト活動を開始すると、難易度が上がり、要する時間が増え、コストがかかり、リスクが高まる。
終了基準（アジャイル開発では、完了（done）の定義と呼ぶ）は、テストレベルまたは一連のテストの完了を宣言するために達成すべき条件を定義する。
開始基準と終了基準は、テスト目的に応じて、テストレベルごと、およびテストタイプごとに定義する。
典型的な開始基準を以下に示す。
テスト可能な要件、ユーザーストーリー、そして/またはモデル（モデルベースドテスト戦略に従う場合）が準備できている。
前のテストレベルで終了基準を満たしたテストアイテムが準備できている。
テスト環境が準備できている。
必要なテストツールが準備できている。
テストデータや他の必要なリソースが準備できている。
典型的な終了基準を以下に示す。
計画したテスト実行が完了している。
定義済みのカバレッジ（要件、ユーザーストーリー、受け入れ基準、リスク、コード）を達成している。
未解決の欠陥の件数は合意された制限内である。
残存欠陥の想定数が十分に少ない。
信頼性、性能効率性、使用性、セキュリティ、他の関連する品質特性を十分に評価している。
※終了基準を満たしていない場合でも、消費済みの予算、費やした時間、そして/またはプロダクトを市場に送り出すプレッシャーにより、テスト活動を切り上げることが一般的に行われる。プロジェクトステ ークホルダーやビジネスオーナーが、テストの追加なしでプロダクトをリリースするリスクを見直しして受け入れた場合には、このような状況でもテストを終了できる。
✔ テスト実行スケジュール
テストケースやテスト手順を作成し、テストスイートにまとめた後、テスト実行スケジュールを作成してテストを実行する順序を定義する。
テストケースの実行順序は優先度レベルに基づくことが理想的であり、最も高い優先度を持つテストケースを最初に実行するのが一般的である。
ただし、テストケースまたはテスト対象の機能に依存関係がある場合はこの限りではない。高い優先度を持つテストケースがそれより低い優先度を持つテストケー スに依存している場合、低い優先度を持つテストケースを先に実行する。同様に、テストケース間に依存関係がある場合は、相対的な優先度にとらわれずに、適切な順序で実行する。
✔ テスト工数に影響する要因
テスト工数の見積りでは、特定のプロジェクト、リリース、イテレーションのテスト目的を達成するた めに必要な作業工数を予測する。
テスト工数に影響する要因には、以下に示すプロダクトの特性、開発プロセスの特性、人の特性、テスト結果などが挙げられる。
■ プロダクトの特性
プロダクトに関連するリスク
テストベースの品質
プロダクトの規模
プロダクトドメインの複雑度
品質特性の要件（例えば、セキュリティ、信頼性）
テストドキュメントの詳細度に関する要求レベル
法規制への適合性の要件
■ 開発プロセスの特性
組織の安定度合いと成熟度合い
使用している開発モデル
テストアプローチ
使用するツール
テストプロセス
納期のプレッシャー
■ 人の特性
参加メンバーのスキルや経験、特にドメイン知識のような類似プロジェクトやプロダクトのスキルや経験
チームのまとまりとリーダーシップ
■ テスト結果
検出した欠陥の数と重要度
必要な再作業の量
✔ テスト見積りの技術
テストを適切に実行するために必要な工数は、さまざまな技術を使用して見積ることができる。
最も一般的に使用する2つの技術を以下に示す。
メトリクスを活用する：
以前の類似したプロジェクトのメトリクスや、典型的な値を基にしてテ スト工数を見積る。専門家の知識を基にする：
テストのタスクの所有者の経験、または専門家による見積りを基にし てテスト工数を見積る。
【アジャイル開発の例】
メトリクスを活用 - バーンダウンチャート
⇒残作業量を把握、報告し、チームが次のイテ レーションで完了できる作業量を決定するベロシティへのインプットとなる
📝ベロシティ
チームが作業を進める速度、作業量のこと
専門家の知識を基にする - プランニングポーカー
⇒フィーチャーをリリースするため に必要な工数をチームメンバー自身の経験に基づいて見積る
※参考 : Slideshare「プランニングポーカーでアジャイルな見積もりがいい！」
【シーケンシャル開発プロジェクトの例】
メトリクスを活用 - 欠陥除去モデル
⇒欠陥の量、およびその欠陥を除去するためにかけた時間を、類似の特性を持つ将来のプロジェクトを見積る際のベースとする。
専門家の知識を基にする - ワイドバンドデルファイ見積り技法
⇒専門家のグループが彼らの経験に基づいて見積りを行う。
✔ テストのモニタリングとコントロール
【テストモニタリングの目的】
テスト活動に関する情報を収集して可視化し、フィードバックをかけることである。
モニタリングする情報は、手動あるいは自動で収集し、テスト進捗を評価するために使う。また、テストの終了基準やアジャイルプロジェクトの完了（done）の定義に関連するテストのタスクで、プロダクトリスク、要件、受け入れ基準のカバレッジのターゲットを満たすかを計測するために 使う。
【テストコントロールとは】
収集、報告されたテストの実施結果を基にガイドや補正のアクションをすることである。補正のアクションは、あらゆるテスト活動をカバーし、他のソフトウェアライフサイクルの活動に影響を与える。
テストコントロールの作業には、例えば以下のものがある。
識別したリスクが現実になった場合（例えば、リリース遅延）、テストの優先度を見直す。
テスト環境や他のリソースの利用可否により、テストスケジュールを変更する。
再作業が発生した場合に、テストアイテムが開始基準と終了基準を満たすかを再評価する。
✔ テストで使用するメトリクス
メトリクスは各テスト活動の期間中、および終了時に収集できる、以下の項目を評価する。
計画したスケジュールや予算に対する進捗
テスト対象の現在の品質
テストアプローチの十分性
テスト目的に対するテスト活動の効果
代表的なテストメトリクスには以下のものがある。
計画したテストケースの準備が完了した割合（または、計画したテストケースを実装した割合）
計画したテスト環境の準備が完了した割合
テストケースの実行（例えば、実行/未実行のテストケース数、合格/不合格のテストケース数、 そして/または合格/不合格のテスト条件数）
欠陥情報（例えば、欠陥密度、検出および修正した欠陥数、故障率、確認テスト結果）
要件、ユーザーストーリー、受け入れ基準、リスク、コードのテストカバレッジ
タスクの完了、リソースの割り当てと稼働状況、工数
テストに費やすコスト（現状のコストと、継続して欠陥を見つけていくメリットと比較した場合 のコスト、もしくは継続してテストを実行していくメリットと比較した場合のコストなど）
✔ テストレポートの目的、内容、読み手
テストレポートの目的は、例えばテストレベルなどのテスト活動の期間中と終了時の両方の時点でテスト活動に関する情報を要約し周知することである。
テスト活動の期間中に作成するテストレポートはテスト進捗レポートと呼び、テスト活動の終了時に作成するテストレポートはテストサマリーレポートと ことが多い。
！）テストのモニタリングとコントロールでは、テストマネージャーはステークホルダー向けに定期的にテスト進捗レポートを発行する。
典型的なテスト進捗レポートは以下を含む。
テスト活動の状況とテスト計画書に対する進捗
進捗を妨げている要因
次のレポートまでの間に計画されているテスト
テスト対象の品質
典型的なテストサマリーレポートに含まれるものは以下の通り。
行ったテストの要約
テスト期間中に発生したこと
計画からの逸脱（テスト活動のスケジュール、期間もしくは工数など）
終了基準または完了（done）の定義に対するテストとプロダクト品質の状況
進捗を妨げた、または引き続き妨げている要因
欠陥、テストケース、テストカバレッジ、活動進捗、リソース消費のメトリクス
残存リスク
再利用可能なテスト作業成果物
テストレポートの内容は、プロジェクト、組織の要件、ソフトウェア開発ライフサイクルによって異なる。
アジャイル開発では、テスト進捗レポートをタスクボード、欠陥サマリー、バーンダウンチャートに組み込んで、日々のスタンドアップミーティングで討議することがある。
📝スタンドアップミーティング
作戦会議のような短い会議のこと。デイリーミーティング。朝会、夕会のようなもの。
テストレポートの内容は、プロジェクトの状況に応じて、さらにはレポートの読み手に応じてテーラリングする。
記述する情報の種類と量は、技術に精通した読み手またはテストチームを対象にする場合と経営者向けのサマリーレポートでは異なる。
技術に精通した読み手またはテストチーム向け
➡ 欠陥の種類と傾向に関する詳細な情報が重要
経営者向け
➡ ハイレベルのレポート（例えば、優先度ごとの欠陥、予算、スケジュール、合格/不合格/テスト未実行のテスト条件などのステータスサマリー）が適切
📝テーラリング
業務プロセス やシステム開発プロセスなどについて、規格や全社的な標準などを元に、個別の部署やプロジェクトに合った具体的な標準を策定すること
✔ 構成管理
構成管理は、欠陥のある部品がプロダクトに入り込まないように、マネジメントするための仕組み
【構成管理の目的】
プロジェクトやプロダクトのライフサイクルを通じて、コンポーネントやシステムの完全性、テストウェア、およびそれら相互の関係を確立し、維持する
テストを適切に支援するために、構成管理では、以下を明確にする。
全テストアイテムを一意に識別して、バージョンコントロールを行い、変更履歴を残し、各アイテム間を関連付ける。
テストウェアの全アイテムを一意に識別して、バージョンコントロールを行い、変更履歴を残し、各アイテム間を関連付ける。また、テストアイテムのバージョンとの関連付けを行い、テストプロセスを通してトレーサビリティを維持できる。
識別したすべてのドキュメントやソフトウェアアイテムは、テストドキュメントに明確に記載してある。
テスト計画にて構成管理の手順やインフラストラクチャー（ツール）を識別し、実装すべきである。
✔ リスクとテスト
【リスクとは】
将来に否定的な結果となる事象が起きる恐れを含むもの。
リスクのレベルは、そのような事象が起きる可能性とその影響（事象による結果がもたらす損害）で決まる。
✔ プロダクトリスクとプロジェクトリスク
■ プロダクトリスク
プロダクトリスクは、作業成果物（例えば、仕様、コンポーネント、システム、テストケース）がユーザー、および/またはステークホルダーの正当なニーズを満たすことができない恐れを含む。
プロダクトの特定の品質特性（例えば、機能適合性、信頼性、性能効率性、使用性、セキュリティ、互換性、保守性、移植性）に関連するプロダクトリスクは、品質リスクとも呼ばれる。
プロダクトリスクの例には以下のものが含まれる。
※リスクベースのアプローチが有効
ソフトウェアの意図されている機能が仕様通りには動かないかもしれない。
ソフトウェアの意図されている機能がユーザー、顧客、および/またはステークホルダーのニーズ通りには動かないかもしれない。
システムアーキテクチャーが非機能要件を十分にサポートしないことがある。
特定の計算結果が状況によって正しくないことがある。
ループ制御構造が正しくコーディングされていないことがある。
高性能トランザクション処理システムで応答時間が適切でないことがある。
ユーザーエクスペリエンス（UX）のフィードバックがプロダクトの期待と異なるかもしれない。
【プロジェクトリスク】
プロジェクトリスクは、発生した場合にプロジェクトの目的達成に悪影響を与える。
プロジェクトリスクの例には以下のものが含まれる。
プロジェクトの懸念事項：
リリース、タスク完了、終了基準または完了（done）の定義の達成が遅延することがある。
不正確な見積り、優先度の高いプロジェクトへの資金の再割り当て、組織全体での経費節減により資金が不足することがある。
プロジェクト終盤での変更により作業の大規模なやり直しが必要な場合がある。
組織の懸念事項：
人員不足、および人員のスキルやトレーニング不足の場合がある。
人間関係によって、衝突や問題が発生することがある。
ビジネス上の優先度の競合によってユーザー、ビジネススタッフ、特定の分野の専門家の都合がつかないことがある。
政治的な懸念事項：
テスト担当者が自分たちのニーズおよび/またはテスト結果の十分性を上手く伝えられないことがある。
開発担当者および/またはテスト担当者がテストやレビューで見つかった事項を上手くフォローアップできないことがある（例えば、開発、およびテストが改善しない）。
テストから期待できるものを正しく評価しようとしないことがある（例えば、テストで見つかった 欠陥の情報を真摯に受け止めようとしない）。
技術的な懸念事項：
要件を十分に定義できないことがある。
制約があるために、要件を満たさないことがある。
テスト環境が予定した期限までに用意できないことがある。
データ変換および移行の計画、それらのツールによる支援が遅れることがある。
開発プロセスの弱点が、設計、コード、構成、テストデータ、テストケースなどのプロジェクトで の作業成果物間の整合性や品質に影響を与えることがある。
不適切な欠陥マネジメントおよび類似の問題によって、欠陥や他の技術的負債が累積することがある。
供給者側の懸念事項：
サードパーティが、必要なプロダクトまたはサービスを提供できない、もしくは撤退することがあ る。
契約上の懸念事項がプロジェクトの問題の原因となることがある。
✔ リスクベースドテストとプロダクト品質
テスト時に必要な工数についてどこに重点を置くかを決定するために、リスクを使用する。また、どのテストをいつから開始するかを決定し、さらなるテストが必要な領域を識別するために使用する。
その 一方、テストは、期待しない事象が発生するリスクを減らしたり、その影響を少なくしたりするために使用する。また、リスク軽減のための活動として使用し、識別したリスクや残存（未解決）リスクに関 する情報を提供する。
リスクベースのアプローチを採用すると、プロダクトリスクを軽減する予防的措置を講じられる。
このアプローチではリスク分析を行い、プロダクトリスクを識別し、各リスクの発生する可能性と発生した場合の影響を評価する。
リスクベースのアプローチでは、プロダクトリスク分析の結果を使用して以下を行う。
適用するテスト技法を決める
実施するテストレベルおよびテストタイプを決める（例えば、セキュリティテストやアクセシビリティテスト）。
テストを実行する範囲を決める
重大な欠陥をなるべく早い時期に検出するため、テストの優先順位を決める
テスト以外の活動でリスクを減らす方法があるか検討する（経験の少ない設計者に教育を実施するなど）
適用するテスト技法を決める
リスクの優先度が高い機能に対して、網羅率が高くなるようにテスト技法を選択する
実施するテストレベルおよびテストタイプを決める
修正作業のインパクトを考えて、テストレベルを決める (例えば、コンポーネントテストで見つけたほうが修正範囲に対して十分なテストができる。また、手戻りも少ないなど。)
テストを実行する範囲を決める
リスクの大きさに応じて、「ここも見ておいたほうがよいかも。」を決める
重大な欠陥をなるべく早い時期に検出するために、テストの優先順位を決める
クリティカルな欠陥を第一に検出できるようにテストを決める
テスト以外の活動でリスクを減らす方法があるか検討する
欠陥を作り込まないようなプロセスへ改善
開発者の適切なトレーニング
リスク分析により、リスクを洗い出すことが重要
リスク重要度に応じて、テストする/しないという判断が取れる
リスク重要度が高いものに対しては、十分なカバレッジが網羅できるようにテストアプローチを選択できる
リスクベースドテストでは、プロダクトリスクの分析を行うために、プロジェクトのステークホルダーの総合的な知識や洞察力を必要とする。
プロダクトが故障を起こす可能性を最小にするため、リスクマネジメントでは、以下のように、きちんと決まったアプローチを備えている必要がある。
どこが上手くいかないか（リスク）を分析する（定期的に再評価する）。
リスクの重要度を決める。
重大なリスクを処理する方法を実装する。
リスクが実際に事象として発生した場合に備えてコンティンジェンシープランを作る。
📝コンティンジェンシープラン
不測の事態が起こった時にできる限り迅速に通常業務に復旧させ、その被害を最小限に留めることを可能にするために、リスク発生時に企業や従業員が取るべき行動指針や事前対策を定めたもののこと
✔ 欠陥マネジメント
テストの目的の1つは欠陥を検出することであるため、テスト時に見つかった欠陥は記録を残す必要がある。
欠陥を記録する方法は、テスト対象のコンポーネントまたはシステム、テストレベル、ソフトウ ェア開発ライフサイクルモデルなどの要因により異なる。
検出したすべての欠陥を調査し、発見や分類 から解決にいたるまで追跡する必要がある（例えば、欠陥修正や解決策の確認テストでの合格、後続のリリースへ延期、永続的なプロダクト制約としての受け入れなど）。
すべての欠陥を解決にいたるまでマネジメントするために、組織で欠陥マネジメントのプロセスを定め、ワークフローと分類の規則を設ける必要がある。
このプロセスは、欠陥マネジメントに参加するすべての関係者（アーキテクト、設計者、開発担当者、テスト担当者、プロダクトオーナーなど）によって合意される必要がある。
効果的で効 率的な欠陥マネジメントプロセスのために、欠陥の属性、分類、ワークフローを定義する。
典型的な欠陥レポートには、以下のような目的がある。
開発担当者や他の関係者に対して、発生したあらゆる期待に反する事象についての情報を提供する。
また、必要に応じて、もしくは問題を解決するために、具体的な影響を識別して、最小の再現テストで問題の切り分けを行い、欠陥の修正ができるようにする。
テストマネージャーに対し、作業成果物の品質や、テストへの影響を追跡する手段を提供する （欠陥の報告数が多いと、テスト担当者は多くの時間をテスト実行ではなく報告作業に費やす必 要があり、さらに多くの確認テストが必要になる）。
開発プロセスとテストプロセスを改善するためのヒントを提供する。
★欠陥マネジメントの目的（要約）
開発担当者への情報提供
故障・不正に関する情報
(必要に応じ、問題の切り分けをした情報)
テストマネジメントのための情報提供
欠陥数や状態を把握し、テスト計画にフィードバックするため
開発プロセスとテストプロセスの改善するためのヒントを提供
欠陥の情報から開発プロセスやテストプロセスの改善につながる情報を提供する
■ 欠陥レポートの構成（要約）
欠陥の件名と概要
レポート作成日付、作成者
テストアイテム
欠陥を観察した開発ライフサイクルのフェーズ
ログ、データベースのダンプ、スクリーンショット (欠陥の再現手段)
期待結果と実際の結果
ステークホルダーに与えるインパクトの範囲や重要度
修正の緊急度/優先度
欠陥レポートのステータス
結論、アドバイス、承認
懸念事項
修正履歴
テストケースなどの参照情報
✔ 個人めも
「構成管理」がよくわかってないので内容を少し嚙み砕いて理解していきたい。
★テストウェアの構成管理
【目的】
再テスト(デバッグ後の確認テストやリグレッションテスト)で適切なテストケース・データを扱うため
間違えて古いテスト手順で確認テストをしたために、欠陥が直ったと勘違いし、リリースしてしまったとういことを防ぐための仕組み。
他にも…プロダクトを構成する部品のバージョンコントロールとトレーサビリティ確保を実施することで↓を防ぐ
間違ったバージョンのプロダクトの出荷
間違った欠陥の報告
ベースソフトウェアのバージョンを間違えて開発する
ソフトウェアに関わる情報を探し回る
★構成管理の手順
構成管理対象を決める(マスタテスト計画書作成時)
構成管理方法(進め方、使用するツール、担当者、規則)を決める
記録を残す(実際に構成管理を行うために、バージョン情報の記録を行う)
管理する (必要な時に参照できる状態にしておく)
7割理解！（？）
この記事が気に入ったらサポートをしてみませんか？