はじめに

続編です。（余力できてきたので再開）

1. テストを学びたくてJSTQBのFLシラバスを読んでみた〜その1 テストの基礎〜
2. テストを学びたくてJSTQBのFLシラバスを読んでみた〜その2 ソフトウェア開発ライフサイクル全体を通してのテスト〜
3. テストを学びたくてJSTQBのFLシラバスを読んでみた〜その3 静的テスト〜
4. テストを学びたくてJSTQBのFLシラバスを読んでみた〜その4 テスト技法〜
5. テストを学びたくてJSTQBのFLシラバスを読んでみた〜その5 テストマネジメント〜　←　ここ

注意事項

あくまで、JSTQBのFLシラバス理解に向けた個人的メモです。
「これを読んだら FLシラバスが習得できます！」とかじゃないです。全然違います。
当然ですけど、こんな記事より「JSTQBのHP - JSTQB公認研修コース」に参加するのが正しい道です。（もしくは自力でシラバスを読むか。）
※本記事は「Foundation Level シラバス 日本語版 Version 2018.J03」を対象にしています。

5 テストマネジメント

225min

5.1 テスト組織

K2 独立したテストの利点と欠点を説明する。

ある程度の独立性を確立すると、開発者とテスト担当者の間の認知バイアスの違い（1.5 節を参照）によって、テスト担当者はより効果的に欠陥を発見できる。
ただし、独立性は熟知していることの代わりにはならない。開発担当者は自分のコードにある多くの欠陥を効率的に検出できる。

独立性と、熟知度合いのバランスが大事ということかな？
スクラムとかだと、テスト担当者も一緒にチーム組むこともあるだろうけど、そっちはどうなんだろう。アジャイルシラバスを後ほど見てみよう。
と思ったら書いてあった。

例えば、アジャイル開発では、テスト担当者を開発チームに参加させる場合がある。
アジャイルの手法を使う組織によっては、このようなテスト担当者をより大きな独立したテストチームの一員とみなすこともある。
さらに、このような組織では、プロダクトオーナーが各イテレーションの終わりに受け入れテストを実行して、ユーザーストーリーの妥当性確認をすることがある。

チームを跨いだ形で、テストチームを作るって感じかな？

独立したテストの利点

• 独立したテスト担当者は、開発担当者とは異なる背景、技術的視点、バイアスを持つため、開発担当者とは異なる種類の故障を検出する可能性が高い。
• 独立したテスト担当者は、仕様作成時および実装時にステークホルダーが行った仮定について、検証、説明の要求、または反証を行うことができる。

独立したテストの欠点

• 開発チームから隔絶されると、協力関係の欠落、開発チームへのフィードバック提供の遅延、開発チームとの対立を招くことがある。
• 開発担当者の品質に対する責任感が薄れることがある。
• 独立したテスト担当者は、ボトルネックとして見られたり、リリース遅延で責任を問われたりすることがある。
• 独立したテスト担当者にテスト対象の情報などの重要な情報が伝わらないことがある。

わかる。

多くの組織が欠点を回避することで、テストの独立性の利点を達成できる。

回避方法が知りたいんだけど、テストマネジメントのシラバスとかにあるのかな・・・？

K1 テストマネージャーとテスト担当者の作業を識別する。

テストマネージャー

◆組織へのアプローチ

• 組織のテストポリシーやテスト戦略を開発もしくはレビューする。

テストポリシーとか、テスト戦略とは？ってのは、テストマネジメントのシラバスにある様子。
FLでは「そういうのがある」くらいの理解で良ということか？

テスト戦略の立て方についてはこれを参考にするのが良さそう。
現場の力をメキメキ引き出すテスト戦略 @JaSST'10 Hokkaido by 湯本 剛

◆テスト計画

• プロジェクトの背景を考慮した上で、テスト目的とリスクを理解してテスト活動を計画する。これにはテストアプローチの選択、テストにかかる時間／工数／コストの見積り、リソースの獲得、テストレベルやテストサイクルの定義、欠陥マネジメントの計画を含む。
• テスト計画書を作成し更新する。
• プロジェクトマネージャー、プロダクトオーナーなどの間でテスト計画書の内容を調整する。
• テスト側の考え方を、統合計画などの他のプロジェクト活動と共有する。

