全部書こうとしたら長すぎるので前編。後編は書くか未定
■イントロダクション
・FLに比べて「分析と設計」「実装と実行」がそれぞれ独立。「計画とコントロール」にモニタリングも仲間入り
■テスト計画
・計画作業はどのくらいやるの？
各テストレベルのテスト開始時～終了作業までプロジェクト通して継続
・計画でやること
戦略から導き出した目的や使命に沿って
何をするか、何が必要かきめる
目的達成を測る方法きめる
その方法を決めると必要なツールやトレーニングが決まる。
戦略からどんなテストをするかを決めるー
・テスマネは、テスト計画段階で
採用するテストレベルと、各レベルの目標目的
使用するテスト技法を決める
→テストに対するアプローチ(何をゴールにしてどんなテスト技法使って、どうやって開始して終了？)を決める！
・テスマネからプロジェクト設計者？へ
テスト環境これでいいか
必要なリソース使えるか
環境設定する人が準備はじめているか
納期いつですか
コストどのくらいですか
を確認
※外部リソースを使う場合などの外部と
やり取りが必要な場合はサービスレベルの水準合意をとる。
・テストベース→テスト条件→テストケースの
トレーサビリティはとにかくしっかりやろう
それをやることがテスト計画とモニタリングとコントロールをうまくやるコツだよ
■テストのモニタリングとコントロール
・モニタリングはテレビ番組ではない
テスト成果物や活動、リソース、スケジュールなどの「対象」を「測定」して、計画が実行できてるか
戦略や目的が満たされてるかを判断する
が、これらをバラバラにみるととっても解りづらいので
テスト条件をキーにしてグループにすると分かりやすくなる
(よくわかっていないが)テスト条件から
→ベース
→あくてぃびてい
→リソース
→ケース
→スケジュール
に紐付けていくと分かりやすいといってるんじゃないかと推測。
・ステークホルダが求めてること→そのまま仕様定義、にはならないので、ステークホルダの求めてるものをちゃんと読み取ってテスト条件に落としこんでね
※ステークホルダは利害関係者。この先1000回出てくるキーワードなので理解必須
・テストコントロールは
計画が計画通り進んでるかを随時確認して
あかんときは必要に応じてテスト計画を是正したり再検討する。→最終的に目的達成できるように
■テスト分析
・何をテストするかをテスト条件の形で定義する。
・1にトレーサビリティ、2にトレーサビリティ、3、4もトレーサビリティ
テスト目的→テストベース→テスト条件→テストケース
このトレーサビリティをまじでしっかり…
・テスト条件を詳細にするとテスト条件が多数になるよ
・テスト条件が詳細だと網羅たくさんできるよ、わかりやすく書けるよ、トレーサビリティのベースになるよ(他にもあるけど略)
・ただし実行に時間がかかるよ、変更があった場合保守が大変。どのくらいの詳細度でやるかも定義しなきゃだめよ
