by shigemk2

当面は技術的なことしか書かない

テスト計画の思い込み #SWTEST_NIHO

テストってテストケースを書いたり、テストの実行だけ?!

→テスト計画は、スケジュールになっちゃうよね。

テストプロセスはやらないといけないことが多い

1.計画 2.分析 3.設計 4.実装 5.実行 6.報告

統合テストって統合テスト工程だけを考えればいいんでしょう?!

  • コンポーネントテスト
  • 統合テスト
  • システムテスト
  • 受け入れテスト

それぞれ違うタイミングで計画やら実装やらをやる必要がある

テスト計画って一度書いたらそれっきりでしょう?!

(とはいえ、プロジェクト計画がコロコロ変わったらそれは破綻してる)

ローリングウェイブ計画法

計画は書き換えてもよい 計画を段階的に詳細化による計画策定の一形態。 (というか頭の固い上司を説得するためのメソッド)

テスト計画を変更してもいいなら何でも変更できるんでしょう?!

歪んだ心がプロジェクトを失敗させる

目的 アプローチ 作業

目的をコロコロ変えたら計画の根底から崩れるからよくない 作業は状況が変わったら内容を変えないといけない。(スケジュールと言いかえてもいい)

でも計画を全く変えないでプロジェクトを進行させるのは不可能なので、 計画はちょくちょく変わる

テスト計画書は目次通り書くのでしょう?!

ロジックを考える

事実 リスク 行動

今見えているもの 見えていないものを浮き彫りにする必要がある

見えていないものにたいするリスクと、そのリスクを軽減するために必要なアクション。

目次を考える前に、「なぜその計画書を書かなければならないのか」を 論理だてて説明する必要があるのである。

頑張って計画しても見積りと実績がどうせ合わないんでしょう?!

参考

JSTQB Foundation Level シラバス