「困ったテスト計画書」を語る夕べ（番外編）
同人誌に投稿した原稿をもとにアレンジました。もともとは「全体テスト計画を語る夕べ」の開始３０分のネタでした。
１．はじめに
１－１．語る夕べシリーズについて
喫茶店や居酒屋などで話されている事柄をオープンの場で話します。登壇している２人の私的な会話に、皆さんを巻き込む感じです。セミナー講師が受講生に向かって理解させるというスタイルではなく、登壇者が勝手に喋りますので、ぐたぐた過ぎて、参加者の方が消化不良になることもあります。
登壇者の話に割り込んできても構いません。どんどん話に入ってきてください。
基本はツイッターで呟いていただいてかまいませんが、僕が呟かないで欲しいと言った内容については止めてください。ハッシュタグはこちらになります。
皆さんの判断でこれは「問題になりそうだな」というのがあれば、そちらも控えていただけると有り難いです。
１－２．本日の進め方
いつもの語る夕べでは、登壇者が２人で話をしますが、本日はひとり語りになります。ひとりで喋りますが、いつものようにセミナーのような講義形式にはしません。質問があれば随時受け付けます。いちいち手を挙げなくても構いません。
１－３．対象者
本日のテーマはいわゆる「あるあるネタ」なので初心者や初級者の人には、ちんぷんかんぷんかもしれません。「こういう現場があるんだなぁ」ぐらいに思ってください。
１－４．コンテキスト
今まで出会ったテスト計画書について語ったものですので、エンタープライズ系開発で書かれているテスト計画書になります。なお、特定の組織の話ではありません。
２．今までに出会った困ったテスト計画書
２－１．テスト計画テンプレートの功罪
仕事でテスト計画を立てなければならないとき、計画に抜け漏れがあったらどうしようかなど不安になります。そのような不安を解消するために、様々な組織ではテスト計画書のテンプレートを作ります。テンプレートを用いたサンプルの計画書も用意します。
テンプレートがあり、それに則ってテスト計画書が作られます。テスト計画書に書かなくてはいけない項目は全て入っているので、問題は解消されています。見栄えもよくなっているでしょう。しかし、見た目がよい計画書と中身がよい計画書は別物です。
本章では、多数のテスト計画書をレビューしてきた経験から得られた知見を、「困ったテスト計画書」として表現することで、テンプレートの限界を示します。「困ったテスト計画書」の特徴を表現している語句をタイトルにして、その後に何がよくないのかを説明します。
２－２．ほぼ転記
サンプルをコピー＆ペーストし、表紙と作成日付、スケジュールの日程と人の名前だけを変更しているテスト計画書
なぜテスト計画書を作成するのか、ということを腹落ちしていない場合、作業の効率化を図って、サンプルの一部分だけ置き換えることがあります。
作成工数は短縮できますが、考え抜いた計画ではないため、計画に沿ってテストチームを運営しようとすると、いろいろ問題が発生しがちです。あまり考えていないのですから、計画変更に弱いものになっています。テスト計画は変更することを前提に考えますから、変更に弱いというのは見逃せません。
２－３．過去の遺物
昔作った計画書を代々受け継いでいるテスト計画書
「転記」と同じコピペ計画書ですが、区別します。サンプルからコピー＆ペーストをしている場合、粗を見つけるのは容易なのですが、過去のテスト計画書をベースに作られたものは、一見すると問題の無いテスト計画書と判断しやすく、レビューの難易度が異なるため、区別しています。
システムの維持管理、保守開発を行っているプロジェクトに多く見かけることができます。保守チームが持っている知見をテスト計画書の中に埋め込んでいるため、テストを効率的および効果的に行うことができます。
過去の遺物と否定的に解釈せずに「秘伝のたれ」と見ればメリットが多いように感じます。実際、有効なケースも多いのも事実ですが、ベースとなっているテスト計画書が相応しくない状況において、保守チームが盲目的に使うことを強制する場合に問題が発生します。
レビューアの「なぜこのような記述なのですか？」という質問に対して、「今までと変えていません」という答えが返ってきたら、リスクがあると思ってください。
２－４．行間を読ませる
テストリーダーが頭の中で考えている計画が、何も表現されていないテスト計画書
テスト計画書の表面だけを見ると「ほぼ転記」や「過去の遺物」と変わりません。まったくのコピペ計画書です。違いはテストリーダーの頭の中にはしっかりとした計画があるということです。ただし、その考えは表にでることはありません。
同じチームでテストをしているところや、保守開発を行っているプロジェクトに多く見かけることができます。
テストリーダーはテスト計画の重要さは認識しています。しかし、テスト計画書に表現することの大切さを理解していません。文書化することは大いなる無駄だと思っているのですが、組織の規則としてテスト計画書を書かなければいけないので、やむを得ず最低限必要な項目だけを書いているのです。
確かに少人数短期間で済んでしまうテストに対して、たくさんの文章を書くのは無駄かもしれません。ましてやテスト実行に直接的には関係しないように見えるテスト計画書であればなおさらです。
しかし、規模や期間によってはチーム内のコミュニケーションを円滑にするために、おざなりなテスト計画書では駄目なこともあります。リーダーの想いをテスト計画書の中に表現しなければ伝わらない規模というのがあるのです。
長いこと一緒にやっているチームだから自分の考えていることはいちいち書かなくても大丈夫だと思ってしまうのは、プロジェクト運営では危険な考えになることもあります。
「言われたからテスト計画書を書く」というのではなく、チームのコミュニケーションを円滑にする、自分の考えを伝達するという側面からテスト計画書を見ることは大切なことです。
２－５．日程表だけ
スケジュールのみが書かれた計画書のこと、または、項目レベルは埋まっているが、内容が浅くスケジュールしか書かれていないように見える計画書
この「日程表だけ」はテスト実行の直前に書かれる計画書に多く見かけることができます。また、テスト計画書の標準書式を持っていない組織の場合、計画書と言えばスケジュールが書かれている文書を指すことがあり、今でも時折見かけることができます。
テスト計画においてスケジュールは大切です。しかし、スケジュールだけしかないというのも困りものです。スケジュールは重要だけれども、計画の一部でしかありません。
テストのスケジュールをレビューするとき、スケジュール表の中身だけで判断することはありません。日程以外の項目を見ることで、スケジュールの妥当性を判断します。スケジュールを考えた根拠がスケジュール以外の項目にあるからです。日程表だけしかない計画書では、その判断ができません。
２－６．テストについて考えていない
スケジュール、リソース、テスト運営方法などには触れられているけど、肝心のテスト戦略がおざなりのテスト計画書
テスト計画書には、次のような項目が書かれます。
・どのようなテストをするのか（テスト戦略・テスト方針・テストアプローチ等）
・どのようにテストを実行するのか（体制、スケジュール、要員割当等）
・どのようにテストを管理するのか（進捗管理、不具合管理、構成管理等）
・どのようにチームを運営するのか（会議体、エスカレーションルール、課題管理、リスク管理等）
組織によっては、テスト管理やチーム運営に関する項目は、プロジェクト計画書に書くことがあります。
テスト計画書と他の計画書との違いは、テスト戦略・テスト方針・アプローチの有無です。ですから、テスト計画書のレビューで最も重視しているのが、このテスト戦略・テスト方針・テストアプローチです。
どのようなテストをするのかをしっかり考えられていれば、多少他の項目の記述が粗くても後で挽回できる可能性が高いのですが、他の項目がしっかり記述されていたとしても、この部分が粗くおざなりに書かれていればテストの成功は遠くなります。テストをどのように組み立てていくのかを考え、それを十分に表現しなくてはいけません。
２－７．詰め込みタスク
〇納期に合わせて、無理矢理タスクを押し込めているテスト計画書
お客様承認を得るために、無理矢理タスクを押し込んでしまいます。たくさんのタスクを押し込んでいるため、複数のタスクを並行処理するようなスケジュールになります。
納期に間に合わせることは大切なことです。しかし、論理的なスケジュールではなく、あたかも間に合っているかのごとく見せかけているスケジュールを書いてしまうのは問題です。
テスト計画書では、スケジュールに書かれているタスク間の関連を考えもせず、現場がどのように振る舞うかがイメージできないようなスケジュールになっているケースがあります。問題を先送りしテスト計画書作成というタスクをしのげればよいと考えているようにも思えます。
このようなテスト計画書が書かれてしまう背景としては、計画は計画、実行は実行というように計画を軽視している考えを持っているからかもしれません。
そもそもテスト実行は、テスト対象の品質によって左右されるものです。想定以上にバグが混入されていた場合、テストケースの消化は予定通りにはいきません。計画段階では、タスクは詰め込みすぎず、できない部分は早めに明らかにして、ステークホルダーと相談するのがよいでしょう。
２－８．全部丸投げ
各担当者が申告した計画をそのままマージしただけの計画書。部下に計画作業の一部または全部を「丸投げ」している計画書
テスト計画書レビューのとき、レビューアの質問にテストリーダーが答えられず、チームメンバーに回答を振ることで発覚することが多いです。全体を見ている人がいないため、各項目間で矛盾があったり、抜けがあったりします。
大きなプロジェクトでは、テスト計画を部分に分割し、担当毎にまとめさせることはあります。だからといってテストリーダーは何も知らなくてよいというものではありません。
テスト計画書を基にお客様と交渉しなければいけない状況もあるかもしれませんし、そもそもテスト計画に基づいてチームを運営しなければいけないにも関わらず、テスト計画書の作成に関わっていないというのは問題です。
この「丸投げ」は、テスト計画書の品質も問題ですが、テストリーダーの資質に問題があるかもしれません。
２－９．リスクを考えない
プロジェクトリスクを考慮していない計画書
テストには様々なリスクがあります。しかし、テスト計画書の中にそのリスクを書くことをしません。レビューのとき、テストリーダーにどんなリスクがあるのか聞いてみるときちんと答えられるにも関わらず、テスト計画書の中に書くことは避けてしまうのです。あたかもリスクを文字にして書いてしまうとそのリスクが発生してしまうかのようです。
テスト計画書を書いた当初にどんなリスクがあるのかを書いておくことは重要です。そして、時間が経つにつれ変化するリスクに対応して、計画書の記述を変更していくことも大切なことです。
２－１０．使われないテスト計画書
プロジェクトの初めの方に作成して後は顧みないテスト計画書
プロジェクトの初期にテスト計画書を作成していますが、プロジェクトの環境が変わっているにも関わらず計画書の更新を行わない計画書です。テストプロセスを確立している組織で見かけることができます。ソフトウェアライフサイクルの早い段階で、またはプロジェクトの早い段階でテスト計画書を作成すると組織で決めている場合に見かけます。
プロジェクトの早い段階でテスト計画書を作成することは、多くの利点が存在します。しかし、その利点はテスト計画書を作成しただけでは得ることはできません。テスト計画書を活用してこそ効果を得られます。
計画書と言うと、一度作ったら大きな変更をせずに計画書に沿って運用していくイメージを持たれている方が多いと思います。テスト計画書の場合、そのイメージを変えなければなりません。更新の頻度はプロジェクトによって異なりますが、作成したテスト計画書を状況の変化に応じて変更していきます。
２－１１．まとめ
レビュー時に出会った困った計画書について、書いてきました。では、ここに記述されている内容の反対にすれば、よいテスト計画書になるかというと、そうならないところが難しいところです。よいテスト計画書をどのように書くかについては、「全体テスト計画を語る夕べ」でお伝えできればと思います。
この記事が気に入ったらサポートをしてみませんか？