テスト計画自体については、以下あたりをもう少し読まないと理解できてない感じがある。

• テスト計画書について　ー　全体テスト計画を語る夕べ　－
• 現場の仕事がバリバリ進む ソフトウェアテスト手法

◆モニタリング・レポーティング・計画修正

• テストの分析、設計、実装、実行の開始を宣言し、テスト進捗とテスト結果をモニタリングし、終了基準（または完了（done）の定義）のステータスを確認する。
• テスト進捗レポートとテストサマリーレポートを、収集した情報に基づいて準備し配布する。
• （テスト進捗レポートおよび／またはプロジェクトで既に完了しているテストのテストサマリーレポートで報告済みの）テスト結果やテスト進捗に基づいて計画を修正し、テストコントロールのために必要なあらゆる対策を講じる。
• テスト進捗の計測、およびテストや対象プロダクトの品質の評価のために、適切なメトリクスを導入する。

目的は理解できる。
計画を修正せず、稼働率を上げることで実績を間に合わせるようなプロジェクトに関わったことあるけど、そういうのはダメだよね、やっぱり。
自分が所属してるのはちゃんと計画含め見直しするような動きができてるけど、もっとうまいことやりたい。
そのためにはポリシーと戦略が必要なんだろうなぁと漠然と感じ始めてる。

◆ツール・環境の用意・支援

• 欠陥マネジメントシステムのセットアップと、テストウェアの適切な構成管理を支援する。
• テストプロセスで使うツールの選択と実装を支援する。これには、ツール選択（および、購入および／またはサポート）のための予算の提案、パイロットプロジェクトのための時間と工数の割り当て、継続的なツール使用支援の提供を含む。
• 構築するテスト環境を決定する。

はい。

◆育成・トレーニング

• 組織内のテスト担当者、テストチーム、テスト専門職を昇格および支持する。
• テスト担当者のスキルアップとキャリアアップを促す（トレーニング計画、業績評価、コーチングなどを使用）。

はい。

テスト担当者

◆テスト計画への貢献

• テスト計画書のレビューによって貢献する。

◆分析・整理

• 試験性のために、要件、ユーザーストーリーと受け入れ基準、仕様、モデル（すなわち、テストベース）を分析し、レビューし、評価する。
• テスト条件を識別して文書化し、テストケース、テスト条件、テストベースの間のトレーサビリティを確立する。

◆テスト準備・実行

• 詳細なテスト実行スケジュールを作成する。
• テスト環境（システムアドミニストレーションやネットワークマネジメントと協調する場合が多い）を設計、セットアップし、検証する。
• テストケースとテスト手順を設計し実装する。
• テストデータを作成、および入手する。
• 他の人が開発したテストケースをレビューする。

◆評価

• テストケースを実行し、結果を評価して、期待結果からの逸脱を文書化する。
• 性能効率性、信頼性、使用性、セキュリティ、互換性、移植性などの非機能特性を評価する。

◆改善

• 適切なツールを使用して、テストプロセスを円滑にする。
• 必要に応じてテストを自動化する（開発担当者や、テスト自動化の専門家の支援が必要な場合がある）。

概ねイメージできたのでコメントは割愛。

5.2 テストの計画と見積り

K2 テスト計画書の目的と内容を要約する。

テスト計画書では、開発プロジェクトやメンテナンスプロジェクトのテスト活動を概説する。
計画は組織のテストポリシーやテスト戦略、使用する開発ライフサイクルや手法（2.1 節を参照）、テストの範囲、目的、リスク、制約、クリティカルな度合い、試験性（テストを容易にするための考慮）、リソースの調達に基づく。

はい。前述の部分で調べちゃったので、なんとなくわかった気になってる。
（一方で、作れと言われたら作れそうにないので、本質的には理解できてないのも分かってるが、ひとまず後回し。）

K2 さまざまなテスト戦略の違いを明確にする。

