129.テストプロセス その⑪
今回は「テストのモニタリングとコントロール」です。
シンプルに言うと
「計画やアプローチは状況に合わせて見直しましょう」
です。
当たり前、と思う人と、え！？と思う人に分かれるかもしれません。
作者が北海道の会社さんで講義したときは「え！？」の人が多数でした。
計画通りに進めることが正しい！という考え方の現場は意外と多いものです。
その考えはわかります。ただその計画は、最初から情報が全てそろっていなければなかなか難しいものです。
例えはよくないかもしれませんが、例えば戦国時代で敵のお城に攻め込もうとして「相手の兵も少ないし正面突破しよう」と計画を立てたとします。
けれど「正面には罠が張り巡らされています！」と新しい情報がわかったとしましょう。
そんなときに「いやけど、計画通りやらないと……」だと目的の達成（敵の城を落とす）が失敗する可能性も出てきそうですよね。
上手くいっても損耗が激しくなってしまうでしょう。
別のアプローチを考えた方が筋がよさそうです。
いい例えが思い浮かばずごめんなさい。
実際テスト計画を立ててテストを進めたことがある方ならわかるかと思いますが、仕様が決まってくるにつれ想定がずれたり、仕様の追加、遅延の発生、仕様の見送り（スペックアウト）などが発生し、最初の計画やアプローチ通りには絶対いきません。
それなのに計画を見直さないで進めたら無用の長物となります。
それだけならまだしも、想定とは変わったのに当初考えた状態のアプローチのままテストプロセスを進めてしまい不要な場所のテストをしてしまう、スコープが増えたのに見逃してしまうといったように逆に害になってしまうこともあるかもしれません。
その昔作者がやっていたテスト計画「松竹梅プラン」
作者はテストコンサル（テスト計画の策定と相談役）のような形で入り、開発の方々がテストも含めて行う現場がありました。
そこで作者がやっていたテスト計画の方法で「松竹梅」の計画を立てておく、というものがありました。
どういったテストが必要か見せつつ、状況に応じてスイッチングしていこう、という方法です。
松は一番細かくテストができるプラン。ただし工数がかかります。
梅は重要個所は細かくテストするけど、他の個所のテストが少ない、簡略化されているようなプラン。
竹はその中間のプラン。
このような形です。
プロジェクト開始時は開発の方々も松プランで「これで細かくテストしよう！」と進めているのですが、開発が進んでスケジュール感が見えてくると「竹……いや、梅で……！」がほとんどでした。
仕様ややることがわかっているけどスケジュールが見通しづらい場合に重宝させてもらいました。
（もちろんそれでOKではなく、状況に合わせて梅のプランのアプローチを変更、なども必要です）
アジャイルの現場だとリーダーはとても忙しい
アジャイルの現場の話じゃないでしょ、という人もいるかと思います。
アジャイルPJのとき作者がどんな感じだったか書いておきます。
その昔アジャイル系のチームをまとめていたときがありました。
どの機能はどういうアプローチでどういったスケジュール感で進めていこうといったベースの計画はあるのですね。
けれど機能は開発された順に飛んで来ますし、それぞれの機能でテストプロセスの進捗も異なりますし、バンバン仕様変更やスケジュール変更も発生するわけです。
できた順で機能をテストしていく様を餅つきに見立てた様子。
色んなプロセスが並走していてみんな状況を把握できなくなるので、状況を物理的に見える化した様子。（コロナ前）
こんな感じの時は、出社したらチャットに現状の計画（どういう風に進めていきましょう）を投下。
朝のMTGでもどう進めていくか全員に連絡。
進捗や突如チャットに投下されたメテオフォール（仕様変更）などを鑑み対応方針を立てて計画（どういう風に進めていきましょう）を変更。
変更したらチャットに投下。
メンバーが「どうなってましたっけ？」のときは、他のメンバーが「まつさん、これ投げてました！」とやってくれる（人頼み！）
こんな感じでした(笑)
細かく軌道修正していく、といったところでしょうか。
マンガの4コマ目が絶え間なくループする感じでしたねｗ
ドキュメント自体の変更は……ごめんなさい＞＜
マンガでいいことを書いておきながらやってないことも多かったです。
毎日の終わりのステータスレポート（テスト進捗の現状報告）のときに載せる必要があったりするのでそこでドキュメントは変更したりもしてました。
