テスト実施はその気があれば際限なく行うことができますが、計画通りに全てのテストを実施して完了したときに、読者の皆さんはどんな感覚を得ますか。やるべきことをやった「すっきり感⁠」⁠、それともまだまだ足りない「もやもや感⁠」⁠、はたまた「別になにも感じない」とそれぞれでしょうか。

筆者は、テスト工程が終わってしまってからの対策は「後の祭り⁠」⁠、そう手遅れと考えています。したがって、テストが終了するまでは、じたばたと足掻きながらテストを実施します。しかし、プロジェクトによっては「すっきり感」で終わることも、「⁠もやもや感」で終わることもあります。どちらで終わったとして完全なテストはありえませんが、できればすっきり終わりたいですね。

テストの性質を知る

テストはどの工程から開始しますか？製品（やシステム）の仕様が決まってからとか、開発工程のプログラムの実装が終盤になってからなど、いろいろあると思います。実は、テストは実施する工程によって性質が異なります。そのテストの性質を理解して、いざテストに臨むと効果が得やすくなります。

開発工程終盤のテストは「歯止め」

実際に行われている多くのテストは、不具合の流出を防ぐ「歯止め」が目的になります。そこでのテストは、網羅性やリスクとかをベースにテストが組み立てられて行きます。効率の良いテストの組み合わせで網羅性を向上させたり、リスクを考慮して⁠”やるべきテスト⁠”を絞ったり、可能な限りテストの効率性を追求します。その一方で、開発で品質が作り込まれていない製品などが送り込まれた場合、このテスト期間は修羅場と化します。

開発工程前半のテストは「抑止」

どうしても開発工程の終盤のテストに目が向けられがちですが、一般的には「テストを早く始めたほうが効率が良い」と言われます。開発初期のテストって、あまりイメージがわかないかも知れません。しかし、レビューやインスペクションのような静的テストは、開発ドキュメントが存在すれば実施できるので、当然開発工程のかなり早い段階で実施することができます。この開発工程前半のテストを「抑止」と考えています。

筆者の場合、この「抑止」効果を考えることで、テストへの取り組み方が変化してきました。従来から仕様書のレビューや開発者とのブレインストーミングによって、仕様や要求の曖昧な点を指摘、質問し、テストの実施に反映させています。これらは、テスト設計を行ったりテスト実行計画の考慮に利用したり、テストチーム側に必要な作業として実施しました。そのために、これらの行為が機械的に行われていた部分もあります。決して仕様書のレビューやブレインストーミングを否定しているわけではありませんが、「⁠抑止」効果を最大限に発揮させることができれば、後工程で効率的なテストが期待でき、テストにおけるミスを減少させることができます。

筆者が抑止効果を感じる最大のポイントは「気付き」を与えることです。

人間力「気付き」を与える

現実には、「⁠気付き」はいつ起こるかわかりません。しかしながら、開発工程前半の「抑止」を実施するときに誘導することが望ましく、それらの要素をテストによって引き出します。では、どのように実施すれば良いか、テスト設計を一例に考えてみます。

テスト設計では、下記のような流れで行います。

• ①テストを実施する範囲を決定します（ビックバンテスト以外では、一般的にテストレベルごとにテストが実施されるので、対象となるテストレベルとテストの対象範囲を決めます⁠）⁠。
  テストレベルでは、“⁠単体テスト⁠”から“⁠結合テスト⁠”⁠、“⁠統合テスト⁠”⁠、そしてそれ以降のテストにレベルが変化します。
• ②テストの観点をあらかじめ確認し、テスト方式を想定しておきます。
  テスト観点とは、テスト対象の持つ特性（エンタープライズ向けアプリケーションなら、そのビジネスモデルなど）を確認するための要素になります。
• ③テスト対象で確認すべき“⁠振る舞い⁠”（通常は、テスト対象の機能や動作）を抽出します。
• ④③の“⁠振る舞い⁠”が動作する環境や条件を抽出します。
• a）すべてのテスト条件を一覧表にまとめます。一般的な変数だけでなく、プラットフォームの種類やデータ種別、コマンド種別などの多くの条件があります。
• b）正常動作する環境や条件を抽出します。正常動作の範囲には、ノーマルケースとエクセプショナルケースに分類します。
• c）動作しない環境や条件を抽出します。正常動作の範囲外や仕様に記述されていない組み合わせ可能性のある条件などです。正常動作の範囲境界では、「⁠限界値分析」なども考慮します。
• d）動作保証外の条件を抽出します。c）との違いは、動作しない仕様（エラー表示する、動作が停止する等）に対して、テスト対象がどのような振る舞いを起こすかが想定外（いきなり電源を切るなど）な条件です。この条件の抽出に関しては賛否が分かれると思いますが、筆者は動作保証外の障害でも利用者の利便性に関係のある条件はテストを実施しています（たとえば、利用中電源が落ちてもハード的な故障が起こらないか、など⁠）⁠。仕様外機能もここで検討します。
• ⑤テストの観点を加えて、構成すべきテスト方式を決定します。
• ⑥抽出した“⁠振る舞い⁠”や条件を組み合わせて、テストケースにします。

実際には、実施するテストの種類によって上記の流れは変化します。テスト設計の流れを見てみると、②以降は開発の流れに近いと思いませんか。実は、テスト設計で作成するテスト仕様は、開発仕様とほぼ同等になります。その上、テストでは動作しない環境や条件、抽出した“⁠振る舞い⁠”と条件の組み合わせなど、開発にない多くのパターンを考慮しています。このテスト仕様と開発仕様の差異部分に、「⁠気付き」の要素が多く含まれています。

「この仕様だったら、こんな不具合が」

テスト仕様と開発仕様の差異がポイントであるとお話しました。でも、これだけでは「気付き」を得ることは難しいかもしれません。そこで、テストエンジニアならではの視点の一例をお教えしましょう。それは開発仕様に「結果系」の記述が少ない場合が黄信号だということです。テスト設計の基本は、入力と対応する出力、つまり期待値を設計することです。経験的にその期待値が不明な仕様書には、途中のプロセスに不備があるケースが多いといえます。処理（プロセス）中心的な開発仕様の場合で結果系の記述が曖昧な場合は、期待値を求める（ヒアリングや質問、ブレストで聞いちゃいましょう）ことで「気付き」を与えることができます。

なんちゃって「人間力」にならないために

この連載では、テストと「人間力」についてのお話をしました。最近では、開発プロセスにテストを組み込んで実施されるケースも多くなってきました。そして開発後期のテストは、自動化などで機械的に実施され、効率を求められるようになりました。しかし、プロセスに頼り機械的、形式的になると「人間力」が低下してしまいます。実際には、テストはまだまだ「人間力」を必要としています。また、どこかの機会にお話するために、ますます「人間力」を高めようと思います。