テスト計画を立てるまえ
鈴木三紀夫
専門は要求工学とか。
ソフトウェアテストが専門。
第一歩の振り返り
○○テストを分類してみよう
みんなが○○テストと呼んでるやつを↓のやつに分類してみよう
- 開発工程
- テストレベル
- テストタイプ
テスト技法
エンタープライズ
- 組み込み
- web
- ゲーム
業種業態が全く違うために、「テストの定義」が異なることに。
みんなで話し合う
どんなテストをやっているかが分かれば、テスト計画がたてやすくなる。リーダーが考えているテストと現場の考えているテストが微妙にズレていることはままある話。
「テスト計画をたてるためには何を抑えるべきか」を考える前に必要なことを洗い出す必要がある。
→遮二無二計画をたてるよりもよりテスト計画が練りやすくなっているかも。
Aさんの話(実話をもとに再構成)
語尾を言い切らない男。
- 今まではテスト計画を書いてこなかったけど客に言われたから書かざるをえなくなった
- 社長賞のプロジェクトの計画書をまるパクリしたテスト計画の目次を作る
- テスト計画は通らず
- 何をしたかといえば、全体の工数からテスト工数をわりだすくらい。
- 「テスト工数=無駄な時間」というのがユーザー企業のコンセンサスになりつつあり、顧客に入れ知恵をするコンサルタント()がいる。
顧客ドリブンでモチベーション上がんない
Bさんの話(実話をもとに再構成)
- コピペまみれのテスト計画書
- 上から言われてやらされるテスト研修
(顧客名やプロジェクト名すらそのままのもあった)
技法は考えるけどテスト計画のとおりにはやらない。
プロマネ指向なんだけど、書いても書いても思い通りにならないから匙を投げた。
モヤモヤを溶き解さないと理解も実践も上っ面で終わる。
解決したい課題
- テスト計画を書いたことがないひとが「書いてもいいかな」
- テスト計画無駄だと思っている人が「多少は無駄にならないかな」
流れ
- テスト計画をたてない
- おざなりなテスト計画をたてる
→ 使えるテスト計画を立てる!!!
改善方法
- モデルを使う
- 問題を取り扱う
改善するために
テスト計画書のサンプルをネットで検索する
モデル
- メリット 実行すべき事柄が分かる
- デメリット形だけ取り繕って終了しちゃうことがままある
問題を扱う
- メリット 具体的なので納得させやすいし、理解しやすい(WBSとか押し付けっぽくて嫌う人は嫌うよね)
- デメリット 問題をあげるのが難しく、単なる不平不満を言う場になりがち。
振り返りとかやると、罵倒の場になりがち。
モデル vs 問題
よくある問題(アンチパターン)を知る
アンチパターン
思い込みを溶き解してさらなる解決策を出さないといけない
アンチパターンとその裏側にある思い込みをどうにかする
(アンチパターンが多すぎると持ち帰りが少ない)
テスト計画のアンチパターン
- 転写
- ぬか漬け
- 幽霊
- 一夜漬け
- 神棚
- 魂抜け
- 圧縮
- 丸投げ
- 言霊
1. 転写
- タイトル以外、下手すると全部コピペ
- 誰もオリジナルで書かない
2. 糠漬け
- 昔作った計画書を代々受け継いでいる
- なぜそのような計画書になったのが意図が見えない
- なぜそれが正しいのか誰も分かってないから質問された瞬間に瓦解する
3. 幽霊
- リーダーの頭の中にしか計画がなく、ドキュメントが存在しない。
- テストは実際に実行はされているけど、コミュニケーションがない
4. 一夜漬け
- 計画書をテスト実行の直前に作る
- 結合テストの後半部分にくっつける
- 項目は埋まっているけど、ほとんど行き当たりばったりで現状を書き連ねただけなので「計画」じゃない
5. 神頼み
- いったん作っておいて後は誰も見ない
- 計画書そのもののクオリティは高い
- でも環境が変わっても誰も更新しない。なぜなら皆無駄だと思っているから
6. 魂抜け
- スケジュールとかにはふれられてる
- 一番重要な方針やアプローチはおざなり
7. 圧縮
- 納期にあわせてタスクを無理矢理詰め込む
- 詰め込みまくってんだからスケジュールはじまらないよ
- スケジュールが技術的じゃなく政治的に決まっちゃうことがある
- 優先順位がぐちゃぐちゃで、やってないこともやったことにされてしまう
8. 丸投げ
- 部下に計画作業の一部や全部を丸投げする
- 各担当者が申告した計画をそのままマージしただけ
9. 言霊
- プロジェクトリスクを考慮しない計画書のこと
- 「よくないことを書いたら怒られた」
- プロジェクトリスクは知ったうえで計画は練らなければならない
業種業態によってどんなアンチパターンが出てくるかは違うよ
