テスト仕様書を改善しよう
テスト仕様書は、システムテストや動作テストを実施するのに不可欠であり、ソフトウェア等の開発において、テスト仕様書は品質を担保するための重要な指標となります。テスト仕様書に記載されている内容が詳細であればある程、再利用する際や資料として見直す時の価値は上がります。つまり、単純な成果物としてだけでなく、チーム全体で活用できる資料として利用出来るようになるべきなのです。今回はその点の改善方法などを探っていきたいと思います。
1. テスト仕様書の内容について
テスト仕様書を作成・利用していく上で注意したいのは、テスト仕様書はそのテストを担当する人だけのものではないという事です。作られたテスト仕様書は、テスト担当者やシステム開発者等も目にする事もあります。以前の内容にもありましたが、経験豊富な担当者だけでなく、初めて行う初心者でも利用出来る内容であるべきです。つまり、内容が専門用語に偏っていたり、既に知っている内容について簡略化しすぎてはいけません。
- テスト仕様書はテスト担当者の専用ではない
- テスト内容は専門内容を多用しすぎない
- 繰り返し行われ、既に知られている内容を簡略化しすぎない
テスト実施者がテスト仕様書を作成した場合、知らず知らずのうちに上記の事が行なわれている事は珍しくはありません。テストの効率化の点では、テスト実施者の手によって最適化されているとも言えるかもしれませんが、その他の人達にとってはそうではありません。
つまり、テスト仕様書を改善するためには「テスト仕様書としての最適化」が必要になり、「個人利用特化のテスト仕様書最適化」は行われるべきではないと言う事です。
少し具体的な例を出してみると以下の様な比較になります。
2. 仕様書の記載内容の密度について
テスト仕様書に記載する情報は、詳細であればある程にミスや取り違えが減ります。多くの情報をテスト項目に記載すれば、様々な資料を行き来する事なく一つで完結できるようになるわけです。しかし、多くの情報を記載すると同時に「文字量が多すぎて内容を把握しずらい」と言う事象が発生してしまいます。これを回避する為にテスト仕様書、テスト項目に記載する内容密度を調整する必要があります。
要するに「大量の内容を書くのはよくない」という話なりますが、先程の内容と正反対になってしまいます。ここがテスト仕様書を改善していく上で難題となります。内容が多すぎても、内容を簡略化しすぎても駄目となるからです。ではどうしたら良いのか？
- 1つの画面に関する内容は、テスト仕様書のグループでひとまとめにする
- 画面遷移等の一度の操作で理解出来る部分は、繰り返し記載しない
- 内容が複雑化するものは、通常のテスト項目とは別に分ける
上記の様な工夫をしていく事が大事になります。必要な情報を選び取り、一連の操作の中で繰り返しとなる部分については記載箇所を一か所にしぼったり、重要な動作に関わる部分は具体的に記述し、単純な入力確認などは共通化・簡略化する等を行います。これにより大量の文字によってテスト実施者が、項目内容を確認する際に情報の取りこぼしが起きない様にする訳です。
テスト項目を順番に確認する際、単純な横移動ではなく階段的な目の動きが出来る様に作られているのが理想ではあります。他には特定のパターンを記載するテンプレート通りに記載するテスト項目シートや、複雑な手順を必要とするテストの為の自由に内容を記載シートといったものを作ったりするのも良いでしょう。
例えば以下の内容のテストがあったとします。
この場合、同じ内容の画面(ログイン画面)とバリデーションについての説明が記載されています。No1は1回目のテストなので記載されていても問題ありませんが、同じ画面内での操作が続く場合、No2以降も毎回記載していると徐々に情報過多となり、本当に確認したい部分が埋もれる可能性があります。なので、ログイン画面や()内に記載している情報は『前提条件』や『共通事項』と言った別の枠に分けておく事で、実際のテスト項目内の文章量を減らす事が出来ます。
IDや入力条件等を抜いて、必要な情報を取り出すとこれだけ少なくなります。これだけだと少々情報が少なすぎると感じる場合や、別の何か追加したい思った時は３の内容に繋がります。
3. 定期的な更新を
一定の記載パターンを用意し、それを利用したテンプレートを作成したら一旦は完了となります。しかし、テスト仕様書は一度作って終わりではなく、継続的に改善されるべきものです。現時点では「これで十分」と思えたとしても、繰り返し利用している間に変化の必要を感じる場面がやってきます。これは自分以外が作成したテスト仕様書を使ったテストを行った際に感じる事であり、その時に感じた印象は取りこぼさずに覚えておかなければいけません。
テストと言うある程度確定した内容を行う作業に対し、あまりに感覚的な話になるかもしれません。しかし、多種多様なテスト仕様書に触れた際の「今の自分が作っているテスト仕様書、変えた方が良いかも」といった意識はそのまま放っておいてはいけないのです。
またテスト項目の記載内容についても、開発者のテスト実施者の両方で意思疎通に齟齬がおきない書き方も模索していきましょう。これは「既にテスト仕様書内に書いてある内容」にも拘らず、「書いてない」と判断されてしまう事を防ぐためでもあります。
少し具体的な例を出してみると以下の様な内容を繰り返します。
４. まとめ
最後に重要なのは、テスト仕様書を「コミュニケーションの手段」として捉えることです。テスト仕様書作成時のレビューを通じて認識のズレを解消したり、仕様の曖昧さを早期に発見したりすることで、開発全体の品質向上につながります。仕様書は単なる個人実施の成果物ではなく、チームの知識を共有したり連携をする際の重要なツールとなりえます。
「以前はこれでよかったが、今は駄目かもしれない」といった様に、テスト仕様書の改善は短期的には実現できませんが、小さな見直しを積み重ねることで確実に効果が現れます。日々の開発の中で意識的に向き合い、より価値のあるものへと改善していきましょう。
