試験仕様書作成において重要なこと

はじめに

私は試験仕様書を作成したりレビューしたりする業務を担当しています。
今回は、そこで得た気づきについて共有します。
※他の試験にも流用できる内容ではありますが、今回は単体試験にフォーカスします。

こんな人に読んでほしい

• 試験仕様書を作成する人
• 試験仕様書をレビューする人
• 試験を実施する人
• 実装をする人

試験仕様書とは

システムやソフトウェアが要件定義書通りに機能するかどうかのテストをするポイントをまとめたドキュメントです。

仕様書に記載すべき必須項目

試験仕様書とは「誰が何度やっても」「手順が再現できる」「結果が変わらない」ことが重要であると考えます。
そこで私は以下項目を基本構成とし、あいまいな表現や手順とならないよう心がけています。

• 試験対象
• 試験観点
• 前提条件
• 実行手順
• 期待結果
• 実行結果

「ストップウォッチ」機能を提供しているページの単体試験仕様書記載例を示します。
※対象は1機能のみ、デザインや細かい挙動については割愛します。

$\textsf試験対象\hspace{6em}$	$\textsf試験観点\hspace{6em}$	$\textsf前提条件\hspace{19em}$	$\textsf実行手順\hspace{8em}$	$\textsf期待結果\hspace{14em}$	$\textsf実行結果\hspace{4em}$
スタートボタン	ボタン押下機能	・「ストップウォッチ」ページを表示していること ・表示時間が「00:00:00.000」であること	スタートボタン押下	スタートボタンが押下可能であること	OK or NG
スタートボタン	計測時間表示	・「ストップウォッチ」ページを表示していること ・表示時間が「00:00:00.000」であること	スタートボタン押下	時間計測が開始されること	OK or NG
スタートボタン	時間計測機能	・「ストップウォッチ」ページを表示していること ・表示時間が「00:00:00.000」であること	スタートボタン押下	時間計測し続けること(停止しないこと)	OK or NG
スタートボタン	ボタン上文言	・「ストップウォッチ」ページを表示していること ・表示時間が「00:00:00.000」であること	スタートボタン押下	スタートボタンの文言が「スタート」から「ストップ」に変化すること	OK or NG
スタートボタン	ボタン活性化	・「ストップウォッチ」ページを表示していること ・表示時間が「00:00:00.000」であること	スタートボタン押下	ラップボタンが活性化すること	OK or NG
スタートボタン	ボタン非活性化	・「ストップウォッチ」ページを表示していること ・表示時間が「00:00:00.000」であること	スタートボタン押下	クリアボタンが非活性化すること	OK or NG

私がレビューを受けて気付いたこと

• 名称を統一しよう
  • ボタンをフォーカスした際に矢印マークが変化しますが「指のマーク」「手のマーク」「人差し指のマーク」などいくつか名称が考えられます。どれか一つで統一しましょう。これは記載箇所が異なったとしても同様です。

• あいまい言葉を使用しない
  • そこ、上の(下の)、しっかり、きちんと、正しい、色の指定　などあいまい(に受け取られる可能性のある)言葉の使用を避けましょう。
    • 悪い例）スタートボタンが正しく機能すること
    • 良い例）スタートボタン押下で時間計測が開始されること
    • 悪い例）計測時間が青色であること
    • 良い例）計測時間が青色(#00AAFF)であること
• 記載方法を統一しよう（インデント揃え、連番　など）
  • 実行手順列に複数手順を記載する必要がある場合、ある箇所では「-(ハイフン)」揃え、ある箇所では連番などせずに、いずれかの記載方法で統一しましょう。
• 箇条書きしよう
  • 文章が長くなってしまう場合には箇条書きしましょう。
    • 悪い例）前提条件としてページへ遷移していてかつ表示時間が0であること
    • 良い例）
      前提条件として以下を満たしていること
      ・「ストップウォッチ」ページを表示していること
      ・表示時間が「00:00:00.000」であること
• 上から下へ、左から右へ進もう
  • あっちこっちに視線が飛ばないように記載しましょう。No10の試験をしているのに、No3とNo5を参照する必要がある　など
• 仕様書からすべての情報が読み取れるようにしよう
  • 試験は実装者以外が実施するのが良いとされています。その際、テスト担当者が詳細仕様を知るためにSlackのやり取りやGitHubの特定ブランチを探すなどすると大変です。試験をする上で必要となる情報や資料はリファレンスとしてまとめましょう。
• 入力値が必要な場合はコピペさせよう
  • 値を入力させる試験については、テスト担当者が誤った値を入力する可能性があります。テスト値を記載し、コピペできるようにしましょう。

これから試験仕様書を作成する人へ伝えたいこと

仕様書の作成は試験対象の規模が大きく、また複雑であるほど大変な作業です。
私もイチ仕様書で1000件を超える試験を記載しています。
しかし「誰が何度やっても」「手順が再現できる」「結果が変わらない」仕様書とするために、私が大切に感じることを記載します。

• 最初から100%を求めない
  • 作成者により若干の個性は出るものですし、レビューアによっても指摘箇所は様々です。レビューを重ねることでより良い仕様書が出来上がりますので、修正は必ず発生するもの！くらいの心持ちで取り組みましょう。
• 読み手のことを考えて作成する
  • この書き方ではわかりづらいかな？意図伝わるかな？と常に考えながら作成しましょう。
• 凝ったものは作らなくて良い。読みやすいものを
  • 色にこだわったり、特殊な記号を使用したりする必要はありません。読みやすく誤りのないものを作成しましょう。
• 単体試験の重要性について意識する
  • (本題から逸れますが)ほとんどのバグは単体試験によって見つけることができます。また、後工程で発見されるバグほど修正コストが高くつきます。大変な作業かもしれませんが、単体試験は品質向上のため重要なタスクであることを理解して取り組みましょう。

まとめ

今回は試験仕様書作成において重要なことについて記載しました。
作成が初めての人も、慣れている人も、本記事を通して改めて考えるきっかけになれば良いなと思います。
みなさんの仕様書が少しでもより良いものになれば幸いです。
ここまで読んでくださりありがとうございました！