テスト設計とは？プロセスや失敗しないためのポイントを解説
COLUMN

ソフトウェアの開発段階で想定していなかったバグや不具合を洗い出し、リリース前に修正するにはテスト工程が必要です。ただし、単にテストを行うだけでは、テストの抜け漏れが発生したり、反対にしなくてもよいテストを行ってしまったりする可能性があります。そのため、テスト工程では、事前にテストを分析して設計を行い、適切なテストケースを作成する「テスト設計」が行われます。テストの信頼性や精度を高めるために、テスト設計は重要です。

この記事ではテスト設計とテスト計画の違い、テスト設計のプロセス、テスト設計を失敗しないためのポイントについて解説します。

1.テスト設計とは

テスト設計とは、テスト工程で実施すべきテストの種類や実施方法、必要なデータ、テストの入出力に使用するものなどを具体的に決めることです。テスト設計は、テスト計画と同じく不具合の発見や品質確認のために必要なフェーズです。

ソフトウェア開発におけるテストとは、プログラムを動かして結果を確認することだけではありません。プログラムを動かすまでの事前準備や、動かした後の結果報告までを含んだ一連の流れを指します。テスト全体の中で、テスト設計は事前準備の一種にあたるフェーズです。

ソフトウェア開発のテストでは、プログラムを漫然と動かすのではなく、要求事項や設計などを満たしているかを客観的に検証する必要があります。そのため、テスト設計によって「何をどのように確認し、結果はどうあるべきか」をあらかじめ定めておくことが大切です。

テスト自動化ツールならATgo

1-1.テスト計画とテスト設計の違い

テスト設計と似た言葉に「テスト計画」があります。テスト設計とテスト計画は、どちらもテストの事前準備として行われるものの、役割は大きく異なります。

バグや不具合を防ぐためには、入念なテストが必要です。一方で、テストにかけられる予算や時間・人員などは限られています。そこで必要となるのがテスト計画です。

テスト計画では、限られた予算や時間などの中で不具合を見つけていくために、テストの目的や方針、注意点、方向性やスケジュールなどをまとめます。テスト計画の内容は基本的に、テスト計画書にまとめられます。テスト設計は、テスト計画で作られた計画書を元に行われるものです。

テスト計画からテスト設計へと段階を踏むことで、テストの信頼性やテスト品質を高めることが可能になります。

テスト計画書について詳しく解説｜目的や記載方法・作成のポイントも

2.テスト設計のプロセス

テスト全体のプロセスは、大きく分けて以下の通りです。

上記のテストプロセスのうち、テスト設計段階で行うプロセスには「テスト分析」「テスト設計」「テストケース作成」の3つがあります。テスト設計業務の各プロセスについて解説します。

製品情報 | テスト自動化ツールならATgo

2-1.テスト分析

テスト分析とは、これからテストを行うシステムの仕様について、テストベースを整理・確認して分析する作業のことです。テストベースとは、以下のようなテスト分析の情報源となるものを指します。

ソフトウェア開発において、テスト工程は必ずしもプログラマーが行うとは限りません。テスターやデバッカーなど、テスト技術に精通する人材が担当するケースもあります。

テスト担当者がプログラマー以外の場合、テストベースを確認し、テスト設計を行うための仕様を理解することが必要です。仕様を理解してテスト設計に必要な情報を導き出すための工程がテスト分析となります。

また、テスト分析の段階でテストベースが不足していたり品質が悪かったりするケースもあります。そのため、必要に応じて成果物の作成やレビューを実施することが大切です。

2-2.テスト設計

テスト設計とは、テストをどのように実施するかを考えるフェーズです。テスト設計では、テスト分析の結果を元に、必要となる条件・要件を満たすための具体的なテストケースを作成します。この際、抜け漏れや重複のないテストケースを作ることが望ましいです。また、テストの際の操作や期待している結果にくわえ、必要なテスト環境や事前準備などを明らかにすることも重要になります。

