「困ったテスト計画書」が作成される背景 ー 全体テスト計画を語る夕べ －
２０１９年１月３１日（木）１９時に開催しました「全体テスト計画を語る夕べ」の原稿の一部をリライトしたものです。
（１９時～２０時１５分までの原稿です）
目次
１．はじめに
２．困ったテスト計画書が作られる背景
３．変更してはならないと考えている
３－１．変更しないのは組織の決まり？
３－２．テスト計画は必要に応じて変更する
３－３．不確実なことを何とかして扱う
４．テスト計画書を使うと考えていない
４－１．テスト計画を立てる目的とねらい
４－２．ステークホルダーとのコミュニケーション
４－３．テスト活動の実現可能性
５．テスト計画の立て方を知らない
５－１．目次の順番通りにテストを計画してしまう
５－２．テスト計画書テンプレートの問題点
６．ここまでのまとめ
１．はじめに
語る夕べシリーズについて
喫茶店や居酒屋などで話されている事柄をオープンの場で話します。登壇している２人（今回は @EgaSa さんと @tulune さんの３人です）の私的な会話に、皆さんを巻き込む感じです。セミナー講師が受講生に向かって理解させるというスタイルではなく、登壇者が勝手に喋りますので、ぐたぐた過ぎて、参加者の方が消化不良になることもあります。
登壇者の話に割り込んできても構いません。どんどん話に入ってきてください。
基本はツイッターで呟いていただいてかまいませんが、僕が呟かないで欲しいと言った内容については止めてください。ハッシュタグはこちらになります。
皆さんの判断でこれは「問題になりそうだな」というのがあれば、そちらも控えていただけると有り難いです。
「ツイッター班がいるので、呟かなくていいや」と思っている方もいるかもしれませんが、後で僕が振り返るとき寂しいので、可能であればツイートしてください。ツイートが少ないと、みんなの興味と違うところを喋っていたのかなぁと思ってしまいます。
対象者
全体テスト計画を策定する立場の人を対象にしていますので、中堅～ベテランの人を対象にしています。
２．困ったテスト計画書が作られる背景
note に「困ったテスト計画書」を語る夕べ（番外編）という記事を投稿しています。
この記事に挙がっているなぜ困ったテスト計画書が作られるのか、という問いを突き詰めるならば、組織の事情を考慮しなくてはいけないでしょう。
例えば、テスト計画の標準が無いからという人もいるかもしれませんし、「テスト計画なんて不要だ」と思っているのに、組織標準で作ることになっているので、嫌々作っているからかもしれません。
本来であれば原因分析をすべきなのですが、今回はよく見かける状況を３つお伝えします。根本的な原因ではありませんが、よく見かける状況をお伝えすることで、何らかの気づきが得られるのではないかと思います。
・「一度作成したテスト計画書は変更してはいけない」と考えていること
・「テスト計画書を使うもの」という認識がないこと
・「テスト計画の立て方を知らない」ということ
今日の全体テスト計画を語る夕べでは、特に３つ目の問題に対して焦点を当てますが、一通り見ていきましょう。
３．変更してはならないと考えている
３－１．変更しないのは組織の決まり？
「テスト計画書を変更してはいけない」という認識を持っているため、結果として困ったテスト計画書になってしまいます。
計画を契約と同じ意味で捉えており、テスト計画書は「テストチームが守るべき事柄を記しているもの」と思っている人であれば、計画変更に抵抗感を持つのは当たり前かもしれません。
しかし、テスト計画書に限らず、様々な計画書でも同じことが言えますが、「変更してはならない」という認識は、円滑なプロジェクト運営の妨げになります。ましてや、テストマネジメントにおける弊害は大きいものです。
テストは開発状況に大きく影響を受けます。常に進捗が遅れるといっても過言ではありません。テスト実施直前には、テスト計画立案時とは異なる状況になっていることはあります。状況が変わっているのですから、事前に作ったテスト計画書は使い物になりません。
使えないテスト計画書であるならば、組織のルールとしてテスト計画書を作ることになっていたとしても、真剣に作ることはしないでしょう。
検査の役割を担う品質保証部などの担当者から、ダメだしをされない程度であればよいので、過去に検査が通ったテスト計画書のコピー＆ペーストをすることに躊躇することはないはずです。
なぜ、使えないテスト計画書になってしまうのか、それは都度変更をしていないからです。なぜ、変更しないのか、それはテスト計画書は変更してもよいという認識を持っていないからです。または、テスト計画書の随時変更を組織のルールで認めていないからです。
所属する組織を変えることによって、いろいろなことが分かるものです。
僕は「テスト計画書は変更するものだ」という認識を持ち、そのスタイルで仕事をしてきました。ある組織に所属したとき、当然のようにテスト計画書を変更したら、烈火のごとく怒られました。未だになぜ怒られたのか分かりません。
３－２．テスト計画は必要に応じて変更する
テスト計画書を一回で完璧なものを作成しなければならないと考えているのであればそれは無理です。
テスト計画の様々な項目の多くはテスト実行の直前でなければ決まらないことが多いからです。早い段階でテスト計画を立てるには、分かっていることは詳しく書き、分からないことは浅く書くと割り切ってテスト計画書を運用することが必要です。
2008年の JaSST 札幌のチュートリアルでは、この図を使って説明しました。
テスト計画はプロジェクトの初期に行う一過性の活動ではなく、継続的な活動なのです。
３－３．不確実なことを何とかして扱う
テストは開発工程の最後であるため、開発工程の初期に計画を立てようとすると、分からないこと、確定していないこと、不確実なことばかりです。
確実な状況になるまでテスト計画書を書かないとしたならば、テスト実行の直前まで書けないでしょう。直前に書くのであれば、そのように思っていても仕方がないかもしれません。
・テスト計画を書くことは意味が無い
・品質保証部のレビューが通ればよい
・スケジュールだけまともならそれで十分
「分かるまで書かない」のではなく、持っている情報をもとに計画を立てます。そうすると、何が分かっていて、何が分からないのかが明確になり、分かっていない部分の情報を集めて、確実さを増そうとします。そして、計画を書き直していきます。
大切なことなので、もう一度言います。何が分からないのかが明確になることが大事です。
このような計画の立て方をローリング・ウェーブ計画法と言います。以下、プロジェクトマネジメント知識体系ガイド第6版 より引用します。
ローリング・ウェーブ計画法
ローリング・ウェーブ計画法は反復計画法のひとつで、早期に完了しなければならない作業は詳細に、将来の作業はより上位のレベルで計画する。
アジャイル手法またはウォーターフォール型手法を使用している場合に、ローリング・ウェーブ計画法はワーク・パッケージ、計画中のパッケージ、およびリリース計画に適用可能な段階的詳細化のひとつの形態である。
したがって、作業はプロジェクトのライフサイクルのどの時点にあるかによって、さまざまな詳細さのレベルがある。
情報がほとんど明確になっていない初期の戦略的な計画の段階では、ワークパッケージの要素分解は既知の詳細レベルに留められる。
そして、時期が近くなって行われるイベントについてより一層わかるようになると、ワーク・パッケージはアクティビティに分解される。
「プロジェクトマネジメント知識体系ガイド第6版」より引用
ローリング・ウェーブ計画法を採用することで、テスト計画は早い段階からの作成に着手することができるようになります。
テスト計画の話なのに、なぜ PMBOK を持ち出したかと言いますと、「段階的に反復的にテスト計画を立てるという方法は一般的では無い」と反論する方がいるからです。そのように言う人には、「 PMBOK に書かれています」と言うと黙りますので紹介しました。
でも、 PMBOK はテストと関係ないと考える人もいるかもしれません。
そこで、「はじめて学ぶソフトウェアのテスト技法」（リー・コープランド）の中に書かれている「海兵隊のプランニング」の一部を孫引きします。全部知りたい人はコープランドの本を読んでください。
海兵隊の プランニング
海兵隊では計画を２つの基本的な機能を包含するものとして定義している
・望ましい未来を思い描くこと
・その未来を実現するために、時間および空間的に可能な行動の構成を整えること
海兵隊における計画で、計画する際に注意すべき事柄
・あまりに遠い将来まで事態を予想しようとすること
・あまりに詳細まで計画すること
・計画の手法を制度化してしまい、計画のプロセスも計画書も固定化して変えられないという硬直化した思考に陥ること
・計画を、問題に対する変更不能な唯一の解決策だと思い込んでしまうこと
・計画の欠点を識別して、必要な調整を行うための、フィードバック機能の必要性を無視すること
計画は、手段と目的をたえず調整し続けるという点で、連続的なプロセスである。また、計画は連続的な調整および改善であるという点で進化的なプロセスとみなすべきである。
（中略）
肝心なのは、可能な限り最善の計画を作ることではなく、可能な限り最善の結果を得ることである。同様に、個々の計画書は動かせない文書ではなく、進化し続ける文書とみなすべきである。
「はじめて学ぶソフトウェアのテスト技法」より引用
４．テスト計画書を使うと考えていない
４－１．テスト計画を立てる目的とねらい
テスト計画書は作って終わりにするものではありません。テスト計画書は使うものです。しかし、テスト計画書を書いただけで、使うことを考えていない人がいます。このような人は、そもそもテスト計画を立てる目的がはっきりしていないことがあります。テスト計画の目的が腹落ちしていないので、テスト計画書を使わないのです。
プロジェクトの状況によって、テスト計画を立てる目的は変わりますが、一般的に言われているテスト計画の目的とねらいを確認してみましょう。
《目的》
- テスト目的に沿ったテスト内容や作業を実施するため
- テストのスコープを明確にするため
- テスト活動を阻害する問題を事前に取り除くため
- ステークホルダー間の役割分担を明確にするため
- ステークホルダー間のコミュニケーションを促進するため
- テストの抜け漏れや重複が少ないテストを実施するため
- テストの時期や内容を顧客と合意するため
- 未決事項を明らかにし、解消に向けた活動を促すため
- テスト活動の実現可能性を把握するため
- テストの進捗管理を行うため
- 計画変更時にシミュレーションを行うため
《ねらい》
- 全体感が把握できる
- 目的地までのナビゲーションとして使える
- ペースメーカーとして使える
- チームで取り組める
- 事前に準備がはかどる
- 活動が円滑に実施でき、無駄が省ける
- 行動の指針(判断の拠り所)が明らかになる
- ステークホルダーとの合意形成がはかどる
- 手戻りが抑止される
- 品質に関する情報を適切なタイミングで提供できる
- 計画変更時の拠り所になる
- 経験を形式知化し、他のプロジェクトに適用しやすくなる
※目的 ：計画の範囲内で実現を期待する成果
※ねらい：計画の範囲外で実現を期待する成果
上記の目的の中で、テスト計画書を使うイメージを持ちやすい次の２つの目的について詳しくみましょう。
- ステークホルダー間のコミュニケーションを促進するため
- テスト活動の実現可能性を把握するため
４－２．ステークホルダーとのコミュニケーション
テストに関する概念や用語は、組織によって異なります。たとえば、単体テストという言葉を一つとっても、今までの開発経験によって、所属していた組織によって、様々な解釈がされます。
そのため、「単体テストという言葉は使わないようにしよう」という人もいます。確かに曖昧な言葉を使わなければ、混乱は少なくなりますが、どのようなテストをするかをステークホルダーと合意する必要性は相変わらず残ります。
用語の混乱は単体テストや結合テストのようなテストレベルだけでなく、性能テストのようなテストタイプであっても、人によって異なる意味を持っています。要件定義で決めた通常時の性能がでるのかどうかを確認するテストと捉えている人もいれば、限界まで負荷をかけるテストのことを性能テストだと考えている人もいます。
テストに関わる人たちの間でコミュニケーションが円滑になるように、文書を作成します。この文書がテスト計画書です。
４－３．テスト活動の実現可能性
計画は実行可能なものでなければなりません。実行可能かどうかを検証するために、テスト計画書を使います。リーダーの頭の中にあるだけの計画では、実行可能性をみることはできません。テスト計画書として第三者が見えるものになって、初めて妥当性を確認することができます。
また、環境や状況が変わり、テスト計画を立てた当初とは条件が変わった場合、その変化を踏まえて、計画の見直しをします。
見直しをする場合、タスク間の関係に変わりは無いかどうか、タスクのボリュームを見直す必要があるかどうか、要員の配置を見直す必要かあるかどうかなどを検討しながら、計画を見直していきます。あたかも様々なパラメータを変更させながら、シミュレーションを行っているようです。
５．テスト計画の立て方を知らない
５－１．目次の順番通りにテストを計画してしまう
テスト計画書の作成方法を教えてくれる研修を受講すると、たいていテスト計画書の目次に添って、どんな内容を入れればよいのかを教えてくれます。僕自身もそういう研修を実施していた過去があります。
研修コンテンツを作成する立場からすると、目次に添って説明するスタイルはテキスト作成が楽です。「ポイント」と称していくつかの文章を配置し、「例」と称して、前後の脈絡は無いけれども、バリエーション豊富な事例を配置するだけで、テキストができます。
受講する側も楽です。組織のルールでテスト計画書を作ることになっていますから、あまり考えたくありません。テスト計画書が穴埋めになっていて、その穴を埋めれば品質保証部の品質検査や監査が通るようなものがよいのです。そのため、テスト計画書の目次をベースに教えてくれる方法は、受講者の意図にもあっています。
テスト計画書の目次に添って説明がなされるので、この順番でテスト計画を検討するものだと考えてしまいます。しかし、テスト計画書の目次は、人に説明するためや後で使うときに効果がでるような順番になっています。
組織の標準として作られたテスト計画書の目次の中には「テスト計画を立案する」のに最適な順番になっていないものがあります。そのため、穴埋めのように作られたテスト計画書は一見するとちゃんとした計画書のようになっているのですが、テスト計画書のレビューを実施すると、記述されている内容の意図が分からないため、たくさんの指摘をもらうことがあります。
テスト計画研修という名前の研修があっても、「計画」そのものを教えてくれるところは少ないように思います。テストレベル、テストタイプという基本的な概念や代表的なメトリクスを教え、最後にテスト計画書の構成を伝えるという内容になっていることが多いように感じます。
５－２．テスト計画書テンプレートの問題点
テスト計画書のテンプレートを作って、組織内に広めるという活動を僕もやっていました。テスト計画書のレビューをしていますと、毎回同じような指摘ばかりをすることに気づいて、テンプレートを作ったんです。
皆がテンプレートに基づいてテスト計画書を作り始めると、一見するとまともな計画に見えます。そのため、テンプレート導入当初のテスト計画レビューは、導入前と比較して圧倒的にレビュー工数が減りました。効果があったと偉い人から褒められました。
でも、半年後どのプロジェクトも上手くいかなくて、特にテストが問題になりました。まともな計画書を作ったはずなのに、あちらこちらで炎上しているんです。
最初は何が何だか分かりませんでした。後からいろいろと聞き出しますと、彼らはテスト計画書を作っただけでした。誰もテスト計画を考えていないのです。
僕は、テスト計画があって、それを表現したものがテスト計画書だという認識でした。でも、彼らはテスト計画が無いんです。テスト計画書というドキュメントはありますが、中身がスカスカだったのです。
テンプレートが存在する前は、他のプロジェクトのテスト計画書をコピペする人はある程度いましたが、それでも考える人が多かったのです。しかし、組織の標準として整備されると、今まで考えていた人も考えなくなっていたのです。
テスト計画書の標準は作りました。それはテンプレートの穴をどのように埋めるかというものです。テスト計画策定の標準は作っていませんでした。テスト計画書という成果物を作るのも大切ですが、それ以上に重要なのはテスト計画を考えることです。
６．ここまでのまとめ
困ったテスト計画書が作られる背景として、次の３つを想定しました。
・「一度作成したテスト計画書は変更してはいけない」と考えていること
・「テスト計画書を使うもの」という認識がないこと
・「テスト計画の立て方を知らない」ということ
テスト計画書は変更してもよいという認識を持ってもらうために、 PMBOK のローリング・ウェーブ計画法を紹介しました。
テスト計画書を使うと考えていないのは、テスト計画の目的を明確にしていないからだという想定のもと、一般的なテスト計画の目的とねらいを明らかにしました。また、テスト計画を利用するイメージを伝えました。
テスト計画の立て方を知らないために、テスト計画書のテンプレートどおりに作成してしまうと弊害があることを示しました。テスト計画の立て方については、別の記事で説明します。
この記事が気に入ったらサポートをしてみませんか？