テスト戦略とは？立て方やポイント、テスト計画についても解説

テスト戦略とは、テスト計画の立案に先立って必要な施策や投資を明確化する、プロジェクトをゴールに導くために欠かせない過程です。テスト戦略を検討せず過去のテストのナレッジのみを参考にしてテスト計画を行っているケースも多々見られますが、工数などを漠然と踏襲するだけでは品質が向上しないばかりか、過去の失敗を繰り返したりITを取り巻く環境の変化に取り残されたりしてしまいます。このような事態を防止するには、テスト戦略を練る必要があります。

本記事では、テスト戦略の概要と立案の仕方、戦略を立てるときのポイントを解説します。

テスト戦略とは、組織やプロジェクトのあるべき姿を明確にし、それに向かうための施策や投資を検討する過程です。ITへの要求はバックエンドからフロントエンドに移り、開発にはよりスピードや柔軟性が要求されています。クラウド、自動化、そのほかさまざまなIT技術もテストの実施方法に変化をもたらしています。過去のプロジェクトからの反省点もあるでしょう。このような内外の変化を踏まえてプロジェクトのゴールを設定し、そこに到達するために求められる適切な施策や投資配分を開発初期の段階から考えるのがテスト戦略です。

テスト戦略は、次の要素から成り立っています。

・組織やプロジェクトのあるべき姿を明確にする
・今回のプロジェクトにおける到達目標を示す
・目標実現のためのテストアプローチを検討する
・テストタイプ・テストレベルへの投資配分を示す

これらは開発者やテストエンジニアだけではなく、ステークホルダーとともに検討するものです。開発したシステムやソフトウェアは、企業や組織のビジネス目標を達成するために存在しており、企業が掲げるビジネス戦略とは切っても切り離せません。テスト戦略は、開発者が決めるようなものではなく、顧客やその周辺のステークホルダーが率先して関与すべき重要な要素なのです。

株式会社SHIFTでは、この重要なソフトウェアテストに関して豊富な実績とテストナレッジを保有しており、あらゆるお客様のニーズを満たしたテスト・品質保証を上流～下流（テスト計画・テスト設計・テスト実行・テスト品質管理）まで一気通貫でご依頼いただけます。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

テスト計画は、テスト戦略で策定した品質担保の施策や目標を、実行し管理できるように細分化したものです。テストの方針・基準・関係者などのソフトウェアテストの全体像を示した全体テスト計画書と、各テストレベルの詳細スケジュール・環境・管理基準などを示した個別テスト計画書を作成します。

テスト計画が行われていないことで、テスト実施に抜け漏れや人による品質のバラつきが発生し、目標の品質に到達しないということはよくありますが、テスト計画を行っていても結果的に品質問題が発生することもあります。特に、社内標準のサンプルをそのまま使っていたり、過去のテスト計画をそのまま使いまわしていたり、先にスケジュールを決めてからテスト内容を後から決めたり、といった例で、計画通りにテストが実行できなくて問題が発生しやすい傾向があります。

テスト戦略を策定している場合は、ほとんどの場合あるべき姿に近づけるための、過去と異なる施策が提示されます。これを過去と同じテスト計画で実施しても、うまくいくはずがありません。テスト計画ではテスト戦略で提示された施策を実現するためにはどうやればいいのか、配分された工数（投資）をどのように活用すれば最大の効果があげられるのか、ということを検討し、実施可能なテストの方法を明文化していきます。場合によっては実現可能なテスト計画が立てられずに、テスト戦略の見直しが発生することもあるかもしれません。このようにテスト戦略とテスト計画はワンセットで考えられるものとなります。

ソフトウェアテストについてはこちらをご覧ください。
＞＞ソフトウェアテストとは？種類や目的、重要な7原則を紹介のページへ

テスト計画やテスト計画書に関してはこちらもご覧ください。
＞＞テスト計画とは？目的や種類・作り方・注意点をわかりやすく解説のページへ
＞＞テスト計画書とは？作成方法やポイントをわかりやすく解説のページへ

全体テスト計画と個別テスト計画で、それぞれ重点を置く項目は次の通りです。

テスト戦略では、さまざまな方針が示される可能性があります。例えば、あるテストレベルを強化するためにより多くの工数をかけたり、それに応じてほかのテストレベルの工数が削られたりします。開発の短期化で全体的にテスト工数が減ることもあるでしょう。このような場合は、全体テスト計画書で、各テストレベルの実施基準を見直して工数を調整する必要があります。単純にテストケース数を増減するだけではなく、機能に優先度をつけてテストケースの最適配分を考えることもあるでしょう。

あわせて読みたい
＞＞「良い」ソフトウェアテストの定義～プロが教える４つのポイント～のページへ

一方で新しいツールや開発体制の導入など、新たな取り組みを導入することもあるでしょう。このような場合は全体テスト計画で示すのはもちろんのこと、個別テスト計画でツールの導入時期、学習スケジュール、試行の要否などを計画する必要があります。テスト戦略で提示された内容は、全体テスト計画だけでなく、個別テスト計画にも正しく反映されるように確認する必要があります。

