Recommended
More Related Content
Similar to 【JSTQB_Advanced Level_TestManager】シラバス第6章
Similar to 【JSTQB_Advanced Level_TestManager】シラバス第6章 (15)
More from ssusercd6d02
【JSTQB_Advanced Level_TestManager】シラバス第6章
- 4. 6.2:ツール選択 • テストツールの主な選択肢 ①：商用ベンダーからのツール購入 ②：オープンソースツール ③：カスタムツール • どのツールを使うにしても、コストとメリットの分析が必要 • 詳細は「6.2.3 投資効果（ROI）」にて説明
- 8. 6.2.1:オープンソースツール • 使用するツールのライセンススキームを理解する必要がある • 多くのオープンソースツールには 「GNU一般公衆利用許諾契約書」が存在する • 「ツールを変更した場合、その変更を全ユーザーが利用できるよう にする必要がある」というもの • 自チームが行った変更を再配布することに伴う法的問題点を確 認する必要がある
- 11. 6.2.2:カスタムツール • カスタムツールの開発を検討すべき状況 • ベンダーツールやオープンソースツールでは対応できないニーズがある • 利点 • チームのニーズに合わせられる • 特徴 • 以下の機能を実装できる • 他のツールと連携する機能 • データ作成機能 • 他のPJにも流用できる • ただし、目的やメリデメの検討が必要
- 12. 6.2.2:カスタムツール • 導入時には、マイナス面の考慮も必要 • 例） • 作成者以外がメンテナンスできるよう、文書化が必要 • 利用目的の変化やツールの機能拡張により、 ツールに品質上の問題が発生する 「カスタムツールもソフトウェアの1つである」 「他のプロダクトと同様、開発上の問題が発生しうる」 「カスタムツールにもテストが必要」
- 14. 6.2.3:投資効果（ROI） • ツール導入における、TMの責任 • ①ツールがチームの作業に付加価値をもたらすこと • ②組織にプラスのROIが出るようにすること • 常に効果（利点）が発揮できるよう、導入前に 初期コストと固定費からコストメリット分析を行う • ツールが実運用できるまでは、ツール導入と実務（テスト業務）の ダブルコストがかかる点に注意 • 複数のツールを使うケースが一般的。故に... • ツール同士を連携して動作させること • 使用する全ツールの相関関係から総ROIを計算すること • 長期にわたる包括的なテストツール戦略をとること
- 15. 6.2.3:投資効果（ROI） 初期コスト 固定費 ツール要件の定義 ツール所有コスト （利用料金・メンテコスト・ トレーニング/メンタリングコスト） ツールおよびベンダーの選定 ツールの購入・適用・開発 他環境へのツールの移植 初期トレーニング 将来のニーズへのツールの適用 他のツールとの統合 ツールを最適に使用するための、 品質とプロセスの改善 ツールサポートに必要な ハード/ソフトウェアの購入 • ツール使用時の主なコスト
- 16. 6.2.3:投資効果（ROI） # リスク 説 明 1 チームが未成熟 組織がツールを使う準備が整っていない 2 成果物のメンテナンスが 困難になる可能性 テスト中のソフトウェアが変更されることにより、ツール による成果物に複数の版が必要になるため 3 テスト価値の低下 Test Analystのテストタスクへのコミット減少により。 例）自動化したスクリプトを実行しているときのみ、欠陥 検出の効率が低下してしまうなど • ツール使用時に考慮すべきリスク
- 17. 6.2.3:投資効果（ROI） # 利 点 説 明 1 反復作業の減少 - 2 テストサイクル時間の削減 - 3 テスト実行コストの削減 - 4 特定のテストタイプの実行数の増加 回帰テストなど • ツールの利点（1/2）
- 18. 6.2.3:投資効果（ROI） # 利 点 説 明 5 人的エラーの減少 ・データ生成ツールによる、テストデータの有効性向上 ・比較ツールによる、テスト結果比較時の精度向上 ・スクリプトツールによる、テストデータ入力の正確性向上 6 テストに関する情報にアクセスするた めに必要な工数の削減 ・ツールにより生成されたレポートおよびメトリクス ・テストケース、テストデータなどのテスト資産の再利用 7 可能になるテストタイプの増加 性能テスト、ロードテストなど 8 自動化を実現したテスト担当者の地位 および テスト組織全体の地位の向上 - • ツールの利点（2/2）
- 20. 6.2.4:選択プロセス • テストツールは長期投資になり得る • TMはツールの候補を、様々な観点から検討する必要がある 誰（何）にとって ツールのあるべき姿 必要なこと ビジネス ・プラスのROIであること ・高い価値を得るために、ツール同士を相互 運用すること ・その為にツール利用プロセスを改善するこ と プロジェクト ・効率的であること ・ツールの投資効果が現れるまでには、長い 時間がかかることの認識 ツールのユーザー ・タスクをより効率的/効果 的に行えるようになること ・最小限のストレスでツール を学習できること ・トレーニングとメンタリング
- 22. 6.2.4:選択プロセス • 各ツールに対する、評価のポイント（1/3） カテゴリ 評価すべき能力 備考 分析 与えられる入力を「理解」できるか？ 目的に合致しているか？ 設計 既存の情報に基づいて テストウェア設計を支援するか 要件からテストケースを生成するテスト 設計ツールなど 自動的に設計が行えるか？ 実際のテストウェアコードは、メンテナ ンスおよび使用が可能な形式で、全部あ るいは一部が生成されるか？ 必要なテストデータは、自動的に生成さ れるか？ コードを解析しデータを生成できるか
- 23. 6.2.4:選択プロセス • 各ツールに対する、評価のポイント（2/3） カテゴリ 評価すべき能力 備考 データと テストの 選択 必要なデータをどのように選択するか？ どのテストケースがどのデータセットを 使用して実行するかなど 手動または自動で入力した選択条件を受 け付けるか？ 選択した入力に基づいて運用データを 「選別」する方法を決定できるか？ 要件からテストケースを生成するテスト 設計ツールなど カバレッジ基準に基づいて 必要なテストを決定できるか 指定した要件セットに基づいてトレーサ ビリティを検証し、実行するテストケー スを決定できるかなど
- 24. 6.2.4:選択プロセス • 各ツールに対する、評価のポイント（3/3） カテゴリ 評価すべき能力 備考 実行 自動実行できるか？ どのように停止し再起動するか？ 関連するイベントを「把握」できるか？ テストケースに対しレポートされた欠陥 をクローズした場合に、自動的にテスト ケースのステータスを更新できるかなど 評価 適切な結果を受け取っているかどうかを どのように確認できるか たとえば、テストオラクルを使用して応 答の正しさを確認できるかなど どのような種類のエラー回復能力を提供 するか？ 適切なログ記録およびレポートの機能が 用意されているか？
- 26. 6.3:ツールのライフサイクル • TMがマネジメントすべき、ツールのライフサイクル • 正常に機能し、サービスが故障なく提供されるようにする ＃ STEP 説 明 1 調達 ● ツール管理者のアサイン ● ツールの利用方法・成果物の格納場所・命名規則などの決定 ● ツールのユーザーへのトレーニング 2 サポートと メンテナンス ● ツール維持の責任者のアサイン（管理者or専門のグループ） ● 連携して動作するためのプロセスの検討（ツール同士の連携時） ● バックアップ、リストア、その出力の検討 3 進化 ● 外部要因（環境、ニーズ、ベンダーの問題）への対応 ● ツールの継続性の確率 4 廃棄 ● ツールの置換 ● データの保持・アーカイブ
- 28. 6.4:ツールのメトリクス • 様々なツールでリアルタイムデータを取得可能 • これらのデータを用いて全体的なテスト活動をマネジメントできる • 重点的に収集するデータの種類は、ツールにより異なる（後述） • ツールのレポート要件は、「ツール選択プロセス」で定義する • これらの要件をツール構成時に適切に実装し、提供された情報はステー クホルダに理解できる形でレポートする必要がある
- 29. 6.4:ツールのメトリクス ＃ ツール種別 主な収集データ 1 テストマネジメントツール ● カバレッジメトリクス ● 利用可能なテスト・計画しているテスト ● 現在の実行ステータス 2 欠陥マネジメントツール ● 欠陥に関する現在のステータス ● 重要度・優先度・欠陥の分布 ● 欠陥の混入/発見/検出フェーズや見逃し率 3 静的解析ツール ● 保守性の問題 4 性能テストツール ● システムの拡張性に関する情報 5 カバレッジツール ● テスト消化率 • ツール別にみた主な収集データ
- 30. おつかれさまでした！！