テスト戦略は、通常、プロダクトまたは組織のレベルでの、テストプロセスに関する汎用的な考え方を提供する。テスト戦略の一般的な種類は以下の通りである。

• 分析的：リスクのレベルに基づいてテストを設計し優先度付けするリスクベースドテストなど。
• モデルベースド：例えば、機能、ビジネスプロセス、内部構造、非機能特性（信頼性など）などに基づいて、テストを設計する。
• 系統的：事前に定義した一連のテストケースまたはテスト条件を体系的に使用する。
• プロセス準拠（または標準準拠）：外部のルールや標準を使用してテストの分析、設計、実装を行う。
• 指導ベース（コンサルテーションベース）：テストチームの外部または組織自体の外部の専門家からの助言に基づいてテストを行う。
• リグレッション回避：既存では実現されていた能力のリグレッションを避けることを目的とする。
• 対処的：テスト対象のコンポーネントやシステム、テスト実行時に発生するイベントに対して対処的にテストを行う。他の戦略とは異なり、テストは事前に計画されない。

どれか単独ってことはない気がする。複合して使うんだろうか。

適切なテスト戦略は、これらの種類のテスト戦略を複数組み合わせて構築する。

やっぱりね！（ドヤ顔）

テスト戦略はテストプロセスを汎用的に説明したものであり、テストアプローチは特定のプロジェクトまたはリリース用にテスト戦略をテーラリングしたものである。

テスト戦略をテーラリングした結果のアウトプットとして、テストアプローチが生まれるということか。
テスト戦略はプロジェクト固有じゃないのか。（テスト戦略のことを全然分かってないことにここで気づく。）
ムムム。テストマネジメントシラバスで勉強するために、取っておこう。（そこまで手が出せない・・・）

K2 可能性のある開始基準と終了基準の例を示す。

開始基準：Ready条件。Readyじゃない状態で開始すると手戻りが発生したり、難しい状況が生まれやすい。
終了基準：Doneの定義。

終了基準を満たしていない場合でも、消費済みの予算、費やした時間、そして／またはプロダクトを市場に送り出すプレッシャーにより、テスト活動を切り上げることが一般的に行われる。
プロジェクトステークホルダーやビジネスオーナーが、テストの追加なしでプロダクトをリリースするリスクを見直しして受け入れた場合には、このような状況でもテストを終了できる。

あんまり経験したこと無いなー。

K3 ある特定のテストケースのセットに対するテスト実行のスケジュールを立てるため、優先順位付けの知識、技術的および論理的な依存関係の知識を適用する。

基本は優先度にしたがって実施。ただし、依存関係がある場合は依存関係を加味する必要あり。
その上で、もっとも効率的な順序を検討する。
（この時点の効率は、単に作業効率というよりは、「リスク等を加味した上でのプロジェクト全体としての効率」という意味合いだと思われる。）

確認テストやリグレッションテストは、変更に関する迅速なフィードバックの重要性に応じて優先度を割り当てる。ただし、この場合も依存関係を考慮する。

まぁそうですよね。

K1 テストに関連する工数に影響を与える要因を識別する

• プロダクトの特性：例えば、金融系だとかなり重厚なテストが必要だよね、とか。
• 開発プロセスの特性：慣れてないツールやプロセスの場合は、手間取るよね。
• 人の特性：メンバーのスキルや知識によって、効率は変わってくるよね。（一次品質はもちろん、不具合検出〜修正のスピードも）
• テスト結果：手戻りのこと。

K2 メトリクスを使った見積りと専門家による見積りの違いを説明する。

• メトリクスを使った見積もり：以前の類似したプロジェクトのメトリクスや、典型的な値を基にしてテスト工数を見積る。
• 専門家による見積もり：テストのタスクの所有者の経験、または専門家による見積りを基にしてテスト工数を見積る。

スクラムで言えば、バーンダウンは「メトリクスによる見積もり」だけど、スプリントポイント算出におけるプランニングポーカーは「専門家による見積もり」と言える。
両方使うのが良いんだろうな、って感覚。（見積もりは複数の手法で行うのが良いって、ばっちゃが言ってた。）

