テスト仕様書

テスト仕様書の作り方大公開：テスト設計の手順とセオリー

みなさん、こんにちは。
以前の記事「テスト仕様書サンプルあり。高品質なテストを実現する方法」では、ソフトウェアテストを行う上で必要な基礎知識をコンパクトにまとめた『テスト入門ハンドブック』をご紹介するとともに、テスト仕様書のテンプレートを提供しました。

以前の記事はこちら

テスト仕様書サンプルあり。高品質なテストを実現する方法

先の記事でも述べましたように、フォーマットは道具であって目的ではありませんから、ただ記入欄を埋めただけでは意味をなさないことは言うまでもありません。大事なのは「何をどのように検証するのか」を正しく誰にでもわかるように記述することです。「テスト仕様書を作れと言われたけれど何をどう書いたらいいのかわからない」「テストケースに抜け漏れがあり、テストをしてもバグが残ってしまう」といった悩みをお持ちの方に向けて、今回から『テスト仕様書の作り方大公開』と題して７回にわたって連載いたします。

まず初回は、フォーマット記入に先立って「テスト設計とは何か？」「何のためにやるのか？」「何をどのようにすればよいのか？」について考えていきたいと思います。早くテスト仕様書の書き方を知りたいとお思いのことでしょうが、何事も基本の考え方が重要ですので、どうか今しばらくお付き合いください。

テスト設計とは何か？

さて、テストを「設計する」とはどういうことでしょうか。「モノ」を作り出すために設計が必要なのは疑問の余地もありませんが、テストという「行為」に対して設計をするということは簡単には理解し難いかもしれません。まずはここから考える必要があります。

できたプログラムを動かしてみて結果を確認することだけがテストではありません。それはほんの一部分であって、事前準備や報告までを含んだ一連の『プロセス』になっています。テスト設計とはその事前準備の一環に他なりません。また、テストとはただやみくもに動かしてみることではなく、要求事項や設計諸元を満たすかどうかを「客観的に検証」することです。そのために「何をどのように確認すべきか」「結果はどうあるべきか」をあらかじめ定めておく必要があります。まさにそれこそがテストを「設計する」ということなのです。

テスト設計は何のため？

では、テスト設計は何のために行うのでしょうか。テストを実行する人がわかってさえいればそれでいいように思えますが、決してそうではありません。

・誰がやっても迷わずに同じことができるように
・誰がやっても同じ結果が得られるように
・結果がOKなのかバグがあるのか誰でも同じ基準で判断できるように
・何に対してどんなテストをして、それがどんな結果だったのか（どこにバグがあったのか）後からわかるように

つまり『第三者が再現できるように』『第三者が客観的に判断できるように』ということなのです。

テスト設計は何をすればよい？

そうなると、テスト設計とはいったいどんなことをすればよいのでしょうか。『テスト仕様書』なるものを作るには何をもとにしてどのような手順を踏めばよいのかが皆様の最大の関心事ではないかと思います。私たちはこのように考えます。

・ソフトウェアはユーザーニーズを実現するための『機能』の集合体であり、機能の内容は設計書に記述されている ・ブラックボックス的な見方をするならば、全てのソフトウェア機能は【入力条件】→【処理】→【出力結果】というモデルで説明できる ・【処理】の正しさは【入力条件】に対する【出力結果】が正しいことで確認できる ・【出力結果】はそれぞれ性質・特徴を持ち、評価するための視点がある

つまりテスト設計をするということは『機能』（何ができるか、どう振舞うか）と『観点』（切り口、着眼点、発想）の『組み合わせ』をすることであるということができます。言葉だけではわかりにくいと思いますので、個人登録画面を例として『機能』と『観点』の関係を図-1に表しました。