開発の手戻り防止やプロジェクト全体の業務効率化が期待できるのが、テスト設計工程の大きなメリットです。テスト設計の分析技法の例としてはホワイトボックステストが挙げられます。

ホワイトボックステストとは？ブラックボックステストとの違いまで解説

2-3.テストケース作成

テストケースとは、テストの手順や、テストに必要なデータ・条件・求める結果などを文書化したものです。ソフトウェアテストを実施するために参照すべき説明書とも言えます。

テストケースは、以下のような条件を埋めることで作成されます。

例えば、足し算を行うプログラムをテストする場合、テストケースは、以下のような内容になります。

テストケースは、テストを実行するための手順書です。特に、テストケース作成者とテスト実行者が別にいる場合、作成者だけではなくほかの人が読んでも理解できる文章で作成することを心がけましょう。

また、テストケース作成の際には、テスト観点の設定が特に重要になります。テスト観点があいまいな場合、顧客が何を望んでいるのかを十分に理解しないまま作業を進めることになり、テストの品質が落ちてしまいます。

3.テスト設計を失敗しないためのポイント3つ

精度の低いテスト設計を行うと、テストを行ってもソフトウェアのバグなどを検出できず、テストが失敗に終わる可能性が高くなります。ソフトウェアテスト設計を失敗しないために押さえておくべきポイントを3つ紹介します。

料金プラン | テスト自動化ツールならATgo

3-1.要件定義書を結論から読む

テスト設計を失敗しないためには、要件定義書を結論から読み、重要な項目を理解するのが大切です。要件定義書を結論から読むことで、ソフトウェア全体を俯瞰でき、システム・サービス運用の目的や重要な機能などを効率的に理解しやすくなります。

要件定義書を単に丸写ししてテストを設計する場合、そのシステムやサービスが想定しているユーザーが分からないため、正確に行動を予測してテストを設計できません。結果として、テストケースに記載すべきパターンが抜け漏れたり、具体性が欠けたりして、テストの制度が下がってしまいます。

要件定義書をそのまま丸写ししてテストするのではなく、要件定義書の要点を押さえていれば、実際の運用方法に近い筋が通ったテスト設計作成が可能になるでしょう。

3-2.テストケースの品質を揃える

テストケースを作成する前に作成方針を決定し、検討内容を資料として残すことで、品質を可能な限り揃えることが大切です。

いきなりテストケースを作成すると、テスト設計者ごとにテストケースの品質にばらつきが生じる恐れがあります。よくあるのが、同じ内容を担当者ごとに違う言葉で表すケースです。表記のばらつきはテスト業務の実行者を混乱させ、思わぬ失敗やトラブルを招きかねません。

また、事前に客観的な視点による検討をしなければ、テスト設計者が無意識に過去の類似案件と同じようにテストケースを作ってしまう可能性がある点も問題です。過去の類似案件をそのまま適用してしまうと、本来システムやサービスが想定していたユーザーの行動とずれが生じ、記載すべきパターンが抜け漏れる恐れがあります。例えば、日本人向けの氏名入力欄をテストするときに、アメリカ人の氏名入力欄をテストしたときのテストケースを流用すると、漢字の入力のバグを見つけられません。

事前に方針を検討・決定し、資料を残していれば、テストケースの品質のばらつきや偏りを防ぎ、精度が高く漏れのないテストを行えます。

3-3.要件定義書の作成者にレビューしてもらう

要件定義を読み込み、テストケースの洗い出しが完了したら、要件定義書を作った担当者にレビューしてもらうとよいでしょう。

要件定義書の作成者は、そのシステム・ソフトウェアについて1番詳しい人と言えます。そのため、作成者にレビューしてもらい、テストケースを直接確認することで、項目漏れなどがないかをチェックすることが可能です。また、システム・ソフトウェアの品質向上にもつながります。

レビューにあたっては、細かい項目を確認してもらうのではなく、主にテスト観点についてチェックしてもらうのがおすすめです。要件定義書の作成者にテスト観点をチェックしてもらうことで、テストの方向性が正しいかどうかが分かり、より的確にテストが行えます。

まとめ