この原稿は、2009年6月に発売された、システム開発ジャーナルvol10の特集「特集1 困ったら読む! 困る前に読む! 今すぐ使える エンジニアのためのソフトウェアテスト術」の総論（最初のまえがきみたいなもの）の後半部分として執筆したものです。この特集は私が豆蔵に在籍していたころに、大西さんと私で企画したもので、多くのイケてる技術者の方々にお願いして各パートを執筆してもらったものです。以下が目次です。

総論 
　ソフトウェアテストの現状と知っておくべきこと
Part1
   独立したテストチームとしてのテスト計画・テスト設計仕様
   テストをスムーズに行う?管理者のための“段取り”術
   品質を向上させるためのインシデントレポートの書き方
   テストツールの活用　自動化できる/できないの判断のコツ
Part2
   開発者による開発者のためのDeveloper Testing
   OSSのツールを使って静的テストを自動化する
   開発チーム内で欠陥を“管理”する方法
Column
   開発手法の観点から理解する「テスト駆動開発」の有用性
インタビュー
  開発者も受けてみよう 初級ソフトウェア品質技術者資格試験
  開発者も参加してみよう 若手エンジニア向けワークショップ WACATE

今日、自分のハードディスクの中を調べ物していたら見つけました。私の手元には当時の全員の原稿が残っていますが、今、読みなおしても我ながらナイスな企画だったと思うんですが、どれだけの人に読んでもらえたのかなって思います。

許可がもらえるのであれば、全員の原稿を載せたいくらいですが、そうもいかないので。。自分の原稿の分も、特に開発者視点のテストとユーザ視点のテストの違いの例えを学校のテストでしたところが自分なりに頑張ったので、以下に載せておきます。

-------

【テストで押さえておくべきこと】

テストとは何か？

みなさんは、何かしらの形でソフトウェア開発に携わっていることと思います。突然「これをテストしておいて！」と言われたり、「テスト不足で品質が悪くなってしまってるよ、もっとちゃんとやってくれよ！」なんて苦言を顧客や上司からいわれたり...なんて経験を持っている方も少なくないと思います。逆に「開発者のみなさんプロなんですよね？ちゃんと作っていれば問題なんて起きないのに、何故テストにお金がかかるんですか？」なんてことを顧客にいわれ、テスト工数を削られた方もいるかもしれません。（実は全て私の経験談です。）

「テストをもっとちゃんとやれと言われたり、逆にテストにそんなお金をかけるなといわれたり、どうすりゃいいんだよ？」って思ってしまいますよね。（ある意味、自問自答です。）

そもそも、ソフトウェアテストとは、「ソフトウェアが想定どおりに動くことを調べる」行為です。何故「調べる」のかと言うと、想定どおりに出来ていない「可能性」があるからです。想定どおりに出来ていない事が何の問題にもならなければよいのですが、作ったソフトウェアを使う人の迷惑になる「可能性」もあります。万が一そのソフトウェアを使ったことで使う人が損害を被るなんてことになったりすると更に事態はややこしくなります。

この「悪い結果を引き起こす可能性」のことを、一般には「リスク」と呼びます。ソフトウェアが想定どおりに動かないために起きる悪い結果の可能性のことは、「プロダクトリスク」と呼びます。結局のところ、ソフトウェアテストは、ソフトウェアが想定どおり動くことを事前に確認しておくことで、「プロダクトリスク」が現実のものになってしまわないようにしているわけです。

プロダクトリスクには2つのレベルがある

前述したなかで気づいた方もいるかもしれませんが、「ソフトウェアが想定どおり動かない可能性」には大きく二つのレベルがあります。

一つが、「（開発者の）想定どおりに出来ていない可能性」です。もう一つが、「作ったソフトウェアが使う人の迷惑になる可能性」です。

開発者の想定どおりに出来ていない例としては、コンポーネントテストレベルなら、「計算結果が間違っている」とか、「範囲外のデータの例外処理のあと、元に戻らない」のようなことが考えられます。統合テストレベルなら「間違った関数を呼び出している（そのために出力結果が返ってこない）」とか、「登録したデータがデータベースに書き込まれていない（そのために別の処理で呼び出せない）」なんてことになるでしょう。

使う人の迷惑になる可能性であれば、「システムダウンで取引が1時間以上できなかった（そのために1億円以上の売り上げ損をした）」とか、「登録したデータが消えた（再登録で数千万円の手戻りコストがかかった）」なんてことになります。

テストは「プロダクトリスク」が現実のものにならないよう事前に確認する行為であるので、この２つのレベルに合わせてテストをしないと、本来の目的を果たしていないことになります。

開発者視点のテストとユーザ視点のテスト

２つのレベルと前述しましたが、要はテストをするときに着目する視点です。開発者が「こう作る」と思ったとおりに作れているかという視点で確認する、つまり、「開発者視点のテスト」と、使う人が「こう使いたい」と思ったとおりに使えるかという視点で確認する、「ユーザ視点のテスト」が必要になるわけです。

