JSTQB(ALTM) シラバス学習：5 テストプロセスの改善
2019.09.08更新
- 5.1 イントロダクション
- 5.2 テストプロセス改善
- 5.2.1 プロセス改善の紹介
- 5.2.2 プロセス改善のタイプ
- 5.3 テストプロセスの改善
- 5.4 TMMiによるテストプロセスの改善
- 5.5 TPI Next によるテストプロセスの改善
- 5.6 CTPによるテストプロセスの改善
- 5.7 STEPによるテストプロセスの改善
5.1 イントロダクション
テストマネージャーはモデルについて精通し、継続的に改善を行うことが大切です。
下記 JaSST'19の資料内（テストプロセスの改善）も参考になります。
http://jasst.jp/symposium/jasst19hokuriku/pdf/S1.pdf
5.2 テストプロセス改善
ソフトウェア開発プロセスを改善するために、プロセス改善技法を使用することができます。ただし、テストプロセスの改善はモデルを使用しなくても、分析的アプローチや振り返りミーティングなどでも達成でき、各組織で改善のために何がより良いアプローチか議論することが大切です。
欠陥は人が作り込みますが、それは作り込む組織のシステムに欠陥があるということでもあり、組織内での議論が必要になります。
ソフトウェアプロセス改善モデル
テスト改善モデル
- TMMI（テスト成熟度モデル統合）
- STEP（体系的テストと評価プロセス）
- CTP（クリティカルテストプロセス）
- TPI Next（Test Process Improvement）
参考書籍
5.2.1 プロセス改善の紹介
ソフトウェア開発プロセスの品質はシステムの品質に大きな影響を与えます。プロセス改善を行うことにより、以下に示すような効果が期待できます。
- ソフトウェア品質の向上
- ソフトウェア維持のリソース削減
- 新ソリューション開発のリソース確保
プロセスモデルの改善では、組織のプロセスの成熟度の測定から開始します。その後、プロセス能力判定やプロセスアセスメントなどにより改善活動を進めます。
5.2.2 プロセス改善のタイプ
アセスメントモデル
一般的に使用されており、実証済みの実践例を使用する標準的なアプローチです。
プロセス改善モデル
- プロセス参照モデル：モデルとの比較やフレームワークから組織の評価を行います。プロセス改善のロードマップも提供します。
- コンテンツ参照モデル：測定指標を用いてベンチマーキングを行うなど、ビジネス指向の評価を行います。プロセス改善のロードマップ作成に使用します。
5.3 テストプロセスの改善
プロセス改善は推奨されるモデルや適切なステップが存在しますので、事前に組織やステークホルダとの合意を行い、適切なステップで進めていく必要があります。
推奨プロセス
- TMMi、CMMI：段階的なモデルでは異なる企業や組織の比較に対応できます。
- STEP、TPI Next、CTP：連続的なモデルでは優先度の高い問題に対応できます。
プロセス改善ロードマップ
- TMMi、TPI Next：テストプロセス改善のためのロードマップを提示できます。
- STEP、CTP：最大の投資効果を受けている部分を判定して、適切なロードマップを採用できます。
プロセス改善ステップ
改善活動を進める合意がされた場合、プロセス改善のステップを決めます。その際、IDEALモデルで定義されているステップを採用できます。
以下のステップを一通り実行した後の進め方は、プロセスモデルごとに異なります。
改善プロセスの開始
改善活動の開始前に以下について決めておきます。
- 目的
- 目標
- 対象範囲
- 改善モデルの選択（公開されているモデルや内部開発）
- 合格基準の定義（基準に基づく測定方法の決定）
現在の状況の診断
アセスメントレポートを作成します（レポートには改善項目リストを含みます）。
テストプロセス改善計画の確立
改善項目リストの優先順位を策定して改善実行の計画を作成します。
優先順位は以下の情報に基づいて設定します。
- 投資効果
- リスク
- 組織戦略
- 利点
改善を推進する活動
以下のようなプロセス改善に必要な活動を導入して展開します。
- トレーニング
- メンタリング
- プロセスのガイド
改善プログラムからの学習
プロセス改善をすべて展開したら、合格基準を達成していることを確認します。
また、事前に合意した利点や予測していなかった利点を確認します。
5.4 TMMiによるテストプロセスの改善
TMMiには5つの成熟度レベルがありCMMIを補間します。
成熟度レベル
成熟度のレベルを上げる際には各レベルの目標の85%を満たす必要があります。
レベル１：初期
- 公式な文書や体系的なテストプロセスがない
- テストケースはコーディングの後に開発されデバッグと同じ行為と見なされている
- テストはソフトウェアの動作を証明するものと考えられている
レベル２：管理された
- テストプロセスはデバッグと明確に分離されている
- テストポリシーや目標が設定されている
- 基本的なテストプロセスの導入され活用されている
レベル３：定義された
レベル４：測定された
- 組織レベルでテストプロセスを効率的に測定、マネジメントできている
- 特定のプロジェクトで効率的に適合できた実績がある
レベル５：最適化された
- テストプロセスのアウトプットにより欠陥を予防する手助けができる
- プロセスをより最適化することに焦点が当てられている
引用：TMMi Reference Model - R1.2「2.1 Overview」
ドキュメント
TMMiの様々なドキュメントは以下からダウンロードできます。
https://www.tmmi.org/tmmi-documents/
5.5 TPI Next によるテストプロセスの改善
成熟度を視覚化することで改善目的を明確にして、組織の状況に応じたフィードバックができます。
特徴
- 4つの成熟度レベルが定義されています。
- 16のキーエリアがあり、各キーエリアはテストプロセスの特定の側面をカバーしています。
- キーエリアのチェックポイントを検証することにより、カバーする成熟度マトリクスによる要約や視覚化ができます。
- すべてのソフトウェアプロセス改善モデルから独立しています。
- テストエンジニアリングの側面と管理者の意思決定支援の両面をカバーしています。
成熟度レベル
4つの成熟度レベルが定義されています。
- 初期
- 制御された
- 効率的な
- 最適化している
ドキュメント
TPI Nextの様々なドキュメントは以下からダウンロードできます。
http://www.tmap.net/tpi-downloads
5.6 CTPによるテストプロセスの改善
CTPによるテストプロセスの改善では、最重要なテストプロセスが特定されていることが前提となります。課題、優れたプロセス、改善順序や重要性など、状況に応じた改善に対応ができます。
特徴
5.7 STEPによるテストプロセスの改善
STEPはCTPと同様に特定の順序で行う必要はありません。TPI Nextと組み合わせて使用することができます。
特徴
- コンテンツ参照モデル
- 要件ベースのテスト戦略（コーディングの前にテストすることによる要求仕様の妥当性判断）
- ライサイクルの開始時からテストを行う
- テストウェアの設計をソフトウェアの設計より先に行う
- 欠陥を早期に検出するか予防する
- 欠陥を体系的に分析する
- テスト担当者と開発者の共同作業
JSTQB(ALTM) シラバス学習：4 欠陥マネジメント
2019.08.17更新
- 4.1 イントロダクション
- 4.2 欠陥ライフサイクルとソフトウェア開発ライフサイクル
- 4.2.1 欠陥ワークフローと状態
- 4.2.2 無効および重複した欠陥レポートのマネジメント
- 4.2.3 クロスファンクショナルな欠陥マネジメント
- 4.3 欠陥レポート情報
- 情報の内容
- 4.4 欠陥レポート情報によるプロセス能力の評価
4.1 イントロダクション
ソフトウェアの開発ライフサイクルでは、発生した欠陥をどのようにマネジメントするかが、当該プロジェクトおよび将来のプロジェクトの発展のために重要となります。
テストマネージャは以下について適切なアプローチを行い、テストプロセスやソフトウェア開発プロセスについて継続的な改善を行います。
- 取得すべき重要データへの精通
- 長期的なデータの収集と分析
- 使用する欠陥マネジメントツールの選択
4.2 欠陥ライフサイクルとソフトウェア開発ライフサイクル
欠陥は成果物を作成するときに人が犯す誤りから混入します。
欠陥はソフトウェア開発ライフサイクルのいずれの場所にも混入する可能性があるため、常に欠陥の検出と除去をするための活動が必要となります。
欠陥は早い段階で、できれば混入と同じフェーズで検出と除去が行われるほど品質コストは低下します。品質コストは欠陥自体を直接見つける静的テストの方が低くなります。動的テストでは、偽陽性や偽陰性でデバッグに時間がかかる可能性があり、コストが高くなる傾向があります。
静的テスト（欠陥を見つける）
- 要求仕様
- ユーザストーリー
- テクニカルドキュメント
- テストケース
- プログラムコード
動的テスト（故障を見つける）
4.2.1 欠陥ワークフローと状態
欠陥レポートはテスト担当者が正確にレポートして、ソフトウェア開発者が欠陥を解決していくために必要な情報です。RedmineやBugzillaなどが多く使われます。
欠陥状態の遷移
初期状態：オープン、新規
一人または複数のテスト担当者が不正を再現させるための情報を収集します。
返却状態：拒否、明確化
テスト不十分によるレポートの受け入れ拒否、または再現情報の追加収集を依頼されています。
確認テスト状態：解決済み、検証
確認テストで修正内容の確認をします。
確認テストの結果により状態をクローズまたはオープンに遷移させます。
終了状態
- クローズ：欠陥が解決して確認テストによる検証が終了
- キャンセル：無効な欠陥レポートと判断
- 不再現：不正・故障が観察できない
- 延期：欠陥をそのプロジェクト内で修正しない
4.2.2 無効および重複した欠陥レポートのマネジメント
不正（結果と期待値が異なる）が欠陥の兆候としてではなく、何らかの誤解により発生する場合があります。できるだけ正確なレポートの発行が必要ですが、誤りの排除を意識しすぎるとレポート発行が遅れたり、未発行となる要因にもなるので対策を行う場合は注意が必要です。
誤解が生まれる要因
- テスト環境
- テストデータ
- テストウェア
- テスト担当者
終了方法
- 無効：偽陰性となった欠陥レポートはキャンセルあるいはクローズします。
- 重複：不正の兆候は異なるが根本原因が同じと判明した場合はクローズします。
4.2.3 クロスファンクショナルな欠陥マネジメント
クロスファンクショナルなチームは、欠陥レポートのマネジメントを部門横断的に担当します。欠陥マネジメント委員会は、不正が欠陥マネジメントツールに登録されると、欠陥を解決する場合と解決しない場合に生じるメリット、リスク、コストから解決すべきか判断します。
解決すると判断された欠陥は、相対的な重要度から優先度を決めて解析を進めます。
欠陥を効率的に解決するには、以下のすべてをバランス良く取り入れることが必要です。
- コミュニケーション
- 欠陥追跡ツール
- 欠陥ライフサイクル
- 欠陥マネジメント委員会
4.3 欠陥レポート情報
欠陥あるいは故障を観察した場合には、プロジェクト全体で意味ある比較ができる情報を収集して欠陥レポートに登録します。
情報の内容は対面的なコミュニケーションで補足できたとしても、適切にアセスメントするという点では、すべての情報は、完全、簡潔、正確、客観的、適切、タイムリーに欠陥レポートに記録されることが重要となります。
情報の目的
- 欠陥ライフサイクル全体でのレポートのマネジメント
- プロダクトの品質とテスト進捗に関するプロジェクトステータスのアセスメント
- プロセス能力のアセスメント
情報の用途
欠陥データは以下に示すような分析を行い、テスト進捗のモニタリング、コントロール、終了基準の評価をするために使用できます。
- 欠陥密度分析
- 解決した欠陥の傾向分析
- 検出から解決までの平均時間
- 故障強度
情報の内容
収集する必要のある情報は、ISO9126、IEEE829、IEEE1044などを参考にできます。
- 発見者の名前
- 発見者の役割（エンドユーザ、開発者、など）
- 発見したときのテストタイプ（性能テスト、回帰テスト、など）
- 問題の概要
- 問題の詳細
- 故障の再現手順、実際の結果と期待する結果、ログ、など
- 欠陥の混入、検出、除去が発生したライフサイクル
- 欠陥が混入した成果物
- ステークホルダへのインパクトの重要度
- 問題解決の優先度（ビジネスインパクトによる）
- 欠陥が存在するサブシステムまたはコンポーネント
- 問題検出時のプロジェクト活動
- 問題検出時の識別方法（レビュー、動的テスト、など）
- 欠陥の種類
- 欠陥により影響を受ける品質特性
- 欠陥を観察したテスト環境
- 問題が存在するプロジェクトとプロダクト
- レポートの所有者（レポートが最終状態にない場合）
- レポートの状態
- 問題を観察した成果物、解決した成果物
- 問題解決のためのアクションに関する結論、提案、承認
- 欠陥を解決する場合としない場合のリスク、コスト、機会、メリット
- 欠陥ライフサイクルの遷移が発生した日付とそのときのアクションなど
- 解決した方法の説明と解決策をテストするための方法
- 欠陥を観察したテスト、リスク、要件、など
4.4 欠陥レポート情報によるプロセス能力の評価
テストプロセスの効果と効率を評価するため、欠陥レポートが何を意味するのか見極める必要があります。メトリクスが示すプロセスの状態を正確に理解して、テストプロセスとソフトウェア開発プロセスの能力の評価やプロセス改善の取り組みを行います。
プロセスの改善
検出効率改善
欠陥総数改善
-
混入情報から、最多数の欠陥が混入したフェーズを分析して欠陥の総数を削減する
-
根本原因情報から、欠陥混入の基となる理由を分析して欠陥の総数を削減する
コスト改善
-
混入、検出、除去の情報から、品質コストを分析して欠陥により発生するコストを最小化する
欠陥の追跡
欠陥は根本原因まで追跡すべきですが、効率性やプロセスオーバーヘッドなどのコストを削減する名目で追跡をしないことがあります。しかし、これらの行為は信頼できるデータを残さないことを意味し、プロセスの改善の実行を困難にします。そのため、状況に応じてリスク分析して判断する必要があります。
また、事象から根本原因の特定が難しく、暫定的に根本原因の除去はせず事象のみ対処するケースもあると思います。しかし、表に見える事象は1つではない可能性があるため、除去を延期した場合でも確実に根本原因を特定して早急に対処する必要があります。これは、プロセスの改善だけではなく、重大な欠陥が隠れていることによってプロダクトリスクが発生することを防ぐ目的でもあります。
JSTQB(ALTM) シラバス学習：3 レビュー
2019.07.14 更新
3.1 イントロダクション
レビューは静的テストの一種であるため、テストマネージャが責任を持つ（レビューリーダと呼ばれる）ことになります。レビューは品質向上に対してコスト効率の高い手段であるため、効果的なレビューを実施することが重要となります。
レビュー参加者の役割
レビューリーダ
- テスト成功の実現を推進する環境を確保する
- 効果的な価値をもたらすように測定計画を作成する
テスト担当者
- 運用での動作とソフトウェアシステムに求められる特徴からレビューする
参加者
- レビューのトレーニングを受けて、レビューが円滑に行われるように役割を果たす
レビューの種類
レビューリーダがこれらの技法を組み合わせて使用することにより、プロジェクトのテストカバレッジを向上させ、より多くの欠陥を見つけることができるようになります。
- 契約レビュー
- 要件レビュー：コードに問題を実装する前に問題を除去できる。機能要件と非機能要件を網羅することが理想的。
- 基本設計レビュー
- 詳細設計レビュー
- コードレビュー：動的テストの補完ができる。
- テスト成果物レビュー：工数がかかりすぎる問題のチェックができる。
- テスト開始レビュー
- テスト終了レビュー
- 受け入れレビュー
3.2 マネジメントレビューと監査
マネジメントレビュー
マネジメントレビューはプロジェクトの将来に関する決定を行うために実施します。
また、プロセス改善の活動として、プロジェクトの振り返りのために実施します。
目的
- 適用するリソースの決定
- 是正措置の実行
- 対象範囲の変更
手段
- 進捗状況のモニタリング
- ステータスの評価
- 将来の対応の決定
特徴
- 直接責任を持つマネージャ（または代理）によって実施する
- 上位マネージャまたは部門長によって実施する（ステークホルダ、意思決定者、または代理）
- 計画との整合性および逸脱をチェックする
- マネジメント手順の妥当性をチェックする
- プロジェクトのリスクを評価する
- アクションの影響とその測定方法を評価する
- アクションアイテムや課題や意思決定のリストを作成する
監査
目的
- プロセス、規制、標準などへの準拠を示すため独立した評価を提供する
特徴
- 監査リーダが管理、モデレートする
- 準拠のエビデンスを収集する
- 観察事項、勧告、是正措置、合否アセスメントのドキュメントの成果物に含む
3.3 レビューのマネジメント
レビュー戦略はテストポリシーと全体的なテスト戦略とに適合させる必要があるため、実施するタイミングが重要となります。
実施タイミング
- 要件と設計を定義した後
- ビジネスの目的段階から詳細設計段階までの適切な区切り
- マネジメントレビューはテスト実行および重大なプロジェクトフェーズの前、途中、後
実施タイミングに関係する要素
- 対象アイテムの体裁面での完成度合い
- レビューに適した担当者の参加可能性
- アイテムの最終版が利用できるタイミング
- アイテムのレビュープロセスにかかる時間
タイミングごとのレビューリーダの役割
レビュー計画作成前
以下に関する決定を行い、継続的に改善活動を行うために、レビューのためのチェックリストの作成と維持を行います。
- レビュー対象を定める
対象を定めることにより、適切なレビュータイプ（非公式レビュー、ウォークスルー、テクニカルレビュー、インスペクション）と公式度合いを決定します。
- レビュー参加者を定める
必要に応じて追加のレビュートレーニングを実施します。
[レビュー参加者の条件]
技術と手順の両方に関して適切な知識
細部に対する完全さと注意力
コメントが明確かつ優先度付けの正しさ
- カバーすべきリスクを定める
リスク評価と投資効果の計算からレビューの予算（時間とリソース）を割り当てることができます。投資効果はレビューのコストとレビューせず その後に検出された欠陥に対処するためのコストの差で示されます。品質コストの計算が使用できます。
レビュー計画
以下に関する主要なレビューアが参加できないリスクやトレーニングができないリスクに備えておく必要があります。
- 技術的要因
十分な技術的知識を持つレビューアがいること
- 組織的要因
すべてのチームをレビュー計画に参加させて責任を持たせること
- 人的問題
レビューの準備、必要とされるトレーニングを受講する時間を用意すること
テスト計画時
以下の定義を行います。フィードバックに関する合意した意思決定の実施も含みます。
- レビュー評価を行うためのメトリクス
- レビュープロセスの目的
レビュー実施後
レビューで発見した課題や問題の欠陥マネジメントのために重要度と優先度の判断基準を作成します。
- 識別された課題が解決されていることをレビューメトリクスを収集して確認する
- レビューの投資効果（ROI）をレビューメトリクスを収集して確認する
- フィードバック情報をステークホルダに提供する
- フィードバック情報をレビュー参加者に提供する
レビューの評価
レビュー参加者が提供する測定指標を使用してレビューの評価を効率よく実施します。レビューメトリクスは賞罰には使用せずレビュープロセス自体に焦点を置いて、レビューリーダが中心となり原因の調査を行います。
- レビューレポートの結果と実際の結果の比較
- 成果物レビューの実施後に欠陥を発見した場合のレビュープロセスの見直し
- レビューチームの編成やレビューツール、トレーニングなど欠陥を見逃した要因の確認
- 検出効率の低下がないことの確認（時間経過によりレビューの効果が失われて検出効率が落ちることがある）
繰り返し
プロジェクトレビューは必要に応じて繰り返し実施します。
回数、タイプ、編成はプロジェクトの規模や複雑さ、プロダクトリスクに依存します。
3.4 レビューのためのメトリクス
レビューリーダ（テストマネージャ）はメトリクスをレビューで使用できるように定量化して、プロダクト評価/プロセス評価をすることにより投資効果、レビュー効率、レポート活動改善、プロセス改善活動に活用します。
メトリクスによる測定
目的別に以下のメトリクスを測定してレポートします。
プロダクト評価
実施コスト評価
- 成果物のページ数、コード行数などのサイズ
- レビューの準備時間
- レビューの実施時間
- レビュープロセスの期間
- レビューのタイプ
- 欠陥を解決するための解析・修正・再評価時間
品質評価/次工程に進めるか評価
ここで出た結果は次工程で重点的に評価すべきポイントの絞り込みにも使います。
- 発見した欠陥の数とそれらの重要度
- 平均欠陥密度（欠陥検出効率）
- 推定残存欠陥数または残存欠陥密度（欠陥除去率）
- 成果物内の欠陥の偏在の識別
プロセス評価
プロセス評価にはプロダクト評価のメトリクスも使用でき、さらに以下のようなメトリクスも用います。
- 計画した成果物の網羅率
- レビュープロセスの活動とタイミング
- レビュープロセスの効果と効率性
- レビューで発見した欠陥と動的テストや運用後に発見した欠陥の比
- レビュータイプと欠陥検出効率の相関関係（レビュー効率の良いタイプ）
- レビュアー数
- 作業時間当たりの欠陥検出数
- 平均欠陥工数（（総検出時間＋総修正時間）÷ 総欠陥数 ）
- 節約される推定時間
3.5 公式レビューのマネジメント
公式レビューの特性
- レビューの開始基準と終了基準
- レビュアーが使用するチェックリスト
- レポート、評価シートなどの提供物
- レビューの効果、効率、進捗を示すメトリクス
公式レビューのフェーズ
レビューリーダは公式レビュー開始前に開始基準の前提条件を満たしているか確認を行います。公式レビューの状況は常にモニタリングを行い、プロジェクトの品質保証活動を進めます。
- 計画
- キックオフ
- 準備
- レビューミーティング
- 再作業
- フォローアップ
前提条件を満たさない場合の対応
開始基準の前提条件を満たしていない場合には、レビュー責任者の最終判断を確認して対応を決めます。
- レビューの再定義
- レビューを進めるための是正措置
- レビューの延期
JSTQB(ALTM) シラバス学習：2 テストメトリクスの定義および使用(2.6)
2.6 テストメトリクスの定義および使用
2019.02.18更新
テスト活動による結果を正しく判断するため、適切なテストメトリクスを定義する必要があります。
メトリクスの使用目的
分析
テスト結果から傾向と原因を探します。
レポート
テスト結果から気づいた点をプロジェクト参加者やステークホルダと共有して計画からの逸脱がないことを確認します。プロジェクトマネージャには欠陥についての詳細情報、ビジネスマネージャにはプロダクトリスクステータスが重要な情報となります。
コントロール
モニタリング結果から状況の変化に応じてテストやプロジェクト全体を見直し軌道修正します。
テストメトリクのカテゴリ
メトリクスのカテゴリは以下の1つ以上に分類されます。
例えば、メトリクスの一つである欠陥検出率を示す指標は終了基準、プロダクトの品質、テストプロセスの能力に関連付けできます。
プロジェクトメトリクス
プロジェクト終了基準（合格、不合格等）に対する進捗を測定します。
プロダクトメトリクス
プロダクトの属性（欠陥密度等）について測定します。
プロセスメトリクス
テストプロセスや開発プロセスの能力（検出された欠陥の割合）を測定します。
人的メトリクス
個人またはグループの能力を測定します。
メトリクスの利用
定義
プロジェクト、プロセス、プロダクトごとの目的に従い、有用な情報に限定して定義します。ステータスや傾向に誤解が生じないよう、バランスよく定義する必要があるが、多すぎもダメ。ステークホルダとの間で合意しておきます。
追跡
生データからメトリクス算出までは自動化すべきです。
メトリクスが変化する場合は合意した解釈以外の情報の影響を分析します。
レポート
速やかに理解できる情報にしておきます。
特定の時期のスナップショットや変化を抽出できるようにしておきます。
有効性
正確性、データから読み取れる情報を検証します。
メトリクスの種類
テスト計画のモニタリングメトリクス
- テストベースカバレッジ
- 欠陥検出
- テストケースの実行に関する計画時間と実時間
テスト分析活動のモニタリングメトリクス
- テスト条件の数
- テスト分析時に検出した欠陥の数
テスト設計活動のモニタリングメトリクス
- テスト条件を網羅している割合
- テスト設計時に検出した欠陥の数
テスト実装活動のモニタリングメトリクス
- 構築済みテスト環境の割合
- テストデータレコードの割合
- 自動化したテストケースの割合
テスト実行活動のモニタリングメトリクス
- 実行したテストケースの割合
- 実行したテストケースにより網羅したテスト条件の割合
- 欠陥の計画数と実際の数
- カバレッジの計画数と実際の数
テスト進捗および完了活動のモニタリングメトリクス
- プロダクトリスク、欠陥、テスト、テストカバレッジ、確信度合い
- 合格、不合格に分類した数
- 欠陥の総数を分類した数
- 変更の発生やテスト済みの数
- 計画と実際ののコスト、期間の比
- プロダクトリスクのステータス
- 進捗を妨げたイベントなどにより無駄になった活動の割合
- 確認テストと回帰テストのステータス
テスト終了活動のモニタリングメトリクス
- 実施、ブロック、スキップしたテストケースの割合
- 再利用可能なテストケースとしたテストケースの割合
- 自動化対応したテストケースの割合
- 回帰テストに統合したテストケースの割合
- 解決済みの欠陥レポートの割合
- 保管したテスト成果物の割合
2.7 テストのビジネスバリュー
- 過剰なテスト：遅延やコスト増により優れたビジネスバリューを提供しない
- 過小なテスト：欠陥の流出により優れたビジネスバリューを提供しない
上記の2つの間に存在する最適なテスト量が優れたビジネスバリューを提供すると認識し、ステークホルダが価値を理解できるように価値の定量化、記述など、明確な表現で示す必要があります。
価値の種類
どのような価値に当てはまるか理解することで適切な情報を提供することができます。
定量的価値
- リリース前に予防、修正する欠陥
- リリース前に判明する欠陥（回避策を文書化）
- テスト実行によるリスク軽減
- ステータスの情報提供
定性的価値
- 品質による評判向上
- 予定を立てやすいリリース
- 確信度合いの向上
- 法律上の免責
- システムの指名が果たされないリスク軽減
- 生命損失のリスク軽減
品質コスト
定量的価値や効率性を測定する方法のひとつで、プロジェクトや運用コストをプロダクト欠陥コストに関連する4つのカテゴリに分類します。
- 予防コスト：保守性、セキュリティ強化されたコードを書くためのトレーニング
- 評価コスト：テストケースの記述、テスト環境の構成、要件のレビュー
- 内部失敗コスト：テスト、レビューで検出した欠陥の修正
- 外部失敗コスト：提供したソフトウェアの欠陥のサポートコスト
また、テスト予算は評価コストと内部失敗コストの合計により示されます。
評価コストと内部失敗コストの合計は外部失敗コストを十分下回ることが、テストが優れた価値を提供していることを示す指標となります。
2.8 分散テスト、アウトソーステスト、およびインソーステスト
テスト活動はプロジェクトチーム自身が行うとは限りません。
テスト活動の種類
- 分散テスト：テスト活動を複数の地域で行う
- アウトソーステスト：プロジェクトチームと同じ地域にいない人が行う
- インソーステスト：プロジェクトチームと同じ地域にいるが同僚の従業員ではない人が行う
テスト活動に必要な定義
このようなテスト活動では、コミュニケーションの問題と期待との差異による問題を起こしやすいので、問題を避けるため以下のようなことを明確に定義することが必要となります。
誰がどこでテスト活動を行なったとしても、それぞれの役割に責任を持って活動できるように、自分たちが何のために何をすべきかを明確に理解できるようにマネジメントする必要があります。
これを成すことが、品質や納期の確保につながり、ステークホルダの信用を得ることにつながります。
2.9 業界標準適用のマネジメント
ソフトウェアテストには以下に示すような標準があります。
そこで、使用する標準を公式な標準、社内の標準、推奨事項のいずれに該当するのか整理する必要があります。また、複数の標準を使用する場合には、矛盾した定義などがないか確認が必要であったり、法的に準拠が必要なものがあったりするため、しっかりとした理解が必要となります。
- 国際標準
- 国内標準
- ドメイン固有の標準
標準の種類
以下に標準の分類と関連標準の例を示します。
国際標準
- ISO(International Standards Organization：国際標準化機構)：標準の推進
- IEEE(Institute of Electrical and Electronics Engineer：電気電子学会)：標準の提案
国内標準
- BS 7925-2(英国の国際標準)：テスト設計技法に関連する情報を記述
ドメイン固有の標準
- DO-178B(米国連邦航空局の標準)：民間航空機に使用するソフトウェアに適用され、致命度に基づく基準の設定
- Title 21 CFR Part 820(FDA：米国食品医薬品局)：構造的、機能的なテスト技法の提案
その他のフレームワーク
その他にもソフトウェア開発に関係するフレームワークがありますが、ISTQBの用語と異なるものもあるため、選択するフレームワークごとに用語の理解が必要となります。
JSTQB(ALTM) シラバス学習：2 テストマネジメント(2.4)
2018.09.23更新
- 2.4 テストドキュメントとその他の成果物
- 2.4.1 テストポリシー
- 2.4.2 テスト戦略
- 2.4.3 マスターテスト計画
- 2.4.4 レベルテスト計画
- 2.4.5 プロジェクトリスクマネジメント
- 2.4.6 その他のテスト成果物
- 2.5 テストの見積り
2.4 テストドキュメントとその他の成果物
テストを実施する際には、テストマネジメントドキュメントが作成されます。
これらのドキュメントは組織や公式度によって作成される種類が異なり、公式度が高くなるほど全てのドキュメントが成果物として利用され、公式度が低くなるほど一部だけ成果物として利用する傾向が高くなります。
テストマネジメントドキュメントの種類と内容
- テストポリシー：組織のテストに関する目的と目標
- テスト戦略：組織の一般的なテスト方法（プロジェクトに依存しない）
- マスターテスト計画（プロジェクトテスト計画）：特定のプロジェクトに関するテスト戦略の実装
- レベルテスト計画（フェーズテスト計画）：各テストレベルで実行する特定の活動
2.4.1 テストポリシー
テストポリシーはテストの目的が定義されたドキュメントです。そして品質ポリシーの補完、もしくはその一部となります。
テストポリシーは新規開発用に加えて保守テストにも対応させ、組織全体で使用する内部標準や外部標準としても参照できるようにする。
作成者
上級テストマネジメントスタッフが、テストステークホルダグループの上級マネージャと協力して作成します。
内容
上位のドキュメントとして以下の内容を要約して記載します。
- テストから得られる価値
- テストの目的（ソフトウェアの確信度合いの構築、ソフトウェアの欠陥の検出、品質リスクのレベル軽減など）
- 目的を達成するためのテストの有効性と効率性を評価する方法
- 一般的なテストプロセスの概要
- テストプロセスを改善する方法
2.4.2 テスト戦略
テスト戦略には一般的なテスト方法を記載します。
ガイドライン
テスト戦略は以下のようなガイドラインに従って記載します。
- 記載するプロセスおよび活動はテストポリシーと一貫している必要があります。
- 異なる戦略を組み合わせることもあります。
- 選択する戦略は組織のニーズや手段に適合させるため調整します。
- 実行するテストレベルを記載する場合もあります。その際には、テストレベル間の開始基準と終了基準の関係についてガイダンスを示します。
- 組織やプロジェクトによって適切なテスト戦略は異なります。
テスト戦略の種類
分析的戦略（リスクベースドテストなど）
カバーする条件の優先度に基づいてテストする順序を決める。
モデルベースド戦略（運用プロファイルなど）
実際の状況を予測して、システムの環境・入力と条件・動作方法のモデルを作成する。
方法論的戦略（品質特性ベースなど）
汎用的かつ論理的な一連のテスト条件を使用する。
プロセス準拠または規格準拠戦略（米国食品医薬品局の規定の対象となる医療システムなど）
規格委員会や専門家たちが定義した一連のプロセスに従う。
対処的戦略（欠陥をベースにした攻撃の利用など）
実際のシステムで実施する。
コンサルテーションベースの戦略（ユーザ主導のテストなど）
ステークホルダの入力からカバーするテスト条件を決定する。
回帰的テスト戦略（広範囲の自動化など）
回帰のリスクをマネジメントする技法を使用する。
その他の記載内容
テスト戦略には以下の内容を記載することもあります。
- 統合手順
- テスト仕様化技法
- テストの独立性
- 必須の標準および任意の標準
- テスト環境
- テスト自動化
- テストツール
- ソフトウェア成果物およびテスト成果物の再利用性
- 確認テストおよび回帰テスト
- テストのコントロールおよびレポート
- テストの測定指標およびメトリクス
- 欠陥マネジメント
- テストウェアの構成管理アプローチ
- 役割と責任
2.4.3 マスターテスト計画
マスターテスト計画に関する項目
すべてのテスト作業が対象となり、以下のような情報を記述します。
- 実行するレベル
- レベル間の関連
- テストレベルと開発活動との関係
- テスト戦略の実装方法
- テストポリシーと戦略の間の不整合についての情報
- プロジェクト計画や運用ガイドを補完する情報
マスターテスト計画の内容
組織やプロジェクトによって異なりますが、以下が代表的な内容です。
- テストするアイテムとしないアイテム
- テストする品質特性としない品質特性
- テストスケジュールと予算
- テスト実行サイクルとソフトウェアリリース計画との関連
- テストを行う人と他の人との関連性と提出書類（部署間の関連性も含む）
- 各レベルにおけるテストアイテムの対応範囲の定義
- 各テストレベルの開始・継続・終了の基準
- 各テストレベル間の関連性
- テストプロジェクトリスク
- テスト活動全体の管理
- 各テストレベルを実行する責任の所在
- 各テストレベルの入力と出力
マスターテスト計画と他の活動
- 小規模プロジェクトの場合は、1つのレベルのテストを公式としマスターテスト計画をまとめて記述することがある。
- マスターテスト計画にテストに影響する他の活動について記述することがある。
2.4.4 レベルテスト計画
レベルテスト計画には以下の内容を記述する。
- 各テストレベルで実行する特定の活動を記述する。
- テストタイプごとに記述する場合もある。
- マスターテスト計画を詳細化する。
- マスターテスト計画でカバーしていないスケジュール、タスク、マイルストーンの詳細情報を記述する。
公式度合いが低いプロジェクトでは、単一のテスト計画がテストマネジメントドキュメントとなることも多く、レベルテスト計画にいくつかの情報要素を加えて1つのドキュメントとすることもある。
2.4.5 プロジェクトリスクマネジメント
プロジェクトリスクはテストマネージャによって軽減できるものとそうではないもの（プロジェクトマネージャに通知して指示に従うもの）があります。
テストマネージャが対応できるリスク
- テスト環境およびツールの準備
- テストスタッフの調達能力と資質
- テスト活動に対する標準類、ルールおよび技法の欠如
プロジェクトリスクマネジメントへのアプローチ
以下のアプローチ手法が含まれます。
- 早期のテストウェア準備
- テスト環境の事前テスト
- 初期バージョンに対する事前テスト
- 開始基準の厳格化
- 試験性要件の強化
- 早期のプロジェクト成果物のレビューへの参加
- 変更管理への参加
- プロジェクトの進捗および品質のモニタリング
プロジェクトリスクマネジメントのためのオプション
オプションの選択は発生する利点と機会、あるいはコストや追加リスクを考慮して決めます。コンティンジェンシープランが特定された場合の、ベストプラクティスはトリガー（実行条件と方法）と所有者（実行者）を識別することです。
- 可能性や影響を減らす予防対策でリスクを軽減する。
- コンティンジェンシープランを作成して、リスクが現実化した場合の影響を軽減する。
- リスクを別の部門に移して対処する。
- リスクを無視する、または受け入れる。
2.4.6 その他のテスト成果物
テストマネージャは、テストアナリストやテクニカルアナリストが作成する成果物の一貫性と品質を確保する必要があります。
成果物の例
- 欠陥レポート
- テストケース仕様
- テストログ
テストマネージャの活動
- 成果物の品質を監視するメトリクスを確立してモニタリングする（拒否された欠陥レポートの割合など）
- 成果物の適切なテンプレートを選択してカスタマイズする
- 成果物の標準を確立する（テスト、ログ、レポートで必要となる詳細度合いなど）
- ステークホルダによるテスト成果物のレビューを行う
テスト文書化の考慮事項
- ソフトウェア開発ライフサイクル
- 標準と規制
- 開発されるプロダクト品質
- プロジェクトリスク
テンプレート
テスト成果物のテンプレートはIEEE829などの資料に基づいて作成できますが、IEEE829はどの業界でも使用できるように設計されているため、これを改訂して特定の組織で使用できる標準テンプレートを作成することで、組織のプロセスが統一化されトレーニング工数の減少が期待できます。
2.5 テストの見積り
テストの見積りはベストプラクティスをプロジェクトのテスト活動に適用する作業で、マネジメント活動としてのテストの見積りは、プロジェクトの活動に対応するコストと終了日の近似値を作成することを意味します。ただし、ソフトウェア品質が低い場合や未知の場合は見積りは困難になります。
優れた見積りの特徴
- 関連する参加者のサポートが得られる
- コスト、リソース、タスク、人について詳細な一覧を提供できる
- 見積り対象のそれぞれの活動について、最も可能性の高いコスト、工数、期間を算出できる
見積りに影響する要素
テストは一般的にプロジェクトのクリティカルパスのため、テストの見積りは、テスト活動のコスト、工数、期間に影響する以下のような要素を考慮します。
- システムの品質レベル
- システムサイズ
- 過去のテストプロジェクトの履歴データ
- プロセス要因
- 物的要因（ツール、環境、ドキュメントなど）
- 人的要因（マネージャからテスト担当者までのスキル、プロジェクトチームの関係など）
- プロセスの複雑さ、ステークホルダの数、サブチームの構成
- 人員増によるトレーニングやオリエンテーション
- テストウェアの適用や開発
- 詳細度合いの高さ
- コンポーネントの受け入れ
- 使える範囲が限られたテストデータ
見積りの技法
ボトムアップ、トップダウンのどちらでも良く、使用する技法は次のような技法から単独または複数を組み合わせても良い。
- 直感、推測、過去の経験
- ワークブレークダウンストラクチャ(WBS)
- チーム見積りセッション
- 企業の標準及び基準
- プロジェクトの総工数またはスタッフ構成の割合
- 組織のデータ蓄積及びメトリクス
- 業界標準平均及び予測モデル
最終的な見積り
以下の点で優れたバランスを表すものが理想的です。
- 品質
- スケジュール
- 予算
- フィーチャ
また、見積りが利用可能な情報に基づいていることも重要です。
なぜならプロジェクトの初期など情報が十分ではない場合は、プロジェクトが進むにつれて見積りに使用した情報が変化する可能性があります。情報が変化した場合は、見積りの正確性を維持するため、再見積りが必要となります。
花粉症が改善するタウロミン
2018.03.13更新
最近、また少し寒さが戻った感じがしますが、だいぶ暖かくなりました。
そして、花粉症がなければ、最高なのに！と毎年思う季節でもあります。
そこで、私に効果があった花粉症の薬を2つ紹介します。
＊症状や効果には個人差がありますが、参考になればと思います。
ストナリニ
ここ数年お世話になっていたストナリニ。
完全には収まりませんでしたが効果があり、満足はしていました。
タウロミン
今年は妻の薦めもありタウロミンを試してみることに。
まだ飲み始めて2週間程度で、多少の症状は出ますがいいですね。
誰もが良い結果になるというわけではないとは思いますが効果ありです。
体質改善効果があるので、本当は症状が出る前から飲む方が良いみたいですが、
出てから飲み始めても効果はあります。
MACで確定申告(e-Tax)ができないとき
2021.02.19更新
MACを使用したe-Taxでハマったところを備忘録も兼ねて記載します。
普通にMACを使用している人はe-Taxの使用環境に対応していないと思います。
私はSafariのバージョンがダメで、「ご利用の環境ではe-Taxをご利用になれません。」となり、何だよ！と思いましたが、このまま進めることができます。
以下のサイトを参考にさせていただきました。
基本的な準備は確定申告書等作成コーナの手順に従えばできますので、つまづいたところを記載していきたいと思います。
私の使用環境
- Sierra10.12.6
- Safari11.0.3
- ADR-MNICUBK（カードリーダ）
サンワサプライ 接触型ICカードリーダライタ ADR-MNICUBK
申請方法
申告方法にはいくつか種類がありますが、私は確定申告書作成コーナーを利用しました。
他の方法も環境的に私はNGなので回避方法がある申告方法を選択しました。
- 確定申告書作成コーナー
- e-Taxソフト
- e-Taxソフト（Web）
ポイント
下準備は早めに
マイナンバーカードやカードリーダーの接続性確認もあるので、申告書が提出段階ではなくても申告できる環境の下準備だけは早めに実施しておくことを強く推奨します。
私の場合、書類の方はやること少ないのですが、こちらの方に時間がかかりました。
Safari11で申請するための設定
[環境設定]-[Webサイト]からJavaを選択して、e-Taxのサイトの設定（右側のリスト）をoptionを押しながら選択すると表示される「安全なモードで実行」のチェックを外します。この設定を変更していないと、電子証明書の再登録をするときに、利用者識別番号を入力後の暗証番号入力時のポップアップが表示されませんでした。
再登録しない場合でも、この設定は変更しておきましょう。
そして、e-Taxによる申告が終了したら元の設定に戻しておくようにしましょう。
書類提出時の暗証番号入力
書類提出時にも暗証番号の入力が必要です。このときは暗証番号欄にキー入力できない事象が発生しました（上記の設定がしてあっても）。どうしようもないので、テキストエディタに打ち込んだ暗証番号をコピペすることで進めることができました。
原因はよくわかりません。
以上、私がつまづいたところでした。
環境によって正常に動作しない場合があるかもしれませんので、 必ずうまくいくという保証はできませんが、参考になればと思います。
