Loading...

最終更新日時:2024.04.09 (公開日:2023.08.22)

テスト仕様書の書き方 プロが考えるすぐに使えるポイントを教えます

昨今プロダクト開発における検証の重要性が高まりつつある中、さまざまな企業・開発チームで困っていることに「テスト仕様書」の作成があるはずです。ノウハウがないから何を書いたらいいのかわからない!作ったはいいけど別のメンバーがうまく使えない!そんな悩みを解決するためのテスト仕様書の書き方のヒントがここにあります。テスト仕様書のサンプルダウンロードもできますので、現場でお困りのみなさんは是非ご一読ください!

テスト仕様書って何?記載すべき内容とは

「テスト仕様書」は現場によっては「テストケース」と呼ばれたりもしますが、そもそもこれってなんでしょう?プロダクト開発の現場では要件定義~リリースまでに、規模の大小こそありますが必ずテストのステップがあります。「テスト仕様書」とはこのテストのステップにおけるチェックリストを含む資料だと思ってもらえればOKです。そう修学旅行や遠足に行くときに忘れ物が無いか確認するアレですね。簡単な話でテストにおける旅のしおりがテスト仕様書ということです。本記事では「テストケース」と区別するために「テストケース」の集まったファイルを「テスト仕様書」と定義して話を進めていきます。

もちろん旅のしおりですから、チェックリストであるテストケース以外にも様々なドキュメントを内包している必要があります。テストを開始するまでのスケジュール情報、環境設定・環境使用における注意ポイント、データの集計シートなども入っていることもあり現場によって内容はだいぶバラつきがあると思います。本記事ではテスト仕様書に含まれるさまざまなドキュメントの中で、メインのドキュメントといえるテストケースの作成に焦点をあてて話を進めていきます。

その他のドキュメントについてはテストケースの実行が滞りなく進行できるように補助的なものとして、必要に応じた内容のものを付け加えてあげるようにしてみてください。それではテスト仕様書のイメージがついたところで中身について考えていきましょう。本記事をご覧になっている皆さんの中にはきっと、「テスト仕様書ってどんな項目を設ければ効率的に適切なテストになるのだろう?」というお悩みの方も多いのではないでしょうか?そこでまずはバルテスが普段作成するテスト仕様書の内容で最低限抑えるべき項目は以下の通りです。

5つのテスト技法の基本がわかる!
テスト技入門ガイドブック

【テスト仕様書で最低限抑えておきたい項目】

  • テスト概要
  • 実施条件
  • 実行手順
  • 期待結果

各項目について一つずつ簡単にご紹介します。

テスト概要

これは端的に言えばテスト手順ごとの「タイトル」だと思ってください。テストの実施作業において、一連の手順によって何を確認するのかが一目で分かるかといった考え方は非常に重要です。テストの作成時点でケースの重複や不足を防いでくれたり、テスターが実施内容を確認しやすくなるためコミュニケーションエラーが減ったりするメリットが期待できます。

実施条件

ソフトウェアのテストでは様々な条件の考慮が欠かせません。例としてデータ取込のテストを考えてみましょう。データの形式は?データのサイズは?一度にいくつのファイルを取り込む?システム側の取込方式は?内容によるデータの選別は?といった形で一般的な機能に関してすぐに思いつく条件だけでもだいぶ数がありますね。こういった条件の中でも「前提条件」としてテストケースの手順を開始する前に整えておくべき、スタートラインを定義するものです。

実行手順

こちらは実際にテスターがシステムを操作する内容を一つずつ記載したものです。内容は「具体的」「簡潔」を意識することでより良いものになります。開発エンジニアがテスト仕様書を作成する際、ノウハウのありなしに関わらず実施手順を雑に記載しがちです。システムへの理解度が高いことによって抽象的に記載してもなんとなく伝わってしまうのが原因の大半です。このような記載になっているテスト仕様書は良いものとは言い難いです。

期待結果

「実施条件」を基に「実施手順」を流した結果として、「何を確認したいか」を明確に記載する箇所です。実施手順と同様でテストのノウハウが乏しい開発エンジニアによって「わかりにくい」記載が発生しやすい箇所になります。

テストに習熟した専門のエンジニアが、
お客様に必要なテスト計画・設計を立案します!
バルテスのテスト計画・設計支援サービス

「わかりにくい」から考える、テスト仕様書の上手な書き方

では次に「わかりにくい」に焦点を当てて、よりよいテスト仕様書の作成について考えていきます。

結論から言って、テスト仕様書においての「わかりにくい」原因のほとんどは「抽象的で曖昧な記載」です。これを読んだ皆さんは「?・・・まぁ、それは確かに、わかりにくそうですね。」といった感じでしょう、そんな当たり前のことを言われても困るといわんばかりの顔をするはずです。しかし皆さんが無意識にやっている可能性があるので一緒に考えてみましょう。

皆さんがテスターを行った際こんなテストケースに出会ったことはありませんか?

