テスト設計では「ユーザー視点」を持つことが大切ですが、この言葉の意味を理解できているWeb制作担当者は少ないかもしれません。

失敗しないテスト設計を作成するために、予め知っておくべきことをまとめました。

まずはテスト設計の意味するところから見ていきましょう。

テスト設計とは？

テスト設計とは「テストする内容を決めること」を指します。

ここでいう「テスト」とは、システムやサービスが上手く作動するかをチェックするためのテストのことです。

つまり、テスト内容の「詳細」や「想定される結果」を予め作成しておくことが「テスト設計」ということになります。

より細かく説明するならば、「テスト観点」と「テストケース」が記載された「テスト仕様書」を作ることがテスト設計の意味するところなのです。

テスト観点とは、システムやサービスが正しく作動するために、どのようなテストが必要なのかの「概要」をまとめたもので、テストを実施することの重要性を伝えるものになります。

また、テストケースは、そのテスト観点をもとに、ユーザーの利用状況によって変化する行動を「パターン」として事前に記しておくものといえます。

テスト設計は「テストの事前計画を記したもの」と覚えておきましょう。

なぜテスト設計が必要なのか

テスト設計が必要な理由は、「リリース後の事故を防ぐこと」と「リリース後の不具合にかかる工数の削減」の2つにあります。

システムやサービスをリリースした後に「テストをしていれば未然に防ぐことができた事故」が発生した場合、企業の信頼は落ち、誰も使わないシステム・サービスとなってしまう恐れがあります。

また、企業の信頼を著しく低下させるような事故ではなかったとしても、本来の運用に戻すまでの労力が余計にかかってしまいます。

つまり、テスト設計は、システムやサービスを使う「ユーザー」および「運営者」を守るためのプロセスなのです。

テスト設計で失敗する理由

テスト設計で失敗するそもそもの原因は、「要件定義書を読み込む」というプロセスの重要性を理解できていないためです。

テスト設計におけるテスト仕様書には、要件定義書に書かれた機能がどのような動きをすることが正しいのかを明記しておく必要があります。

しかし、「忙しい」や「面倒」といった理由で要件定義書の読み込みを疎かにすると、テストで行うべき項目がチェックできずに（あるいは見過ごされて）実際の運用へと移ってしまうことになります。

これではテスト設計を行う意味がありません。

この記事を読んでいるWeb制作担当者は、テスト設計以前の段階で失敗してしまわないように注意しましょう。

とはいえ、要件定義書を読み込むだけで、効果のあるテスト仕様書が作成できるわけではありません。

次の2つの点に注意することで、失敗しないテスト仕様書作成のスタートラインに立つことができます。

要件定義書の内容をそのまま書き写す

要件定義書には、システムやサービスがどのように動くことで目的が達成されるのかが書いています。

その要件定義書の内容をテスト仕様書のテストケースとしてそのまま書き写すと、テストで失敗する可能性が高まってしまいます。

なぜなら、テストケースにはユーザーの様々な行動を想定した上で得られる結果（パターン）を書くべきなのであり、1つの理想的なユーザー行動を記すものではないからです。

実際のユーザー利用を考えれば当然のことではありますが、要件定義書の内容を受けて、想定されるユーザー行動をパターンとして記載していくことが重要といえます。

過去に使用したテスト仕様書を流用する

過去にリリースしたシステムやサービスと似たような（あるいは同じ）機能を使用する場合でも、テスト仕様書の流用には注意が必要です。

過去の制作物を参考にするのは、効率の観点から見て必要なことではありますが、あくまで参考程度に留めましょう。

実際のテスト段階になって、テスト仕様書に書かれている内容と異なる動きが発生した場合、テスト担当者はテスト仕様書を作成した担当者に「正しい動きかどうか」を確認するロスが生まれます。

あるいは最悪の場合、テスト担当者によって見過ごされてしまう可能性があることも覚えておかなければなりません。

テスト仕様書に書く内容にはそれだけ正確なものが求められ、かつ責任が伴うものだと理解しておきましょう。

抜け目のないテスト設計を作成するコツ

テスト設計の作成には、「要件定義書を結論から読む」「要件定義書を作成した担当者からレビューをもらう」「スケジュールを決める」といった3つのコツがあります。

それぞれのコツを実践することで、抜け目のないテスト設計を実現することが可能です。

要件定義書を結論から読む

要件定義書を結論から読むことで、そのシステムやサービスを運用する目的を素早く理解することができます。

その後に要点を押さえていくことで、ブレのないテスト設計が作成できるようになります。

要件定義書を作成した担当者からレビューをもらう

要件定義書はシステムやサービスを作るエンジニアが作成します。

そのエンジニアにテスト観点やテストケースを確認しておくと、項目漏れがないかをチェックすることが可能です。

要件定義書を読み込み、テストを行うことの意義や方向性をまとめた上で、要件定義書を作成した担当者からレビューをもらいましょう。

スケジュールを決める

テスト設計におけるテスト仕様書には、テスト観点やテストケースといった実際に行うテストの「中身」を記述することが多くなります。

したがって、テスト設計段階では、テストの実施スケジュールを予め決めておくことが重要です。

テストケースの内容は詳細であればあるほど良いとされますが、セクションごとに期限を決めておかないと、リリース前に必要なテストを行えなくなる可能性があります。

システムやサービスを利用するユーザーのためにも、抜け目のないテスト設計が必要なのです。

テスト設計で確認する項目

テスト設計では、上述してきたように「テスト観点」と「テストケース」、「テスト実施手順」や「想定される結果」などを確認しておく必要があります。

要件定義書の読み込みを行い、要件定義書作成者とテスト観点およびテストケースの確認を行った後、細かなスケジュールを決めていきましょう。

ユーザー視点のテスト設計が必要

テストがリリース前に行われることを考えると、テスト設計が「テストのためのテスト設計」となってしまう恐れがあります。

テストの実施の目的は、あくまでユーザーの快適な利用や運営側の労力削減です。

本来の目的を見失わないためにも、ユーザーから見たシステム・サービスのテスト設計を行うようにしましょう。

（画像はPixabayより）