テスト仕様書を書いてくれと言われてもそのフォーマットは多種多様なものがあります。IPAなどの機関がフォーマットを定義していることもないため、新卒の新人でも渡されたテスト仕様書のフォーマットを見て「こんなフォーマットで良いのか…？」と戸惑う人もいるのではないでしょうか（実際僕がそうでした）。今回は試行錯誤して独自にテスト仕様書のフォーマットを固めてきたので、テスト仕様書の書き方とフォーマットについて公開したいと思います。
テスト仕様書とは
テスト内容によってフォーマットや書き方は多種多様
国内のテスト仕様書の多くはExcelで書かれているのではないかと思います（Googleスプレッドシートを含めて）。そのExcelファイルでもテストの内容によって書き方は変わってきます。
- 単体テスト
- シナリオテスト
- 回帰テスト（レグレッションテスト）
今回はシナリオテストに焦点を当てます。ちなみに単体テストはユニットテストとして開発者（プログラマー）が自動化して品質を担保している必要があるもので、本来は仕様書は不要なはずです。回帰テストも回帰テストの仕様書があるケースや、今まで発生した不具合を再度チェックするなど会社や組織によってやり方は様々でフォーマットや下記型定義は難しいです。
シナリオテスト仕様書とは
実際にエンドユーザーが使用するシナリオ（ストーリー）を具体的な手順に落とし込んで問題なくソフトウェアが動作するか確認するのがシナリオテストです。受け入れテストがシナリオテストであることも多いかと思います。シナリオテスト仕様書はシナリオテストの手順と正しい挙動の定義、テスト結果をまとめたドキュメントとなります。
テスト仕様書の書き方
テスト仕様書で抑えるべきポイント
テスト仕様書を書く上で抑えておくべきポイントは下記の通りです。
- 誰がいつ、何をどういう環境でテストしたかが分かること
- 誰がテストを実施しても同じ結果になること
- 誰がテストを実施しても合格か不合格が判断できること
誰がいつ、何をどういう環境でテストしたかが分かること
テスト仕様書に限った話ではありませんが、テスト仕様書には誰がいつ実施したのか、テスト対象と環境は何を使ったのか書き残しておかなければなりません。
- XXXXXXアプリケーション v0.8.2
- 2018/11/10
- Keita
- Windows10 64bit Home
最低でもこのくらいは無ければテスト仕様書としてマズいです。対象のソフトウェアは当然のこと、バージョンを記述しておかなければ後日再確認できません。Windows10 64bit Homeなどの環境も同様です。これらの情報がなければ不具合が修正されたのか、バージョンやWindowsの違いのせいで問題が再現しないのか判断ができなくなります。テスト環境についてはメモリやCPUまで書いた方が良い場合もあります。また、Windows10はビルド番号も残しておいた方が良いでしょう。
誰がテストを実施しても同じ結果になること
テスト仕様書には操作手順を必ず書きます。例えばエレベーターのテストの操作手順だと、次のようにAとBのパターンがあります。
A. ダメな操作手順
4階に行く
B. 正しい操作手順
1. 上ボタンを押下する 2. 扉が開いたらエレベーターに乗る 3. 4階のボタンを押下する 4. 4階で扉が開いたらエレベーターを降りる
誰がテストを実施しても同じ挙動をするためには手順を細かくかみ砕く必要があります。Aの操作手順はエレベーターの使い方を知っていることが前提で書かれており、エレベーターの使い方を知らない人は「どうやったら4階に行くことができるのか？」となってテストを実施できません。「やり方が分かりません」と質問してくれるならまだ良い方で、「たぶんこうだろう」と判断して実施した方法が間違っていたら最悪です。例えば極端な話、テスト実施者はエスカレーターを使って4階に行くかもしれません。エレベーターに致命的な不具合があっても、不具合がないというテスト結果になってしまう可能性があります。（Bのテストもテスト実施者が4階より下にいる前提になっているため前提条件を書く必要があるが、本題ではないので割愛）
誰がテストを実施しても合格か不合格が判断できること
テスト仕様書には正しい挙動も必ず書きます。例えばエレベーターのテストの正しい挙動定義を次のように比較してみしょう。
A. ダメな挙動定義
エレベーターが正しく動作すること
B. 正しい挙動定義
1. 上ボタンが白く点灯すること 2. 到着音とともに扉が開くこと 3. 4階のボタンが白く点灯すること。4階に向けて移動すること 4. 到着音とともに扉が開くこと
極端すぎると思うかもしれませんが、実際に新卒で入社した会社のテスト仕様書はAでした。何が正しい動作か分からなかったので全然テストを実施できず、質問を都度するハメになりました。また、この挙動を書くときに色や文言も大事なので事細かく定義します（実際には開発前に仕様が決まってるはずなので仕様を書くことになります）。
テスト仕様書のフォーマットとは
テスト仕様書のテンプレートを作りました
参考までにテスト仕様書のテンプレートを作成したのでGithubにアップしました。ScenarioTestSpecificationSample.xlsxをクリックしてDownloadボタンを押せばダウンロードできます。
github.com
テスト仕様書にはタイトルが必要
ここにテストについての説明や実施日、実施者を書いておきます。テスト環境もここに書いて良いですが、シナリオによって環境を変える場合もあるので、僕は環境は各シナリオで定義していることが多いです。あとはテスト完了後に所要時間や各結果の総数をここに書いておくと後日見直したり再度テストする場合に便利です。
各項目の説明
テンプレートでは1つのシナリオに1つのタブを割り当てています。各項目の説明は下記の通りです。
- No：行番号
- Result：テスト結果のステータス
- Testcase：何をテストするのか？を書く。「～できること」と書くと良いかも
- Procedure：テストの実施手順。誰でも同じ挙動となるように具体的に
- Predict：テストを実施して想定される挙動。Procedureの番号と紐づいて書いておくと良い
- Memo：気になることなどがあったらここに書いておく
テスト結果は少なくとも3つのステータスが欲しい
テスト結果は少なくとも3つのステータスが欲しいです。
- OK
- Attention
- NG
テストを実施していると「これ仕様にはないけど合ってるのかな？」と気づくことがあります。そのときはAttentionにしておいてMemoに書いておきます。例えば同様にエレベーターのテストで考えると、
- 仕様には白く点灯と書いてあるが、背景と同化して点灯しているか分かりにくい
- 移動中に現在の階が白く点灯していたけど、これは挙動として合ってる？
など書いておきます。AttentionはOKにもNGにもなる可能性があるステータスというわけです。個人的にはステータスに応じてセルを塗り替えたほうが全体を見渡せて良いと思います。
Predictには画像も積極的に貼りたい
正しい挙動を文章で細かく具体的に書くことは大事ですが、伝わらないこともあります。伝わらなかったせいで不具合が合格になることを防ぐためにも、積極的に正しい挙動の画面キャプチャは貼っていきたいところです。