開発者視点のテストでは、自分達で考えた仕様と突合せ、仕様どおりに動くことを確認します。これは、たとえるなら、学生が理解度確認テストを受けた後、解答用紙を提出する前に見直しをする行為と似ています。出題数が少なかったり、見直し時間が多く取れたりした場合は全問見直しするでしょうが、逆のケースでは全問見直しができないため、自分が「間違えたのではないか？」と思う難しい問題や配点が高い問題を中心に見直しを行うでしょう。

一方ユーザ視点のテストは、仕様どおりに動くことも重要ですが、それ以上に重要なのが、その動きで本来実現したい事ができるのかどうかを確認することです。理解度確認テストのたとえを使うなら、テスト結果から本当に学生が学習内容を理解したかどうかを判断する、出題側の立場と似ています。出題側は、テスト時間の制約から学習範囲を網羅的に出題出来ません。基本的に理解してほしいことをサンプリングして出題するでしょうし、「こういうことを理解していれば大丈夫だろう」というポイントを明らかにし、応用問題のようにして出題することでしょう。

このように両視点のテストは、性質が異なります。

テストは頭を使わなければ良いものにならない

両視点のテストは性質が異なるのですが、共通して言える事があります。それは「網羅的にテストはできない」ということです。網羅的に全数テストを出来るのであれば、体力でしのげますが、そうでない場合には、テスト数を絞らなければなりません。それがテストにも設計行為が必要な理由です。

設計とは、そもそも課題を解決するために工夫する知的行為です。ソフトウェア設計であれば、実装作業分担をするために処理を分割したり、性能を出すために処理を非同期にしたり、データの一貫性を保つためにロック機構をいれたり、保守性が高くなるように構造を決めたりするなどの行為が設計になります。テスト設計では、主に本当に確認したいことを時間内に確認できるように入力値のパターンや処理条件の組み合わせ、機器構成などをサンプリングするための工夫をします。

サンプリングが「的を射た」ものにするためには、的を決めなければいけませんし、サンプリングのためのテクニックも知らなければなりません。的は、ソフトウェアの特徴や開発の特徴、プロダクトリスクを分析し、確認ポイントと優先度を明らかにすることを指します。サンプリングのためのテクニックはテストレベル/テストタイプの選択や、同値分割などのテスト設計技法が該当します。これらを頭を使って考えないと「気になるところを手のつけられるところから場当たり的に」テストすることになってしまい、テストが十分なのかどうかもわからなくなります。

開発者によるテストと独立テストチームによるテスト

テストは、上記のように開発者視点とユーザ視点があるので、本来はテストを担当するのは開発者とユーザだけで十分かもしれません。しかし、ソフトウェア開発の規模が大きくなるなどの要因で開発者とユーザだけではテストしきれなくなっていたり、ユーザにテストしてもらうことが実質困難であったり(パッケージソフトや家電製品のようにユーザが不特定多数の場合が該当します)という理由で、独立したテストチームが作られ、ユーザ視点のテストを受け持つという体制ができています。（独立したテストチームの必要な理由に関してはPartⅠ-1に詳細な考察があるので参照してください）

理想的に分けると、「開発者視点のテスト＝開発者によるテスト」「ユーザ視点のテスト＝独立したテストチームによるテスト」という体制が成り立ちます。どちらにしろテスト設計が重要であることには変わりはありません。しかし、それ以外に関しては、それぞれ固有の課題があり、そのため、テストのやり方も双方で異なる部分が多く、実務を上手く進めるための重要な要因となります。各論では、ユーザ視点のテスト術、開発者視点のテスト術と言う分類でそれぞれのテストの具体的なやり方が解説されますのでそちらを読んでいただければと思います。

ユーザ視点のテスト術

ユーザ視点のテストを進める上での計画、設計に関してはPartⅠ-1にて触れています。また、ユーザ視点のテストをする独立したテストチーム独自の問題として、テストチームの運営、開発チームとのコミュニケーションについて現場の最前線でバリバリ仕事をしている技術者に現実的な仕事内容やコツを執筆してもらいました。また、ユーザ視点で行うテスト実行の効率化はどこでも課題になることが多いため、その活用方法にも触れています。

開発者視点のテスト術

まず、開発者視点のテストの範囲の定義や、用いる技法、良いテスト設計の指標に関してPartⅡ-1で解説していただいています。また、総論では書ききれなかったテストの基礎知識についても触れていただいています。そのほかには開発者間のコミュニケーションとしての欠陥管理方法や、開発者視点ならではのテスト自動化の基本について一線で活躍する開発者に執筆していただいています。

まとめ

総論では、テストの置かれている現状を解説した上で、基本に立ち返り、テストで押さえておくべきことを、プロダクトリスク/開発者視点とユーザ視点/テスト設計などのキーワードをつかって解説しました。これらについて押さえておいた上で、読者のみなさんが必要としていることを各論から読み取ってもらえれば幸いです。