Recommended
More Related Content
Similar to 【JSTQB_ALTM】シラバス第1章
【JSTQB_ALTM】シラバス第1章
- 1. テストプロセスとは？ Foundation Level 1. 計画とコントロール 2. 分析と設計 3. 実装と実行 4. 終了基準の評価とレポート 5. 終了作業 Advanced Level 1. 計画、モニタリング、およびコントロール 2. 分析 3. 設計 4. 実装 5. 実行 6. 終了基準の評価とレポート 7. 終了作業
- 2. 1.2：テストの計画作業、モニタリング、およびコントロール テスト計画作業 ○ 何をやるの？ ■ 採用するテストレベル、各レベルの目標と目的、テストアプローチ（テスト 技法など）の定義 ■ そのテストの目的を達成するための活動＆リソースの特定 ■ 計画順守や目的達成の判断基準となるメトリクスやその収集方法の特定 ■ テストスコープの特定と一覧化 ※特にスコープ外 ■ （必要に応じて）外部とのリソース調整 ○ いつやるの？ ■ 各テストレベルのテストプロセス「全体を通して」継続する
- 3. 1.2：テストの計画作業、モニタリング、およびコントロール テストのモニタリングとコントロール ○ テストを効率的にコントロールするためには ■ テスト成果物＆リソースを、計画と比較できるようにする ● その為に、モニタリングの仕組みを確立する ○ 小規模PJなら「テスト成果物＆活動」⇔「計画＆目的」の関連付けは容易 ■ しかし関連付けのためには、目的をより詳細に定義する必要があるケースが多い ○ テスト成果物＆活動とテストベース（要件や仕様など）との関連付けは ステークホルダが理解可能であることが重要 ● トレーサビリティを確保し、開発成果物⇔テストベース⇔テスト成果物の関 係性をわかりやすくする
- 4. 1.2：テストの計画作業、モニタリング、およびコントロール テストのモニタリングとコントロール ○ ステークホルダが「モニタリングしてもらいたい」と思うものが、 システムの機能＆仕様に関連していない場合もある ■ 例）プロダクト仕様→システム機能の観点で定義 ■ ステークホルダが求めるもの→運用上のビジネスサイクルに対する カバレッジの達成 ● ステークホルダにはPJの初期段階から関わってもらうことで、モニタリ ング対象を一緒に定義することができる
- 5. 1.2：テストの計画作業、モニタリング、およびコントロール テストのモニタリングとコントロール ○ テストコントロール＝以下を継続的に行うこと ■ 計画と、実際の進捗の比較 ■ （必要なら）是正措置対応
- 7. 1.3：テスト分析 ● テスト分析とは ○ 「何をテストするか」を定義する活動 ● テスト分析の成果物 ○ テスト条件 ● どのようにテスト条件を洗い出していくか？ ○ 以下の分析 ■ テストベース ■ テスト目的 ■ プロダクトリスク
- 8. 1.3：テスト分析 ● テスト条件は、成功のための測定内容やテスト終了基準の1つとみなせる ○ そのため、テスト目的や戦略目的、PJやステークホルダーの基準などに 遡れることが重要 ● また、テスト条件はその他のテスト成果物（テストケースなど）を追跡でき る（関連付けられている）必要がある
- 9. 1.3：テスト分析 ● テスト分析はいつ開始できる？ ○ そのテストレベルのテストベースが確立されればすぐに ● テスト分析はどうやったらできる？ ○ テスト技法の活用 ○ 分析技法の活用 ■ リスクベースド戦略 ※第2章「テストマネジメント」にて説明 ■ 要件ベースド戦略 ※第2章「テストマネジメント」にて説明
- 10. 1.3：テスト分析 ● テスト条件の詳細度合いの決定について ○ 以下要因を考慮する必要がある ※一部抜粋 ■ テストレベル（UT/IT/STなど） ■ テストベースの詳細度と品質 ■ システム（ソフトウェア）の複雑性 ■ PJリスクとプロダクトリスク ■ 使用する開発ライフサイクルやテストマネジメントツール ■ テストアナリストのスキル＆知識 ■ テストプロセスや組織自体の成熟度
- 11. 1.3：テスト分析 ● テスト条件を細かく指定するメリット ■ テスト成果物とテストベース・目的との関連付けが柔軟になる ● より細かく適切なモニタリング＆コントロールが可能に ■ （早期に分析を行うことで）欠陥の防止に貢献できる ■ テスト成果物をビジネスステークホルダが理解しやすくなる ■ 他の開発活動を導くのに役立つ ■ より最適化したテスト成果物を作れる ● 各テスト活動にて、詳細な測定＆効率的な網羅ができるため ■ より明確なトレーサビリティを提供できる
- 12. 1.3：テスト分析 ● テスト条件を細かく指定するデメリット ■ 時間がかかる ■ 保守が困難になる ■ 形式化のレベルをチーム全体で定義する必要がある
- 13. 1.3：テスト分析 ● 詳細なテスト条件が有効なケース ○ 簡易的なテスト設計文書化方式を使用している（チェックリストなど） ○ 要件や開発成果物が、テストベースとして使えない場合 ○ PJが大規模or高リスクである場合 ● 概略的なテスト条件を使用できるケース ○ 単体テスト ○ 複雑性の低いPJ ○ ユースケースを活用可能な受入テスト
- 14. 1.4：テスト設計 ● テスト設計とは ○ 「どうテストするか」を定義する活動 ■ （FYI）テスト分析は「何をテストするか」 ● テスト設計の成果物 ○ テストケース ■ （FYI）テスト分析の成果物は「テスト条件」 ● 特徴 ○ テストケースはテストベースや目的に関連付けられる場合がある
- 15. ● テスト設計はいつ開始できる？ ○ テスト条件を識別し、テストケースを作るための情報が揃った後 ● 上位テストレベルのテスト ○ テスト設計が独立した活動になる（可能性が高い） ● 下位テストレベルのテスト ○ テスト分析と設計を統合して実行する（可能性が高い） ● 反復的アプローチを使ってテストを作成する場合 ○ テスト実装で行う活動の一部をテスト設計に統合する可能性がある （例：テストデータ作成） 1.4：テスト設計
- 16. 1.5：テスト実装 ● テスト実装とは ○ テスト設計の内容を、具体的なテストケース、テスト手順、テストデー タとして実装する活動 ■ （FYI）テスト分析は「何をテストするか」 ■ （FYI）テスト設計は「どうテストするか」 ● テスト実装の成果物 ○ テストケース（入力と期待結果）、テスト手順、テストデータ ■ （FYI）テスト分析の成果物は「テスト条件」 ■ （FYI）テスト設計の成果物は「テストケース」
- 17. ● テスト実装には「テスト実行する準備が整っていることの確認」も含む ○ 必要なテスト環境＆データ＆テストコードが整っていること ○ テストケースが作成＆レビュー済であり、実行の準備が整っていること ○ 明示的、暗黙的な開始基準のチェック ● テスト実装作業の詳細度や複雑性は、テスト成果物（テストケースやテスト 条件）の詳細度に影響される ○ 回帰テストでは、テスト実行手順の詳細な説明が必要になる場合もある ■ 誰がやっても同じテストが実行されるようにするため ○ 法規制への適用が求められる場合、テストがそれに適合しているエビデ ンスを示す必要がある 1.5：テスト実装
- 18. ● テスト実行スケジュールには、テスト実行順序を含める必要がある ○ そのため、テストマネージャは下記を理解しておく ■ 特定の順序でテストを実行する必要性やその優先度 ■ テスト環境やテストデータの依存関係 ● 早期のテスト実装のメリット/デメリット ○ メリット ■ 設計者や開発者に対し、必要とされる動作を明確に説明できる ○ デメリット ■ 頻繁な保守が必要になったり、実装作業が無駄になる可能性がある （変更が頻繁に発生するPJでは） 1.5：テスト実装
- 19. ● いつから実行できるか？ ○ テスト対象が受け渡され、開始基準を満たした時 ● テスト実行におけるテストマネージャの役割 ○ テスト計画に従って進捗をモニタリング ○ （必要に応じて）テスト成功のためのコントロール 1.5：テスト実装
- 20. ● テスト実行を効率的に進めるため、事前に準備しておくこと ○ テスト設計&定義 ○ ツールの用意 ■ テストマネジメント、欠陥追跡、自動化といった目的のため ○ テスト結果追跡方法の確立 ■ 追跡データに対するメンバーの理解 ○ テスト実行結果記録および欠陥レポートの使用＆公開 1.5：テスト実装
- 21. ● テスト実行手順について ○ 原則はテスト手順に従うべきだが、担当者には自由裁量も与えられる ■ テスト中に見られた興味深い振る舞いや、追加テストシナリオを網 羅するため ● 未記述のテストで検知した故障は、故障の再現のため、記述し たテストケースとの差異を説明できるようにしておく 1.6：テスト実行
- 22. 1.7：終了基準の評価とレポート ● 詳細は2章で説明 ● テストプロセスの観点においては、「終了基準の評価とレポート」を行うた めの情報を、効率的に収集できる仕組み作りが重要 ○ 仕組み作りは「テスト計画＆モニタリング及びコントロール」の一環 ○ 効率的な情報収集のためにテストマネージャが必要なこと ■ テスト担当者への的確な情報提供 ● レポートの頻度や粒度は、PJや組織によって異なる ○ テスト計画段階でステークホルダーと予め協議すること
- 23. 1.8：テスト終了作業 ● テスト終了時に行う主な作業 ○ テスト完了チェック ■ 全てのテストが実行済みか ■ 未修整の欠陥は対応方針が決まっているか など ○ テスト成果物の提供 ○ 振り返りMTGの実施、ナレッジのドキュメント化 ○ 構成管理システムにてドキュメントや成果物の保管
- 24. ● テスト終了作業は重要ではあるものの、実施されないケースがある ○ したがって、テスト計画の一部として明確に盛り込む必要がある ○ 契約下で行われる作業（受託開発など）では、必須タスクとして盛り込 む必要がある ● テスト終了作業が実施されない主な理由 ○ チームの解散が早すぎた ○ 以後のスケジュールやリソースが切羽詰まっていた ○ チームが燃え尽き症候群に陥った 1.8：テスト終了作業