若手のエンジニアがキャリアを積んでいくと、結合テストのテスト設計を任されるタイミングが訪れます。 初めてテスト設計を行う方の中には、何から手を付ければいいのかわからず、途方に暮れてしまう方もいるのではないでしょうか。

プロジェクトによっては、開発工程からではなく、テスト工程から参加することもあり得ます。そうなれば、システムやソフトウェアの仕様を一から把握しなければなりません。

要件定義書など、プロジェクトの上流で作られるドキュメントの読み込み方を知らないと、テスト設計で思わぬ失敗をしてしまう可能性があります。経験を積むことで、避けることができる失敗ですが、コツをつかむことで、すぐに回避することができます。

この記事では、テスト設計でやりがちな２つの失敗と、失敗を避ける3つのポイントに加えて、テスト設計のクオリティを上げるための方法も紹介します。

テスト設計のミッションとは

テスト設計とは、テスト観点とテストケースの両方が記載されたテスト仕様書を作ることです。

テスト観点とは、システムやソフトウェアの機能が正しく動作するために、どのようなテストが必要か、その視点をまとめたものです。例えば、「ボタンを押すと仕様通りに画面が遷移するか」といったものです。

テストケースとは、テスト観点をもとに、どのような手順と入力する値でテストを行い、どのような結果が得られるのか、期待結果をまとめたものです。

テスト設計をするためには、まずテスト観点をまとめることです。このテスト観点は、システムやソフトウェアの機能を理解していなければ、まとめることはできません。つまり、要件定義書を読み込み、機能を理解することが、テスト設計の第一歩なのです。

テスト設計で犯しがちな２つの失敗とその原因

初めてテスト設計をするエンジニアの方は、要件定義書を読み込み、過去に作られた、似たようなシステムやソフトウェアのテスト仕様書を参考にしながら、新たなテスト仕様書を作ろうとするでしょう。

テスト観点をまとめ、いざテストケースを作ろうとした段階で、犯しがちな失敗が2つあります。ここでは、どうして失敗するのか、その２つの失敗と原因を説明します。 

失敗１ 要件定義書の内容を書き写しただけでテストケースを作ってしまう

せっかく要件定義書を読み込んだのに、要件定義書を書き写しただけのテストケースができてしまった経験はないでしょうか。要件定義書をコピー（copy）＆ペースト（paste）して、語尾を「～検証する」などと修正（modify）して作られるため、CPM法と揶揄される作り方です。

「ログイン画面では、管理画面にログインするためのフォームを表示する」

これを参考に、CPM法でテストケースを作ると、次のようになります。

「ログイン画面では管理画面にログインするためのフォームが表示されることを確認する」

これでは、どのようなフォームが表示されるのかわかりません。結果、テストを行う担当者は、テストの結果をどう判断していいかわからず、テストケースを作った担当者に確認する、時間のロスが発生します。テストを行う担当者が確認してくれればいいのですが、勝手に判断してテスト結果をOKとしてしまう可能性もあります。

失敗２ 過去のテスト仕様書を流用してテストケースを作ってしまう

過去に作られた、似たようなシステムやソフトウェアのテスト仕様書を参考にして、今回の要件定義書にあてはめてみたら、テスト仕様書ができあがったように見えます。

しかし、システムやソフトウェアに同じものはありません。もちろん、要件定義書も同じものはありません。要件定義書を読み込み、機能の背景を理解していなければ、一見テストできそうで、正しい動作なのかどうか判断できないテストケースを作りかねません。要件定義書の内容を書き写しただけでテストケースを作ってしまったときと同じように、時間のロスが発生するだけでなく、テスト担当者が勝手にテスト結果を判断してしまかもしれません。

失敗する理由はテスト工程での心構えができていないから

テスト設計でこのような失敗をしてしまうのは、どうしてでしょうか。

それは、要件定義書を読み込み、機能を理解したうえで、どうすれば機能が正しいと判断できるのかという発想を持ったうえでテスト設計を行うという意識が欠けているからです。

テスト設計において要件定義書を参照し、過去のテスト仕様書を参考にするのは必ずしも間違いではありません。しかし、過去のテスト仕様書には記載されていない要件定義書を読み込むというプロセスを経て、テスト仕様書は作られていることを念頭に置きましょう。

また、単体テストレベルでは要件定義書の一部しか参照しなかったかもしれませんが、結合テストレベルのテスト設計では、全体を俯瞰して読むような視点の切り替えが大事です。

テスト設計は、まず要件定義書をじっくり読み込むことからはじまります。効率がよい方法はなく、地道なものです。