5.3 テストのモニタリングとコントロール

K1 テストで使用するメトリクスを想起する。

メトリクスは各テスト活動の期間中、および終了時に収集できる、以下の項目を評価する。

• 計画したスケジュールや予算に対する進捗
• テスト対象の現在の品質
• テストアプローチの十分性
• テスト目的に対するテスト活動の効果

「テスト目的に対するテスト活動の効果」って例えば・・・？とか一瞬よぎったけど、そんなん目的によるわな。

K2 テストレポートの目的、内容、および読み手を要約する。

テストレポートは大きくは二種類。テスト進捗レポートと、テストサマリーレポート。

典型的にテスト進捗レポートとテストサマリーレポートに含まれるものは以下の通り。

• 行ったテストの要約
• テスト期間中に発生したこと
• 計画からの逸脱（テスト活動のスケジュール、期間もしくは工数など）
• 終了基準または完了（done）の定義に対するテストとプロダクト品質の状況
• 進捗を妨げた、または引き続き妨げている要因
• 欠陥、テストケース、テストカバレッジ、活動進捗、リソース消費のメトリクス（例えば、5.3.1で示したメトリクス）
• 残存リスク（5.5 節を参照）
• 再利用可能なテスト作業成果物

概ね想像通り。

記述する情報の種類と量は、技術に精通した読み手またはテストチームを対象にする場合と経営者向けのサマリーレポートでは異なる。

そうでしょうね。ここも具体的なところはテストマネジメントのシラバスなのかな・・・？

5.4 構成管理

K2 構成管理がテストをどのように支援するかを要約する。

構成管理の目的は、プロジェクトやプロダクトのライフサイクルを通じて、コンポーネントやシステムの完全性、テストウェア、およびそれら相互の関係を確立し、維持することである。

アプリケーションで構成管理っていうと、コードやドキュメントのバージョン管理と、システム構造の維持管理とかあるけど、テストも同じってことか。
テスト成果物および、テスト実行環境とか、トレーサビリティとか諸々だろうな。

テストを適切に支援するために、構成管理では、以下を明確にする。

• 全テストアイテムを一意に識別して、バージョンコントロールを行い、変更履歴を残し、各アイテム間を関連付ける。
• テストウェアの全アイテムを一意に識別して、バージョンコントロールを行い、変更履歴を残し、各アイテム間を関連付ける。また、テストアイテムのバージョンとの関連付けを行い、テストプロセスを通してトレーサビリティを維持できる。
• 識別したすべてのドキュメントやソフトウェアアイテムは、テストドキュメントに明確に記載してある。

はい。

5.5 リスクとテスト

K1 可能性と影響を考慮してリスクレベルを定義する。

リスクは、将来に否定的な結果となる事象が起きる恐れを含む。リスクのレベルは、そのような事象が起きる可能性とその影響（事象による結果がもたらす損害）で決まる。

この一文だけなのに、章として区切られてるってのは、それだけ大事ってことなんかな？
「恐れを含む」ってのはどういう意味だろう？
「否定的な結果を起こしうる事象（発生が確定していないものを含む）」という意味か、「否定的な結果を起こしうる事象にたいして不安に思う気持ちも含む」という意味か・・・

ちょっと深読みしすぎな気もするけど、一応英文見るか。

Risk involves the possibility of an event in the future which has negative consequences. The level of risk
is determined by the likelihood of the event and the impact (the harm) from that event.

possibilityだから、前者だな。
案の定、深読みしすぎたやつだ。

K2 プロジェクトリスクとプロダクトリスクの違いを認識する。

プロダクトリスクは、作業成果物（例えば、仕様、コンポーネント、システム、テストケース）がユーザー、および／またはステークホルダーの正当なニーズを満たすことができない恐れを含む。
プロダクトリスクの例には以下のものが含まれる。

