前回の記事に続いて、2011年にSQiPのサイトで連載してた記事の第二話の再掲です。

思い出話になりますが、この質問は、本当にたくさん聞かれました。この頃は、テストツールのプリセールス（技術営業ともいう、販売支援をする仕事）をしてて、営業の人と一緒にいろいろな会社に訪問をして、役員レベルの方々にテストについて説明したりする仕事をしてたのですが、経営層の視点でこういう質問になったんだろうと思います。

なので、テストの現場にいる方がこれを読む際には、こういう説明を経営層にすると、わかりやすく説明できるのではないか、ということを考えながら読んでもらうといいかもしれないです。（経営層にはこれで理解してもらえることが多かったのですが、現場に近い層になるとこれではほとんど「わからない」となります。第三回のテスト設計についての説明が必要になります。）

--------

1. はじめに

ソフトウェアテストはここ10年の間に多くの専門書籍が出版され、Web媒体やシンポジウムなどでも多くの情報が入手できるようになりました。筆者は、ソフトウェアテストのコンサルティングという仕事を通じて、記事を書いたり講演をしたりすることがあるのですが、いろいろな方とお話をする機会を得るたびに、ソフトウェアテストに関して似たような質問を受ける事が多くあります。それらの質問は、書籍などに書いてある専門的な質問というより、もっと原点に戻るような質問であることが多くあります。

今コラムではそのような「ソフトウェアテストにまつわるよくある疑問」とそれに対する私の回答を四回に分けて紹介していきたいと思います。第二回は「テストを委託した時のチェックはどのようにすればよいのか」という質問です。

2. テストを委託した時のチェックはどのようにすればよいのか？

 質問を受ける状況
「テストを委託した時のチェックはどのようにすればよいのか？」という質問は、エンドユーザーとなる事業会社の方とお会いする機会が増えてからよく受けるようになりました。昨今のオフショア以降の流れもありますが、システム開発を外部に委託しているため、その品質を可視化するためにテストだけ別にするケースなども増えているのが原因のようです。

この回答も、初回と一緒で非常にシンプルです。もしかしたら初回以上に当たり前のように聞こえるかもしれません。

 テストを委託する時の狙いは何か
この質問を受けた時に、どのようなことが困っているのかといったことをまずは確認するようにしています。そのなかでテストを委託する際に、「委託先に何を求めてテストをしてもらっているのか」がはっきりしていないことが多いと感じました。そのため、レビューするドキュメントに対する委託元の依頼も明確ではありません。そうなると、納品されるドキュメントはテストケースが何万件も列挙してあるリストであったり、現場でテストしやすいように分類されたドキュメント群であったりしてしまうため、レビューしようとしても委託元が確認したい内容をドキュメントの中から見つけることが困難になってしまいます。

 何をレビューしてチェックしたいのかを明らかにする
では、委託先の何をチェックすればよいのでしょうか？この答えは前回のコラムで書いた、何を持って「最適」だと判断するのかと同じです。それは、ソフトウェアをテストした結果こうなっていればよい、ということを指します。前回は十分性を見るためには、「テスト目的」とテスト目的を具体化した「観点」、および「テスト対象」が必要であることを話しました。それらを考慮すると以下のようなチェック項目が考えられるでしょう。

＜テストをレビューする際の典型的なチェック項目＞
･  テスト目的があるか？
･  テスト目的を具体的な観点に落としているか？
･  観点に沿って「テストする事」をピックアップしているか？
･  ピックアップした「テストする事」をいろいろなケース（場合）で
　テストしているか？

 チェックできるように段階的にテスト関連のドキュメントを作る
この典型的なチェック項目のどれがテストを委託した時のチェックに使えるかは、委託元となる組織がどこまで自分たちで決めてから委託先へ依頼しているかによります。例えばテスト対象だけ提示してテストを委託する場合は、委託先が決めたテスト目的をレビューしてそのテスト目的が共有できるものであるかを確認しなければなりません。テスト目的を委託元が提示する場合は、委託先が決めたテスト対象に対する具体的な観点がテスト目的に沿っているかを確認しなければならないでしょう。つまり、確認する際は委託先の作ったテストケースをレビューするのではなく、委託元が提示したことに対する解となることをレビューしたほうがよいということです。そのためには、「委託先へ提示する内容」と「委託先から委託元への解となる内容」が明示的にわかるドキュメントが作られるようにすると、お互いレビューが容易になります。筆者はこれを「自社（委託元）と協力会社（委託先）で、インターフェースとなるドキュメントを用意して下さい」というように話しています。

 段階的なテスト関連のドキュメントによる効果
いきなりテストケースをレビューするのは、要求も設計もわからないままソースコードをレビューすることと似ています。それよりも委託元の依頼内容の解がわかりやすく記載されているドキュメントを委託先に提示してもらうほうがポイントを絞ったレビューが可能になり、レビュー工数削減にもつながります。細かいドキュメントを見た時に思わず聞きたくなる「要はどういうことか一言でいってもらえませんか？」という質問の答えになることを提示してもらうということです。

3. 最後に

今回の質問の回答は、「テストケースをレビュー」するのではなく、「委託先への要求の解をレビュー」してください、というものです。これは、ソフトウェア開発が歩んできた道と同じと言えると思います。つまり、要求が実現できているかをソースコードのレビューで確認するのではなく、その上位に当たるドキュメント、つまり仕様書や設計書を作り、そこで要求の意図がくみ取られているかを確認するということになります。ソフトウェアテストも単にテストを実行しているだけではなく、このような段階的なドキュメントが必要である理由の一つとなります。