はじめに : JSTQB FLの学習内容・解釈・気づきを共有
JSTQB Foundation Level(シラバスVersion2018J03)について学習した内容と自分の解釈・気づきをまとめてブログで公開しています。JSTQB FLをシラバスや教科書で学習されている方は、不明点があるときに、本ブログの内容と照らし合わせて頂いて、理解の助けになればいいなと考えています。
(※このブログを全部を読むというよりは、学習中に分からないことがあったときに、覗いていただくという使い方が良いと思います。)
今回の内容 : 第5章.テストマネジメント
目次
テスト組織
テストの計画と見積り
テスト計画書の目的と内容
テスト戦略とテストアプローチ
開始基準と終了基準
テスト実行スケジュール
テスト工数に影響する要因
テスト見積りの技術
テストのモニタリングとコントロール
構成管理
リスクとテスト
リスクの定義
プロダクトリスクとプロジェクトリスク
リスクベースドテストとプロダクト品質
欠陥マネジメント
テスト組織
- テストの組織の形態
- テストの組織の利点と欠点
- 独立したテストを構成する技術者の役割
独立したテスト
- 独立したテスト
- 「テスト対象(テストレベル)に対して、テスト対象に対する独立性を考慮して、テスト担当者を最適に配置することにより、効率的に欠陥を見つけられる」という内容
-
テストの独立性と特徴について (独立性は昇順で高くなる)
- 独立したテスト担当者不在
- プロジェクトに所属する、独立した開発担当者またはテスト担当者
- 組織内にある、独立したテストチーム
- 顧客から派遣された独立したテスト担当者 または ある特定のテストタイプを専門に行うテスト担当者
- 組織外の独立したテスト担当者
-
独立したテストのメリット (要するに、第三者目線でテスト対象を検証できる)
- 開発担当者とは、異なる種類の故障を検出する可能性が高い(異なる背景、技術的視点、バイアスを持つため)
- 仕様に対する妥当性を確認でき、レビュー実施により早期に欠陥の検出ができる可能性が高い
-
独立したテストのデメリット (要するに、開発チームから隔離されてしまうことがある)
- 協力関係の欠落、フィードバックの遅延、開発チームとの対立を招くことがある
- ボトルネックと認識され、リリース遅延での責任を問われる可能性がある
- テスト対象の情報が伝達されない可能性があ
- ➡開発チームとテストチームの綿密な協調が必要
- 開発担当者の品質への責任感が薄れることがある
- ➡開発チームとテスト担当者がそれぞれの観点、役割でテスト行う必要があることを認識させることが必要
-
独立したテストチームの形態と対応するテストレベルによって、得られる効果は変化する
- つまり「独立したテストチームがテストやレビューを実施することで必ずしも、効率的に欠陥が見つけられる」というわけではない (例↓)
- 内部構造に対するテストでは、コードを熟知している開発者がテストをしたほうが、欠陥を効率よく検出できる可能性が高い。
- 要求に対するテストでは、独立したテストを実施したほうが、開発者が持っている先入観、心理的バイアス(特に確証バイアス)の影響をずにテストができる。
- つまり「独立したテストチームがテストやレビューを実施することで必ずしも、効率的に欠陥が見つけられる」というわけではない (例↓)
-
開発プロセスに対する独立テスト担当者の参加の仕方の違い
- 仕様書が都度がっちりできる開発プロセス（例えば、ウォーターフォール型）
- テスト担当者は、独立した組織のまま参加
- 仕様書をベースに専門の高いテストを実施
- テスト担当者は、独立した組織のまま参加
- 仕様書が必要最低限しかない開発プロセス (例えば、アジャイル開発)
- テスト担当者は、開発チームに参加
- テスト対象の情報を共有しながらテストを実施
- テスト担当者は、開発チームに参加
- 仕様書が都度がっちりできる開発プロセス（例えば、ウォーターフォール型）
テストマネージャーとテスト担当者のタスク
- テストマネージャー
- 組織のテストポリシー・テスト戦略を開発・レビュー
- テストの計画
- 各テスト活動の開始宣言
- テスト全体進捗と結果の管理
- テスト進捗レポートとテストサマリーレポート作成と共有
- テスト活動のコントロール
- 欠陥とテストウェアの管理
- テスト活動とプロダクトの品質評価のためのメトリクス導入
- テスト活動を行うためのインフラ整備
- テスト担当者の教育
- テスト担当者
- テスト計画書のレビュー貢献
- テストプロセスの実施
- ツールによりテストプロセスを円滑にする
- 必要に応じテストを自動化する
- 非機能特性を評価する
- ほかの人が開発したテストケースをレビューする
- 専門スキルを持った技術者が担当すべきこと
- テスト分析・テスト設計
- テストの自動化
- 特殊なテスト実行(セキュリティテストや性能テスト)
テストの計画と見積り
テスト計画書の目的と内容
テスト計画は、テストの目的を明確にし、様々な制約を考慮してこそテスト計画である(スケジュールは一部)
特に、納期から逆算したスケジュールだけを書くことが多いがそれは違う。
- テスト計画書の種類 : プロジェクト全体のテスト活動の計画 / 部分的なテスト活動の計画
- マスタテスト計画書・・・プロジェクト全体のテストの計画
- テストレベル毎のテスト計画書・・・テストレベル毎のテストの計画（システムテスト計画書、統合テスト計画書など）
- テストタイプ毎のテスト計画書・・・テストタイプ毎のテストの計画（セキュリティテスト計画書など）
- マスタテスト計画書・・・プロジェクト全体のテストの計画
テスト計画書の概要（ISO/IEC/IEEE 29119）
-
テスト計画書の内容の拡充 ： テスト計画書はプロジェクトを進めながら育てていくもの
- プロジェクトに関する情報が増えれば、テスト計画書の内容も具体化させる
- テスト実行により判明したリスクの変化を認識し、スケジュール調整を行う
-
テスト計画時に考慮すること : テスト計画を変化させる要因↓ (顧客要求期日だけで考えた計画は、実現できない計画になる可能性が高い)
- 組織のテストポリシーや組織のテスト戦略
- 使用する開発ライフサイクルや方法
- テストの範囲
- テストの目的
- リスク
- 制約
- 重要度、優先度
- テストの容易性
- 使用するリソース
-
テスト計画の活動
- テストは範囲を決める
- テスト目的を決める
- リスクの洗い出し
- テスト内容、必要なリソース、テスト活動の進め方を決める
- テスト活動（テスト分析～実行）のスケジュールを決める
- モニタリングとコントロールのために必要なメトリクスを選択する
- テストドキュメントの詳細と種類、構造の検討とテンプレート、サンプルの作成
- テスト活動の予算を決める
- ソフトウェアライフサイクル（獲得、提供、開発、運用、保守）での活動にテスト活動を統合し、協調させる
テスト戦略とテストアプローチ
汎用的にあるテスト戦略をプロジェクトの状態を加味して具体的なテストアプローチとして検討する
- テスト戦略 : テストプロセスの指針となる汎用的な考え方（これをプロジェクトにテーラリングしたものがテストアプローチ）
- 分析的戦略
- 要件やリスクなどの要因分析結果を活用してテスト設計を行う
- モデルベースド戦略
- ビジネスプロセスモデルや機能、内部構造、状態遷移モデル、信頼度成長モデルなどのモデルを基にテスト設計を行う
- 系統的戦略
- 既存のテストケースやテスト条件を基にテスト設計を行う
- チェックリストをベースにしたテスト設計、発生しやすい故障リストを用いたテスト設計
- 組織やプロダクトに関する重要な品質特性をベースにしたテスト設計
- プロセス準拠戦略
- 業界固有の標準や組織内の標準に基づいて、テストを実施する
- 指導ベース戦略（コンサルテーションベース戦略）
- 外部や顧客からの助言、指導、ガイダンスを基にテストを実施する
- リグレッション回避戦略
- リグレッションが発生しているかどうかを確認するテストを実施
- 既存のテストケースやデータを再利用する
- 対処的戦略
- 事前に計画しない
- テスト結果に対応してテストを実施する
- 探索的テスト
- 分析的戦略
- テストアプローチ : テスト戦略を実際にプロジェクトで使うために仕立てたもの
- プロジェクトの状況
- リスク
- 安全性
- 使用可能なリソース
- スキル
- 技術
- システムの性質 (例:カスタムメイドなのか、既製品なのか)
- テスト目的
- 法規制
開始基準と終了基準
テストの開始基準を決め、テストを行わないと、難易度が高くなり、テスト時間・コストが増え、リスクが高まる
テストの終了基準を以て、テストの終了を判断する(状況よりステークホルダーの了承をもって切り上げる)
- テストの開始基準 : 次の準備が完了していること
- テストベース
- テストアイテム
- テスト環境
- テストツール
- テストデータ
- その他のリソース
- テストの終了基準 : 以下の条件を達成していること・・・これを判断するようなメトリクスが必要になる
- 実行済みテスト(テストを消化していること)
- カバレッジ
- 残存リスク : 未修整の欠陥やカバレッジ不足の領域が合意された制限内であること
- 残存欠陥数 : 信頼度成長モデル(※)などを用いて想定した残存欠陥数が十分に少ないこと
- 品質特性 : 各品質特性の評価レベルが十分であること
※信頼度成長モデルとは (引用元 : https://www.ipa.go.jp/files/000005133.pdf)
ソフトウェア信頼度成長モデル（SRGM）は、主にテスト工程で用いられ、与えられた累積欠陥データの傾向から総欠陥数を推定するものである。
指数形モデル、超指数形モデル、遅延 S 字形モデル、ゴンペルツ曲線、シフトゴンペルツモデル、ロジスティック曲線、習熟 S 字形モデル等がある。
予測欠陥数が摘出目標欠陥数を下回るようであれば、その予測欠陥数を目標欠陥数に追い込むため、レビュー工数の追加や、レビューアの質の向上等の改善施策を計画する。
テスト実行スケジュール
設計したテストケース一覧リストの上から下までやみくもに実施するのではなく、効率良く・効果的に行うための実行の計画を立てる必要がある (考えるべきこと↓)
- 効率性
- テストを実施する順番 (小さいモジュールから実施していくなど)
- 依存関係
- テストケースの依存関係によりテストの順番を考える (テストケースAとテストケースBは連続に実施する必要がある)
- テスト対象機能間の依存関係によりテストの順番を考える (機能Aは、機能Bを利用するから、機能Bを先にやる必要があるなど)
- 優先度
- テストアイテムやテストケースの重要度により、優先度が異なる
- 開発者へ早期フィードバックを行う必要があるのであれば優先度は高い (デバッグ後の確認テストやリグレッションテスト)
テスト工数に影響する要因
テストの工数に影響を与えるものは、3つの特性 (プロダクト、開発プロセス、人)
テスト見積りの技術
過去の実績に対して、見積もり対象のテストが近いと考えれらるのであれば、メトリクスが有効である。
一方で、規模が異なったり、ドメインが異なるのであれば、メトリクスは信頼できないため注意が必要。(結果的に納期と費用に対する帳尻合わせ的な見積もりとなってしまうが、これは意味のない見積もりとなるので避けるべき。)
- メトリクス活用による見積もり
- アジャイル開発 : バーンダウンチャート
- バーンダウンチャートの実績工数を基に、次のイテレーションの工数を見積もる
- シーケンシャル開発 : 欠陥除去モデル
- 過去の類似プロジェクトの実績(検出した欠陥数や修正に要した工数)を基に、工数を見積もる
- アジャイル開発 : バーンダウンチャート
- 専門家の知識を基に見積もる
- アジャイル開発 : プランニングポーカー
- チームメンバ全員参加で、各自の経験に基づいて工数を見積もる
- 参考 : Slideshare「プランニングポーカーでアジャイルな見積もりがいい！」
- シーケンシャル開発 : ワイドバンドデルファイ法 (良い資料がなかった。。。)
- 専門家自身の経験に基づいて工数を見積もる
- アジャイル開発 : プランニングポーカー
テストのモニタリングとコントロール
策定した計画のモニタリングと開発を成功させるためのコントロールについて
テストプロセスの状態を図るための指標(メトリクス)を収集・モニタリングし、テスト活動をコントロールするための対策を講じる(例えば、スケジュールの見直し、リソースの投入)
- コントロールする必要がある状況
- リスクが現実になった時
- テスト環境などのリソースが利用できなくなった時
- 一度中断したテストを再開する時
テストで使用するメトリクス
テストレポート
- テストレポートの目的
- テスト活動の結果を要約し、ステークホルダーに周知する
- テスト活動から得られた教訓をを未来のテスト活動にフィードバックするための情報として、ステークホルダーに提供する
- テストレポートの種類
- テスト進捗レポート
- 標準フォーマット : ISO/IEC/IEEE 29119-3 テスト進捗レポート
- テスト活動の状況とテスト計画書に対する進捗
- 進捗を妨げている要因
- 次の報告までの間で行う実行予定のテスト
- テスト対象の品質
- など
- テストサマリーレポート
- 標準フォーマット : ISO/IEC/IEEE 29119-3 テスト完了レポート
- 実行したテストの概要
- テスト計画からのテストの逸脱
- テスト完了評価
- 進捗を妨げた要因
- テスト方法
- 残存リスク
- テスト成果物
- 再利用可能なテスト資産
- など
- 標準フォーマット : ISO/IEC/IEEE 29119-3 テスト完了レポート
- テスト進捗レポート
- テストレポートはテーラリングして活用
- 報告の目的や対象者に応じて内容を拡充・省略して使う(↓が大まかな報告の種類)
- 多くのステークホルダー向けの報告
- 組織内の簡易的な報告
- アジャイル開発などでの日々の朝会での報告
- 開発担当者やテストチーム向けの報告
- プロジェクトマネージャー向けの報告
- 経営者向けの報告
- 報告の目的や対象者に応じて内容を拡充・省略して使う(↓が大まかな報告の種類)
構成管理
構成管理について
構成管理は、欠陥のある部品がプロダクトに入り込まないように、マネジメントするための仕組
(英語 : SCM(Software Configuration Management))
- プロダクトを構成する部品のバージョンコントロールとトレーサビリティ確保を実施することで↓を防ぐ
- 間違ったバージョンのプロダクトの出荷
- 違った欠陥の報告
- ベースソフトウェアのバージョンを間違えて開発
- ソフトウェアに関わる情報を探し回る
- テストウェアの構成管理
- 目的
- 再テスト(デバッグ後の確認テストやリグレッションテスト)で適切なテストケース・データを扱うため
- 間違えて古いテスト手順で確認テストをしたために、欠陥が直ったと勘違いし、リリースしてしまった。。。とういことを防ぐための仕組
- 対象
- テスト対象
- ソフトウェアの動作環境
- テストウェア
- 欠陥
- テスト結果
- ドキュメント類
- 構成管理の手順
- 構成管理対象を決める(マスタテスト計画書作成時)
- 構成管理方法(進め方、使用するツール、担当者、規則)を決める
- 記録を残す(実際に構成管理を行うために、バージョン情報の記録を行う)
- 管理する (必要な時に参照できる状態にしておく)
- 目的
リスクとテスト
リスクの定義
ソフトウェア開発でのリスクは、プロジェクトのステークホルダーやプロダクトのユーザが受ける可能性がある不利益の元
シラバスではリスクを以下のように定義している
「将来的に否定的な結果となる事象が起きる恐れを含む。リスクのレベルは、そのような事象が起きる可能性とその影響(事象による結果がもたらす損害)で決まる。」
プロダクトリスクとプロジェクトリスク
- プロダクトリスク (←リスクベースのアプローチが有効)
- 「作業成果物がユーザーおよびステークホルダーの正当なニーズを満たすことができない恐れを含む」
- テストによってリスクの軽減を行う (事前対策)
- 種類(例)
- 故障の起きやすいソフトウェアの出荷 (ソフトウェアの故障と改修)
- ソフトウェアやハードウェアが個人や会社に対して損害を与える可能性 (個人への損傷、顧客企業への障害)
- 貧弱なソフトウェア品質特性 (顧客を満足させられない)
- 貧弱なデータの完全性と品質 (ソフトウェアの目的を果たさない)
- 予定の機能が動作しないソフトウェア (当たり前品質を満足しない)
- 以下のプロダクトリスクを軽減させるためにテストを実施 -
- ソフトウェアが仕様通りでないかもしれない
- 顧客のニーズ通りに動かないかもしれない
- 非機能要件を十分に満足しないかもしれない
- など
- プロジェクトリスク
- 「発生した場合にプロジェクトの目的達成に悪影響を与える」(ヒト,モノ,カネの観点でとらえる)
- 観点 : 人
- テストを行う組織やメンバー (スキル不足、リソース、人員配置)
- テストに関わる他のプロジェクト内外の組織 (顧客も含む)
- 観点 : モノ
- ソフトウェア
- ハードウェア
- ドキュメント(テストウェア)
- 観点 : カネ
- 予算に対する実績コスト
- スケジュールに対する実績進捗
- 人件費や間接コスト(トレーニング費用、テスト環境整備・維持費用、通信費など)
- 種類
- スケジュールに関するリスク
- テストの進捗が滞る
- テストケース作成/実行がスケジュールに終わらない
- テスト環境整備に関するリスク
- 調達が滞り、テスト環境が構築できない
- テストマネジメントに関するリスク
- テスト活動に必要なヒト・カネを確保できない
- テスト計画が適切に活用されない (テスト計画通りに進まない)
- 無計画にテスト活動を進めた結果の予算やリソースのショート
- スケジュールに関するリスク
リスクベースドテストとプロダクト品質
プロダクトリスクを軽減するための予防的処置として、リスクベースのアプローチが有効
リスクに対して以下のように対処する
- 適用するテスト技法を決める
- リスクの優先度が高い機能に対して、網羅率が高くなるようにテスト技法を選択 (例：ホワイトボックステストなら、網羅率の高いC1カバレッジを使う)
- 実施するテストレベルおよびテストタイプを決める
- 修正作業のインパクトを考えて、テストレベルを決める (例えば、コンポーネントテストで見つけたほうが修正範囲に対して十分なテストができる。また、手戻りも少ないなど。)
- テストを実行する範囲を決める
- リスクの大きさに応じて、「ここも見ておいたほうがよいかも。」を決める
- 重大な欠陥をなるべく早い時期に検出するために、テストの優先順位を決める
- クリティカルな欠陥を第一に検出できるようにテストを決める
- テスト以外の活動でリスクを減らす方法があるか検討する
- 欠陥を作り込まないようなプロセスへ改善
- 開発者の適切なトレーニング
- リスク分析により、リスクを洗い出すことが重要
- リスク重要度に応じて、テストする/しないという判断が取れる
- リスク重要度が高いものに対しては、十分なカバレッジが網羅できるようにテストアプローチを選択できる
欠陥マネジメント
欠陥マネジメントについて
- 欠陥マネジメントの目的
- 開発担当者への情報提供
- 故障・不正に関する情報
- (必要に応じ、問題の切り分けをした情報)
- テストマネジメントのための情報提供
- 欠陥数や状態を把握し、テスト計画にフィードバックするため
- 開発プロセスとテストプロセスの改善するためのヒントを提供
- 欠陥の情報から開発プロセスやテストプロセスの改善につながる情報を提供する
- 開発担当者への情報提供
- 欠陥レポートの構成 (要約)
- 欠陥の件名と概要
- レポート作成日付、作成者
- テストアイテム
- 欠陥を観察した開発ライフサイクルのフェーズ
- ログ、データベースのダンプ、スクリーンショット (欠陥の再現手段)
- 期待結果と実際の結果
- ステークホルダーに与えるインパクトの範囲や重要度
- 修正の緊急度/優先度
- 欠陥レポートのステータス
- 結論、アドバイス、承認
- 懸念事項
- 修正履歴
- テストケースなどの参照情報
- 欠陥マネジメントのプロセス
- オープン
- 分析/割り当て
- 修正待ち
- 延期
- 重複
- 確認テスト待ち
- 再オープン
- クローズ
以上 第5章.テストマネジメント
参考になれば幸いです。