• ソフトウェアの意図されている機能が仕様通りには動かないかもしれない 。
• ソフトウェアの意図されている機能がユーザー、顧客、および／またはステークホルダーのニーズ通りには動かないかもしれない。
• システムアーキテクチャーが非機能要件を十分にサポートしないことがある。
• 特定の計算結果が状況によって正しくないことがある。
• ループ制御構造が正しくコーディングされていないことがある。
• 高性能トランザクション処理システムで応答時間が適切でないことがある。
• ユーザーエクスペリエンス（UX）のフィードバックがプロダクトの期待と異なるかもしれない。

最終的に出来上がるプロダクトのリスクってことっすね。了解です。

プロジェクトリスクは、発生した場合にプロジェクトの目的達成に悪影響を与える。
プロジェクトリスクの例には以下のものが含まれる。

• プロジェクトの懸念事項：遅延、資金不足、炎上。
• 組織の懸念事項：人員不足、スキル不足、人間関係、要員調整。
• 政治的な懸念事項：うまく伝えられない、改善されない、真摯に受け止めない。
• 技術的な懸念事項：曖昧な要件、制約、環境準備の遅延、支援の遅れ、選択した開発プロセスの弱点、技術的負債の累積。
• 供給者側の懸念事項：利用サービスの撤退、契約関連。

いわゆるプロジェクトマネジメントに関わるリスクのことだと理解。

K2 プロダクトリスク分析がテストの十分さ、およびテストの範囲にどのように影響するか例を挙げて説明する。

リスクベースドテストでは、プロダクトリスクの分析を行うために、プロジェクトのステークホルダーの総合的な知識や洞察力を必要とする。プロダクトが故障を起こす可能性を最小にするため、リスクマネジメントでは、以下のように、きちんと決まったアプローチを備えている必要がある。

• どこが上手くいかないか（リスク）を分析する（定期的に再評価する）。
• リスクの重要度を決める。
• 重大なリスクを処理する方法を実装する。
• リスクが実際に事象として発生した場合に備えてコンティンジェンシープランを作る。

他にもテスト戦略の種類はあるはずなのに、リスクベースドテストはわざわざ取り上げられるのか。
雰囲気はわかるけど、実践にたる知識にはなってない。が、それはテストマネジメントのシラバスなんだろうな。

5.6 欠陥マネジメント

K3 テスト時に見つかった欠陥を修正するために欠陥レポートを記述する。

テストの目的の 1 つは欠陥を検出することであるため、テスト時に見つかった欠陥は記録を残す必要がある。欠陥を記録する方法は、テスト対象のコンポーネントまたはシステム、テストレベル、ソフトウェア開発ライフサイクルモデルなどの要因により異なる。

そっすね。バグトラッキングシステム（BTS）で有名なのはRedmineとかかな。Jiraも来てる気がする。

典型的な欠陥レポートには、以下のような目的がある。

• 開発担当者や他の関係者に対して、発生したあらゆる期待に反する事象についての情報を提供する。また、必要に応じて、もしくは問題を解決するために、具体的な影響を識別して、最小の再現テストで問題の切り分けを行い、欠陥の修正ができるようにする。
• テストマネージャーに対し、作業成果物の品質や、テストへの影響を追跡する手段を提供する（欠陥の報告数が多いと、テスト担当者は多くの時間をテスト実行ではなく報告作業に費やす必要があり、さらに多くの確認テストが必要になる）。
• 開発プロセスとテストプロセスを改善するためのヒントを提供する。

まぁ、そうですよね。って感覚。

動的テスト時の欠陥レポートには、一般的に以下の情報を記入する。
(ちょっと数が多いので割愛)

欠陥管理って面倒なんだよなー。
一覧項目いっぱい埋めないといけないのに、役に立ってる感が薄い。
フィードバックになってない項目が多いからだろうな。。。

フィードバックする仕組みと、不要な項目の削除はちょっと考えなきゃなぁ。

さいごに

今回も225minどころじゃないくらい時間かかっている・・・
でも、次回で最後！！！！！

継続して考え続けたい
（ゴールイメージがそこまで沸いてないもの）

• 結構テストマネジメントのシラバスで触れられることが多い内容だったので、そっちをちゃんと読もう。
• 欠陥管理において、開発者へのフィードバック方法の検討（合わせて、不要項目を削除。）

以上です。