テスト戦略は、「テスト」という名前が付いているために、テスト計画の一部として取り扱われることあります。

しかし、状況によっては、テスト戦略・テスト計画をもっと広い範囲で捉えた方がよい場合もあります。

品質の確認方法はテストだけに限られているわけではありません。レビューや静的解析も品質保証活動に含まれます。テスト戦略のなかであるべき姿を考えたときに、レビューの内容や工数が課題と認識されるケースも十分にあり得ます。このような場合は、テスト戦略の施策としてレビューの改善があげられ、テスト計画もしくはほかの開発方針としてレビューの指針が変更されることになるでしょう。

テスト戦略・テスト計画は、テストの内容だけ検討するのではなく、レビューなどを含めた総合的な品質方針を策定するものだと認識してください。

あわせて読みたい
＞＞「品質」は誰が決めるもの？～改めて「品質」を考えてみる～のページへ
＞＞品質コンサルティング／品質PMOのページへ

「戦略」という言葉は、目的を達成するために、中長期的な視点と大局的な判断によって資源を配分して運用することをいいます。テスト戦略もまさに、組織やプロジェクトの中長期的な視点から、大局的な判断で施策を選択し、それに費用や工数などの資源を配分することになります。

一般的には、次の手順でテスト戦略を立てます。

①組織やプロジェクトのあるべき姿を明確にする
②今回のプロジェクトにおける到達目標を示す
③目標実現のためのテストアプローチを検討する
④テストタイプ・テストレベルへの投資配分を示す

それぞれ詳しく解説します。

数年先に、組織やプロジェクトがどのようになっていたいかを考えます。品質のレベルをいまのレベルからどう進化させたいのか、開発や管理の仕組みをどのように変えていきたいのか、どのような方向性で進みたいのかを明確にします。具体的には、リリース後に発覚するバグを絶滅したいとか、リグレッションテストの工数を削減したいとか、実行管理を効率化したいとか、さまざまな希望が出てくるでしょう。場合によっては、開発手法を転換してアジャイルソフトウェア開発を取り入れたいというような総合的な変革であったり、あるいは現状で困っていることを改善したいというような短期的な要求だったりするかもしれません。

いずれにせよ、ITを取り巻く環境は変化しているので、何かを変えていかないと、流れに取り残されていくばかりとなります。まずは、顧客を含むステークホルダーを中心に、あるべき姿や変わっていく方向性の合意を形成するのが最初の手順となります。

リグレッションテストについてはこちらをご覧ください。
＞＞リグレッションテスト（回帰テスト）とは？目的や自動化のメリットを解説のページへ

アジャイル開発についてはこちらをご覧ください。
＞＞アジャイル開発とは？意味や特徴、メリット・デメリットをわかりやすく解説のページへ

中長期の目標として設定したあるべき姿は1回のプロジェクトでは達成できないと考えるべきです。そのため、そこに至るまでの中間点として、今回のプロジェクトでの到達目標を決める必要があります。このときに知っておくべき考え方として、3つのポイントがあります。

1つ目のポイントは、現状と将来の到達点を正しく認識して、どのようにそのギャップを埋めていくかを意識することです。将来像に到達するには、現状からの改善だけではなく、何かブレイクスルーが必要となることもあります。

2つ目のポイントは、一方向からの視点に囚われず、いろいろな方面から検討することです。バグが残っているならテストを増やすという単純発想だけではなく、レビューやコーディングにも視点を広げることも考えてみましょう。

3つ目のポイントは、やらないことを決めることです。やりたいことは考えはじめると次から次へと出てきますが、すべてを1回のプロジェクトに盛り込もうとすると、どうしても無理が出てきます。数年先に向けた1ステップとして、今回の到達目標を設定するようにしましょう。

もし、今回のプロジェクトで重要な目標があれば、合わせて明確にしておきます。例えば、法改正などのイベントに間に合わせるというような目標です。

このような検討を経て、今回のプロジェクトでの到達目標を決めていきます。

目標が決まったら、それを実現するためのアプローチを検討します。

バグを減らす目標であれば、現状のバグを分析して、どのような工程でバグの作りこみが多いのか、どのようなテストレベルでバグの見落としが多いのかということを明確にします。そうするとどの工程のレビュー、どのレベルのテストを強化すべきという判断ができて、それが時間・工数の問題なのか、それとも作業内容・方法論に問題があるのかを切り分けることになります。

リグレッションテストを効率化したいという目標であれば、まずはテストの自動化に目が向くところですが、単体テストと統合テストとどちらに手をつけるのか、導入するツールやそれに必要な開発者のスキルはどうなっているのか、プロジェクト内で推進できるのか外部からの応援が必要なのか、といった検討になります。

実行管理を効率化したいのであれば、管理指標やチェック周期の妥当性、実行数やバグ数の集計に必要な工数、バグレポートを作成する工数、管理者がメンバーを拘束している時間などを評価して、管理作業の改善やツールによる自動化ができるポイントを探すことになるでしょう。

