私がテスト計画を書く理由
これはソフトウェアテスト Advent Calendar 2017 - Qiita の17日目の記事です。
はじめに
この記事では、特にQAやテストのエンジニアの方にむけて、テスト計画を作成する理由や目的を書いていこうと思います。 もし、テスト計画を新たに導入したり、テスト計画書の内容を見直したいと考える際に参考になれば幸いです。
私の仕事
私は普段、ウェブサービスを運営する会社でQAのマネージャをやっています。 以下は、最近社外のソフトウェアテストシンポジウムで登壇させていただいた時の発表資料です。うちのチームの仕事のスタイルなどを理解していただくのにあわせてご参照頂ければと思います。
www.slideshare.netテスト計画とは
ものの本によると https://www.amazon.co.jp/gp/aw/d/4817161108/ref=dbs_a_w_dp_4817161108
検査計画書は、いうまでもなく検査実施のためのもっとも重要な仕様書である．
とあります。
しかし、普段社外の人たちとコミュニケーションするなかで、実際にテスト計画をプロジェクトで有効に活用されている話をあまり聞きません。 もしかしたら、プロジェクトがただ上手くいっているからなのしれませんが、私が所属する組織では、難易度が高い（規模が大きい、システムが複雑、活動の制約が厳しい）と思われるプロジェクトでは、テスト計画なしでプロジェクトの成功は難しいと私は感じています。 ですので、もし今テストプロジェクトが上手くいっていないと感じるのであれば、テスト計画を有効活用することがプロジェクト成功の助けになるかもしれません。
テスト計画が解決してくれること
テスト計画が解決してくれることは沢山あります。 私が普段重要だと思っていることを書き出していきます。
テストする範囲（テストアイテムやテストスコープ）の意識をあわせることができる
まず、テストする範囲を特定します。当たり前なことですが、これはとても重要なことです。 今回の開発システム（サービス、製品）のなかでテストの対象となる機能を書き出すことでその認識を合わせていきます。
ここで不足しがちなのは、テストしない機能を明らかにしておくことです。
自分が影響範囲外だと思っている"直接改修しない"既存のモジュールや外部システムとのテストを、 一部の担当者はテストすべき（もしくは当然テストするだろう）と考えることがあり、そういった認識の齟齬から後で問題が起こることがあります。 計画フェーズで確認しておかないと、あとから発覚したときに調整が難しくなることがあります。 *1
テストのアプローチを検討できる（テストタイプ、テストカテゴリ、テスト条件、テスト観点、適用するテスト技法 等の検討）
対象となる機能が決まったら、何をどうテストするかも具体的に書き出して検討することができます。 人によってテスト設計や分析を始めるタイミングは違うと思いますが、計画中に設計すべきことはしてしまうのが良いと私は考えています。
もしかしたら、テストタイプ毎にテストカテゴリのみを決めておくだけでも悪くないかもしれませんが、 クリティカルなプロジェクトであればスケジュールとの戦いになりますので、現実的なスケジュールを作成するために、 より詳細なテストをイメージできるように計画段階でテストの内容を明らかにしておくべきです。
特にテストプロジェクトに割り当てられたリソースやスケジュールを後から変更しづらいようなプロジェクトの場合は、 予定されたテストを実行しきれないにもかかわらず、限られたリソースの中でベストを尽くすしかないような状況になってしまうと不幸なので、 要求された品質にたどり着くために必要なテストを、きっちり全員が腹落ちするようにテストのアプローチをまとめましょう。
テストの順序を明確にし、テストの回数をイメージするきっかけをもてる（テストレベル・テストサイクルの検討）
テストの順序や回数を明確にしておく必要があります。 各テストレベルの目的や概要を書き出し、テストアプローチで検討したテストはどこで実施することが妥当なのか考える機会になります。
ポイントは重要な問題をいかに早く気付けるように組み立てるかです。 例えば、「もしかしたら、新しいOSSのプラグインはバグだらけで使わない方が良いかもしれないので、システムテストに入る前の早い段階でOSSに関係するテストの一部を実施しよう」と考えてみたり、 「業務レベルの要求が抜けていたら不安だから、受入れテストの前工程でその問題を発見するためにどうしたら良いか」など検討したりすることです。
また、機能テストのテストベースとなる機能仕様書が十分な精度で準備されていないままプロジェクトが進行しているのであれば、「テストサイクルが1回では不安なので、3回くらい考えておいて、追加のテストケース設計も見積もっておこう」などと考えることができます。
QAの立場から、検討されたテストの内容（テストのアプローチ）を眺めながらが不安に感じることは時々現実になるので、プロジェクトリスクも含め、全体の流れをイメージするために順序や回数を検討する必要があります。
プロダクトリスクを合意することができる
私の場合、QAエンジニアとして、計画時に提案するテスト内容はプログラマや開発側のディレクターのイメージを少し（時々大きく...）超えた量です。
テストはプロダクトリスクの軽減活動の一部であると言えると思いますが、 なぜ、これだけのテストが必要か、プロジェクトのステークホルダー全体で腹落ちするためにプロダクトリスクについても合意が必要です。
テストが必要であることを納得してもらえる説明ができなければ（もしくは、テストを実施しなかったときに発生するリスクを運用チームや事業オーナーが許容できるのであれば）極論ですがテストのアプローチを見直してしまっても良いと思います（極論ですよ）
テスト環境を検討する機会を得る
テスト環境の検討も意外と重要です。同じチームで繰り返し開発を行っている場合は、おそらく前回と同じでしょうから気にしなくて問題ないと思いますが、 色んな開発プロジェクトで仕事をするようなQAエンジニアは、過去にテスト環境の問題（受け渡し時期や、制限（一部の機能が使えない）、スペックが低い（レスポンスが遅い））などが原因でテストが上手く実施できなかった経験があるのではないでしょうか。
私は普段の業務で、テスト環境の問題が発生してしまった際、冗談半分に「（地球のそれを彷彿させるように）深刻な環境問題が発生した」と発言してプロジェクトメンバーと笑いますが、マネージメントの観点からすると環境問題により、時として深刻な遅れがでることがあります。
原因は色々ありますが、例えば、事前にテスト環境（もしくはリリース前の本番環境）を使って、どのタイミングでどんなテストを実施するかを明確にしていない、もしくは開発側と環境の引き渡し時期を合意していないためです。
また、テストアプローチやテストカテゴリ間の愛称により、一緒にテストが実施できないことありますが、そういった前提条件をキチンとテスト環境の要件に加味できていないことも原因にあたります。 例えば、パフォーマンステストの結果の精度を求めるのであれば、専用のテスト環境を準備してもらう必要があるでしょうし、業務シナリオを通して日々のシステム全体の売り上げ集計を正確に再現するようなテストでは、他のテストと同じ環境ではテスト結果に自信が持ちづらくなります。
「環境問題」が発生しない未来を創るためにも、計画時にキチンと検討を済ませておくことが大切だと考えています。
見積り、担当者、スケジュールの妥当性を判断できる
どんな機能に対して、どんなテストを、どんな流れで実施するかをしっかりと検討できていれば、各テストの工数やタスクごとに担当者を適切に配置することができます。
まとめ
いかがだったでしょうか。 計画段階で話しておかないと、大きな方針や予算、リソースなどをあとから調整できなくなることがあると思うので、QAをはじめとするプロジェクトのステークホルダが不幸にならないためにも必要十分な検討が大切です。 あなたがテスト計画から解決できることのヒントになれば幸いです。