・テスト概要:アカウント登録時の入力機能Aの処理結果確認

・実施条件 :画面Xを表示していること

・実施手順 :1.プルダウンを選択する

      2.テキストボックスへ入力を行う

      3.確定ボタンを押下する

      4.画面Yの結果表示を確認する

・期待結果 :画面Yに表示される機能Aの処理結果が正しいこと。

一見するとしっかりと最低限の記載内容を抑えたテストケースに見えるかと思います。ただこのままテストを行うとテスターは様々な確認作業が発生してしまいます。最初に「実施手順」で2か所の確認です。まずプルダウンでは何を選択するべきでしょうか?プルダウンを利用していることから項目が複数あると予測できます。実際に複数ある場合には「プルダウンから○○を選択する」と選択対象を明記すべきです。またテキストボックスへの入力内容も特に指定されていません。実施手順を見たテスターは任意の入力でいいのか、特定の文字列や入力制限をパスできる内容の入力なのか迷うはずです。

「テキストボックス“△△”へ○○と入力を行う」と指定するのがベストですね。または「テキストボックス“△△”へ任意の有効値で入力を行う」など、テスト結果に影響が出ない範囲程度で幅を持たせることもひとつの手です。そして「期待結果」にも皆さんが意外とやりがちなミスを一つ紛れ込ませてみました。早々に答え合わせをしてしまいますが「処理結果が正しいこと」の記載が良くありません。この期待結果はテスター側からすると結果記載が大変になる原因で、非常に面倒に感じる記載なんです。では何が良くなかったのでしょうか?それは何をもって「正しい処理結果」とするのかが記載から読み取れない点にあります。

今回の用意したテストケースではアカウント登録での入力機能の確認をモデルにしいています。この手の機能では処理結果として「次項目の入力欄が表示される」「入力内容の確認画面へ遷移する」「不正入力にエラーメッセージを出す」などが多いかと思います。例として記載した内容と「処理結果が正しいこと」どちらの方が実施作業に適した記載であるか一目瞭然ですね。さて、ここまでで「わかりにくい」について発見と確認を行ってきました。すべて「抽象的で曖昧な記載」に起因していました。

意外と指摘されないと、違和感を感じにくい記載になっていたのではないでしょうか?作成者自身では気づきにくい&言語化して伝えるのも分析が手間なので、皆さんそのままにしがちなんです。ここまで分かってしまえばあとは簡単ですね!「抽象的で曖昧」を「具体的で明確」な記載に変更すればいいんです。ここで気を付けたいポイントです。「具体的だけど冗長」になっていないか、ここに注意して記載を行っていきましょう!具体的な内容であったとしても、冗長な記載になっていると読み違えや解釈違いが発生します。

こういったミスはテスト結果にも影響を及ぼすことになるため、最悪の場合会社が傾くような大損害や人命への被害が起きることだって考えられます。テスト屋さんと呼ばれる人たちは、こういった細かいところからヒューマンエラーを減らすための取り組みを行っています。余談ですが、冗長な文章の対策として私が普段気にしていることを記載しておきます。これらはやっているうちに自然と身に付いてくるはずですので、テスト仕様書を作成する際に頭の隅にでも置いておいてください。

【冗長になっていないかの判定基準】

  • 一呼吸の間に同じ助詞が登場していないか?(の、は、が、に、を、へ)
  • 「、」は1個までになっているか?
  • 一呼吸で読める文字数が40字以内になっているか?

まとめ

本記事ではノウハウが無くてもすぐに使える、「テスト仕様書の書き方」を「わかりにくい」へスポットを当てて考えてきました。紹介したポイントのまとめは以下の通りです。

【テスト仕様書作成のポイント】

  • 「テスト仕様書」は「テストケース」がまとまったもの
  • 最低限「テスト概要」「実施条件」「実施手順」「実施結果」を記載
  • 記載する際は「具体的で明確」を意識した読みやすい一文を心がける

テスト仕様書のサンプルダウンロードはこちら
※ダウンロードには、Qbookのログインが必要になります。
アカウントをお持ちでない方は、新規登録が必要になります。

ソフトウェアの開発はプログラミングを扱えることももちろん重要です。しかしそれと同じ分だけ作成したものに対する十分な検証が必要です。バルテスでは今回の紹介内容はもちろん、効率的に不具合を検出するためのテスト仕様書を作成いたします。第三者検証サービスを始めとして、品質向上を目指すすべての方々に向け各種サービスを展開しておりますのでお気軽にお問い合わせください。本記事が皆様の品質向上への手助けとなれば幸いです。

当サイトでは、テスト技法を学びたい方、アジャイル開発やマイグレーションのテスト手法について知りたい方、テストアウトソーシングサービスに興味のある方へ、ダウンロード資料を多数ご用意しております。ぜひダウンロードいただき、資料をご活用ください。

CONTACT

お問い合わせ

バルテスでソフトウェアの品質向上と安全を手に入れよう