このように施策の効果や実行可能性を検討しながら、今回のプロジェクトで採用する施策を選んでいきます。

新しい施策を導入するためには、投資が必要になります。単純にレビューやテストを手厚くするとなると、そこに工数を追加する必要があります。またツールを導入するとなると、ツール自体の費用や、導入にかかる訓練の工数を考えなければなりません。

新しい施策を導入するからといって、プロジェクト費用をそのまま増やしてくれるようなケースはあまり多くありません。稀に組織改革への投資として許容されることもありますが、多くの場合はプロジェクトの別のところの工数を減らして対応することになります。しかし、それによって工数を減らした分のレビュー・テストが疎かになって、品質が下がるようでは困ります。そのため、効率化につながりやすい施策を合わせて導入することも考えられるでしょう。例として3つの施策を紹介します。

1つ目は、機能を分析して、重要度別にテスト密度を変える手法です。ITシステムにはよく使われる機能とあまり使われない機能があります。また、業務に重要な機能とあまり影響のない機能があります。よく使われる機能、業務に重要な機能でバグがあると大きく利用者に影響しますが、あまり使われない機能、業務に影響のない機能ではバグがあっても利用者への影響が限定的です。これを分析することで、需要度の低い部分のテスト密度を下げる方向に調整することが考えられます。

2つ目は、導入障壁の低い自動化ツールを検討することです。ソースコードの単体テストは、そもそもドライバを書かないとテストができないので、テストを自動化することの工数増は限定的でしょう。テストの選択肢の組み合わせを自動展開するツールは、手作業に比べてはるかに効率的になるでしょう。要件やインシデントの管理ツールも、目的を見失って余分な管理項目を増やすようなことにならなければ、導入障壁は高くありません。

3つ目は、上流工程のレビューを強化することです。上流工程で書かれたバグがテストで見つかると、そのバグを修正するだけでなくほかの部分にバグの影響がないかを確認するために大きな工数がかかります。バグが見つかるのが遅ければ遅いほど影響範囲が広くなって、確認工数がかかるので、上流工程のレビューを強化することが結果的に総工数の抑制につながることが多いようです。

テスト戦略が明らかになった後に、テスト計画書の作成に進みます。

テスト戦略では方針レベルの合意で、段取りや成果物といったところまでは含まれないため、テスト戦略の内容を実行可能にするためのタスクや指標を決めていくことになります。

テスト戦略は、プロジェクトを成功させるか否かを決定づける非常に重要なものです。プロジェクト戦略を成功に導くために必要なポイントは次の2点です。

・プロジェクトのリスクを考慮する
・プロジェクトの目的を明確にする

テスト戦略の選択を間違えた結果、プロジェクトが失敗してしまう可能性があります。プロジェクトの品質維持をするために、上記の2点を特に意識するようにしましょう。

テスト戦略では、組織やプロジェクトの将来像を考えて立案するために、多くの場合に新しい施策が導入されます。しかし、導入がうまくいかずに、プロジェクトのスケジュールが大きく狂うというリスクもあります。例えば、キャプチャ=リプレイ型の画面操作自動化ツールは、導入は簡単そうに見えても、いざ導入したらHTMLやCSSの深い知識が必要だったというようなケースもあります。

このような課題が発生する前に、リスクとして認識して、発生時の対応をある程度想定しておくことが、失敗の防止につながります。新しい施策は一度に導入せずに、最初は部分的に導入するというようなことも考えましょう。

テスト戦略は非常に重要ですが、プロジェクト全体の目的はテストを通過することではありません。プロジェクトは企業を発展させるためのものであり、そのひとつとしてシステムやソフトウェアの開発があるのです。

テスト戦略は組織やプロジェクトの成長を円滑に進めることにおいて確かに重要ではあります。しかし、前提には企業全体で実施しているプロジェクトがあることを忘れず、ときには中長期目標を犠牲にしてもいまの目標を推進しなければならないことを覚えておきましょう。

テスト戦略は、テスト計画を作成するために必要不可欠な要素であり、企業のビジネスを推進させるために必要なものです。しかし、テストはソフトウェア開発において非常に重要なものですが、テストのクリアが第一優先になってはいけません。企業にとってビジネス戦略のひとつであり、ビジネスを成功させることが求められます。そのために必要になるのがテスト戦略であることを覚えておきましょう。

株式会社SHIFTは、ソフトウェアテストや品質保証サービスで強みをもっており、テスト戦略の設計にも対応しています。過去ご支援させていただいた実績を活かした品質保証が実現できます。テスト戦略の構築でお困りの方は、ぜひSHIFTまでご相談ください。

＞＞ソフトウェアテスト・第三者検証のページへ
＞＞品質コンサルティング／品質PMOのページへ
＞＞導入事例ページへ
＞＞料金についてページへ
＞＞お問い合わせページへ

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座