JSTQB TMのシラバスを読んでいる
はじめに
ソフトウェアテストの勉強をしているので、JSTQBのTMの勉強をしている。
自分がよくわかってないところを重点的に勉強しているので、ここに自分の理解を書いておく。自分の理解なので、間違っている可能性もある。
テストの見積もり
見積もりの技法
直感、推測、過去の経験
チーム見積もりセッション（ワイドバンドデルファイなど）
- 企業の標準および基準
- プロジェクトの総工数、スタッフ構成の割合
- 組織のデータ蓄積、メトリクス
- FP、コードの行数、開発者工数などのパラメータから業界標準や予測モデル チーム見積もりセッション以外は、これまでやったことがある気がする。
見積もりに影響を与える要因
- 品質レベル
- システムのサイズ
- 過去プロジェクトのデータ
- プロセス成熟度、プロジェクト見積もりの正確さ
- 物理的要因。ツール、環境、データ、再利用可能なテストドキュメント
- 人的要因。
- プロセス、組織、技術などの複雑さ、ステークホルダーの数。サブチームの構成と場所
- 人数増加に伴うトレーニングと導入
- 新しいツール、プロセスなどの適用や開発
- テスト仕様の詳細度合い
- コンポーネントの受け入れ時期
- 使える範囲の限られたテストデータ
- テスト対象のソフトウェア品質
挙げられているものは粒度がまちまちだが、そういわれれば考慮しないといけないものばかり。特に、「テスト仕様の詳細度合い」「コンポーネントの受け入れ時期」「使える範囲の限られたテストデータ」は日頃あまり意識してなかった。大体の要素が見積もりが増える要素。
テストメトリクスの定義及び使用
テストメトリクスの4つのカテゴリ
ALでは、以下のうち、プロジェクトメトリクスに重点を置く。
プロジェクトメトリクス * プロジェクト終了基準に対する進捗を測定 * 実行済み、合格、不合格のテストケースの割合など * プロダクトメトリクス * プロセスの属性について測定 * テスト範囲、欠陥密度など * プロセスメトリクス * テストプロセスや開発プロセスの能力を測定 * テストで検出された欠陥の割合 プロセス自体が機能しているかどうか * テストで欠陥を見つけられているか * 早期に大量の欠陥を見つけられているか * 人的メトリクス * 個人、またはグループの能力を測定
テスト進捗モニタリング
- プロダクトリスク
- テストに合格することにより対応されたリスクの割合
- テストに不合格になったリスクの割合
- テストが完了できていないリスクの割合
- 最初のリスク分析後に識別したリスクの割合
- リスクカテゴリで分類されたリスクのうち、対応されたリスクの割合
最後の要素の意味がわからなかった。一番最初のテストに合格することにより対応されたリスクの割合とは違うのか。テスト以外の手段で対応されたものということ？
欠陥
拒否されたレポート、重複レポート
* バグレポートのうち、評価対象外となるものといえるか。また、レポート内容の品質を測定するものにもなる。テスト
- テストの総数
- 回帰テスト、確認テストのステータス
- 計画している1日当たりのテスト時間と実績のテスト時間の比
- 進捗ではなくて、コストを見るもの
- テスト環境の可用性
- テスト時間のうち、テスト実行ができた時間を導き出すためのもの
確信度合い
* カバレッジを代替とすることもある。主観的な評価となることが多い。テストコントロール
- 品質リスク分析、テストの優先度、テスト計画見直し
- リソース追加、プロジェクト活動・テスト活動の追加（タスクの追加）
- リリース日の延期
- 終了基準の緩和、または厳格化
- プロジェクトの対象範囲の変更
どの選択肢をとるかは、PJの事情や役割・立場によって違うだろう。