テスト設計の失敗を回避する３つのポイント

テスト設計において、要件定義書を読み込むことが何より重要だということは、理解していただけたでしょうか。

テスト設計に近道はありません。要件定義書を読み込むことは難しいことですが、ポイントがあります。ここでは、そのポイントを3つ紹介します。

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

要件定義書の中でも、機能を説明するドキュメントは複数あって、どこから読めばいいか分からなくなっていませんか。ひとつずつ、頭から最後まで読まなければいけないと思いがちですが、要件定義書は、教科書とは違います。重要な結論を最初に読むことで、全体の機能が把握しやすくなります。

要件定義書の厳密性を確認する

要件定義書に書かれている内容があいまいだと、機能もあいまいになり、テスト設計まであいまいになってしまいます。テスト設計を行うには、内容を確認して、厳密にする必要があります。

例えば、エラーログが出力されると書かれていても、どのような種類のエラーなのか書かれていない場合、あいまいなテストになってしまう可能性があります。

要件定義書の漏れ・情報不足をチェックする

要件定義書の情報が欠けていたり、不十分だったりすることがあります。単純に漏れている場合もあれば、要件定義を行った担当者と、クライアントとの常識や暗黙の了解で省かれている可能性も考えられます。後になって、「そういうつもりではなかった」ということが起きないように、常識や暗黙の了解で、要件定義書に書かれていないことも、テストしなければなりません。

例えば、エラーログが出力されることは当然だと要件定義を行った担当者とクライアントが思っていたり、単純に書き漏れていたりした場合、要件定義書にエラーログが出力される仕様が書かれておらず、結果的にテストが漏れてしまうかもしれません。

テスト設計のクオリティを高める4つの方法

テスト設計の良し悪しが、システムやソフトウェアの品質を決めるといっても、過言ではありません。テスト観点を洗い出し、テストケースを挙げることは通過点といえるでしょう。ここでは、テスト設計のクオリティを高めるための、4つの方法について説明します。

テスト設計のレビューを行う

要件定義書を読み込み、テスト観点を洗い出すことができたら、要件定義書を作った担当者にレビューしてもらいましょう。 要件定義書を作った担当者は、このシステムやソフトウェアの仕様について一番詳しい人です。レビューしてもらうことで、テスト観点の漏れを防ぐことができ、システムやソフトウェアの品質向上にもつながります。

ここでのポイントは、テストケースを作る前にレビューしてもらうことです。細かいテストケースの一覧を見せることで、大本になるテスト観点のチェックがおろそかになり、テスト観点が漏れてしまうかもしれないからです。テスト観点の段階でレビューしてもらうことが肝心です。

テストケースの偏りをなくす

テスト設計において、テストケースを漏れなく洗い出すことも重要です。しかし、テスト設計を行うときに、自分では気づかないうちに、テストケースが偏ってしまう場合があります。

過去によく似たシステムやソフトウェアのテストをしたために、よく理解している機能や、要件定義書を作った担当者と話しやすい機能だったために、起こりうることです。無意識のうちに、テストケースが偏っていないか、客観的な目で確認しましょう。

実際のユースケースを想像する

実際にシステムやソフトウェアを利用するユーザーが、どういった目的や状況で使うのか、想像しましょう。ユーザーの視線に立って考えることは、開発工程だけではなくテスト工程でも重要なことです。

例えば、ヨーロッパに向けた日本観光情報サイトで、外国人向けの会員登録フォームなのに、漢字での氏名入力欄を考えても意味がありません。細かい仕様まで把握することで、テストすべき内容が見えてきます。ユーザーがどのように使うのか、実際のユースケースを十分に想像して、テスト設計を行いましょう。

要件定義書を作った担当者とコミュニケーションをとる

テスト設計を初めて任されたのですから、わからないことが多くあって当たり前です。要件定義書を作るようなベテランともなれば、声をかけづらいこともあると思いますが、気後れせずに質問しましょう。

わからないことをわからないまま、テスト設計を行ってしまうことで、テストの品質、ひいてはシステムやソフトウェアの品質を下げかねません。要件定義書を作った担当者とコミュニケーションをとることも、テスト設計においては重要な仕事です。

まとめ

初めてのテスト設計は、誰でも壁にぶつかるものです。だからといって、ネガティブに考えることもありません。テスト設計に近道はありませんが、コツがあるからです。

まずは、要件定義書を読み込むこと。その時に、今回紹介した3つのポイントを、ぜひ思い出してください。