ご紹介、我流ペライチテスト計画

こんにちは、まままです。

テスト計画のお話しです。
テスト計画といえば、会社や現場でテンプレートを持っていて、テンプレートの項目を埋めるだけってパターンだったり、ググればテンプレートも山ほど出てくるし、ガチガチに作るとかなりの大作(それなりに工数もかかるし、調査／調整毎が意外と多い)ドキュメントかなと思っています。
また、JSTQBやIEEEでテスト計画に記載すべき事項が定められているかと思いますが、ゼロベースから作成すると結構個人のクセだったり拘りが出るドキュメントかなと思っています。
おそらく、テスト計画に記載する項目の中で、重点をおくポイントも作成者ぞれぞれ違ってくるのかなといった感覚を持っています。

そこで、今回は、我流のペライチテスト計画、僕が絶対に記載する事項をまとめようと思います。
テスト計画に関しては、(前述と重なりますが)ググると山ほどの記事が出てくるし、「テスト計画とは。」という超参考になるnote記事も沢山あるので、皆さんの参考になるか分かりませんが、僕の中でのテスト計画の立ち位置や役割の解釈含めて記載します。

テスト計画書の役割

僕の中での解釈で、大きく２つの役割を担っていると思っています。
・テスト工程の実施内容の明確化、責任の明確化
・テスト工程を担当するメンバーの心の拠り所
また、テスト計画が完成後は、プロジェクト全体ではほぼ見られない資料になりがちなのかなといったイメージが強いです。（なんかあった時にどうだったっけ？って引っ張り出されることはあっても・・・、これまでの仕事の経験的にも）。
ただ、テストでやること／やらないことや担当範囲、責任範囲を明確にして正式な資料として残すことは、チームとしてもプロジェクトとしても重要事項の１つだと思っています。
（言った言っていない防止や、問題が起きた際の判断基準になれる）

絶対に記載する事項（テスト計画で重要視する項目）

テスト計画書にこれだけは記載すると言う項目を5つに絞って記載します。

【テスト戦略】

どのようにテストを進めるか？、テストとしてどのような作戦で行くか？を記載するイメージが一般的かなと思います。
僕も大きくはイメージのズレはないのですが、進め方や作戦以外に、どのように品質を高めていくか？と言う点を意識して記載しています。
求められる品質は、テスト対象の成熟度や規模、スコープによって異なります。
その求められている品質に対して、どよの様なアプローチをとるか、どの様にしてプロジェクト全体で品質を上げていくかの道筋を描くようにしています。
また、この道筋を描くための仮説作りや方針検討はQAエンジニアとしての腕の見せどころかなと思っています。

【テスト範囲と対象】

テストで対象とする範囲とテスト対象を明確にします。
システム構成図や機能一覧で対象範囲を示します。
テスト対象のOSやブラウザ、画面サイズ、モジュールバージョンの指定も記載します。
言い方を変えれば、「ここで対象としない部分＝テスト対象外」となります。
テストしない部分に関しては、明示的にテストしない旨とテスト対象外理由を記載するのが望ましいです。
テスト範囲と対象を明確にすることは、PMやプロジェクトメンバー、ステークホルダーとの認識齟齬防止や品質担保範囲の共通認識に繋がります。

【テスト工程定義】

各テスト工程で実施するテスト目的を記載します。
各テスト工程で、ここの工程の目的は何か、何をテストするか、どんなテストをするか、どのテストは記載しないのか、を記載します。
具体的には、
・各テスト工程の目的（何を確認するのか）
・各テスト工程と対象のテストカテゴリー（機能テスト、シナリオテスト、リグレッションテスト、性能テストとか）
を記載します。
どの工程でもテストしないカテゴリーがあれば、その旨も記載します。

【テスト開始／中断／終了条件】

各テスト工程で、どうなったら着手するのか、どうなったらテストを中断するのか、どうなったらテストを完了とするのか、を記載します。
特に、中断条件が一番重要であり、PMやプロジェクトメンバー、ステークホルダーと確実な合意が必要な部分になります。
テストを一旦止める（＝プロジェクトの進行を停止させる）ことにつながるため、スケジュールのリスクが発生します。
また、テストを中断し前工程へ差し戻しするレベルで品質に対するリスクも発生していいます。

【バグ起票ルール／回送ルートとバグ票テンプレート】

ここは、かなり僕の個性が出ている部分かと思います。
テスト工程のメンバー間で、作業粒度の統一や困った時に立ち返れるために記載をしています。
特にバグ起票関連に関しては、実作業時の戸惑いや人によって粒度が異なる部分が出てくる部分だと思うので、少しでも共通化や適切なフローでバグ票を開発チームに連携できる様にしています。
具体的な一例としては、以下のような記載をしています。
・バグ起票ルール
再現確認の方法や回数、再現性の書き方を指定する
参照したテストベース、仕様書との付け合わせ状況を記載する
blockになるケース数（優先度判断の１つにする）を記載する
・回送ルート
バグ起票後の対応をフローで記載する
チーム内に通知する手順を盛り込む
・NG／block／NAとする場合のルール
バグが発生するケースのみをNGとして、NGが影響して実施できないケースをblockとするとか、
NAにする場合のルールとか、
NG→OKにするルールとか
テスト実施の際のテスト結果の付け方に関して記載する
・バグ票テンプレート
記載項目を準備したテンプレートを用意して、テンプレートを使って起票をする
エビデンスをキャプチャで貼ることとかのルール付きです。
担当者間での起票粒度のズレが防げます。

ペライチテスト計画書テンプレート

どこまで参考になるか分かりませんが、最後に僕がペライチでテスト計画作る時のテンプレートを載せます。

【概要】
記載すること
・テスト概要（どんなプロジェクトのテストか）
・テスト計画の目的
・プロジェクト計画のリンク
とか

【テスト戦略】
（前述した項目参照）

【テスト範囲と対象】
（前述した項目参照）

【テスト工程定義】
（前述した項目参照）

【テスト開始／中断／終了条件】
（前述した項目参照）

【テストベース】
記載すること
・テストベースとなる資料を記載する

【成果物】
記載すること
・各テスト工程の成果物を記載する
（テスト計画書、テスト設計書、テストエビデンスとか）
※プロジェクト計画書にも書かれていたら、そっち参照にしてもいいかも

【スケジュール】
記載すること
・テスト工程のスケジュール
※プロジェクト計画書にも書かれていたら、そっち参照にしてもいいかも

【コミュニケーションルール】
記載すること
・コニュニケーションに使うチャット
・質問対応のルール
・会議体
※プロジェクト計画書にも書かれていたら、そっち参照にしてもいいかも

【バグ起票ルール／回送ルートとバグ票テンプレート】
（前述した項目参照）

終わり

テスト計画は、自分の型を持ってしまえばどこに行っても基本迷うことはないかなと思うので、皆さん自分の型を持ってみてもいいかと思います。
また、テスト計画を作成しない方や、そもそも作らずにプロジェクト進める場合でもテスト計画に記載する事項はチーム内で共有した上でテストを進めると迷いや手戻り防止にも繋がると思います。

内容薄いよとか、これはテスト計画じゃない（考え浅い）とか、怒られるかもですが、少しでも参考になれば・・・。
では。