あきやまさんがnoteで公開しているソフトウェア品質のホンネの記事を読んで、私の書いたソフトウェア品質のホンネの記事も公開しとこうと思ったので、ゴールデンウイーク特別企画として、これから四回に渡って再掲していきます（笑）。

ソフトウェア品質のホンネについては、あきやまさんの記事に書かれている通りなので私がここで追加で書くことはないのですが、この４回に渡って書いたネタは、プレゼンテーションバージョンもあって、少なくとも３回以上は同じネタで講演をやったと思います。（私の持っているスライドを見たらAgile Japan2011　2011年4月15日って書いてありました。）

このプレゼンテーションスライドは、いろいろ著作権に関わるような写真が多すぎて、掲載するには加工が必要なので簡単にSlideShareにアップとかできないのですが、以下の文章の挿絵として使えるところは使おうと思います。※あと、当時の文章に対して、今回ちょっと加筆もしました。バインディングタイムのところです。

-----------

1. はじめに

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

本コラムではそのような「ソフトウェアテストにまつわるよくある疑問」とそれに対する私の見解を四回に分けて紹介していきたいと思います。まず初回は「テストはどの程度やれば十分なのか？」という質問です。

2. テストはどの程度やれば十分なのか？

 質問を受ける状況
「テストはどの程度やれば十分なのか？」という質問を非常によく受けます。質問される方の状況もさまざまです。いくつか例をあげると下記のような状況です。

･　エンドユーザー側の責任者

システム開発を発注し、受入時にどのようなテストをすればよいか？
開発側のテストが何件やってあれば受け入れて良いか？

･　プロジェクトマネージャー

テスト工数を見積もるときにどの程度見積もればよいのか？

･　システムテストの責任者

システムのソースコードの行数に対して何件テストをやればよいか？

・　テスト駆動開発を推進、実践している開発者

自分の書いたコードに対して何処までテストするのか？

この回答は、言ってしまえば非常にシンプルで、もしかしたら当たり前のように聞こえるかもしれません。ただ、その当たり前を順序立てて考える事がとても重要な事だと思います。

 そもそもテストとは
この回答の前に、テストとは何かということから話を始めたいと思います。まずはSWEBOK（ソフトウエアエンジニアリング知識体系）の定義を引用してみます。

･ソフトウェアテスティングとは、通常は無限に大きいと考えられる「プログラムの振る舞いの実行領域」から、最適だと考えられる有限な「テストケースの集合」を選定し、所期の通りかどうかを実際に動かして検証すること（SWEBOK 2004）

SWEBOKの解説にもあるように、ソフトウェアテストの重要なところは、「最適だと考えられる」ものを「選定」して検証をしているところです。本当に何もかも全部テストできるわけではないし、テストする必要もないのです。

 最適とは？
では、何を持って「最適」だと判断するのでしょうか？それは、ソフトウェアをテストした結果、こうなっていればよい、ということを指します。一般的にテストをする際に考える、「こうなっていればよいであろう」ということを列挙してみます。

＜テストした結果ソフトウェアがどうなっていればよいか＞
･　プログラムコードを実行してエラーにならなければよい
･　仕様に書いてある通りに動けばよい
･「いつでもどんな時でも」仕様に書いてある通りに動けばよい
･「いつでもどんな時でも」「所定の速度で」動けばよい
･　仕様に書いてある通りに動いたときに、変な副作用
　（ex.データ漏えい)がおきなければよい
･　仕様に書いてなくても「利用シーンを想定し」上手く動けばよい
･　ソフトウェアを使うと当初のもくろみを達成すればよい
　（ex.商品売上○%アップ）

どれが正しい「最適」であるかというと、どれも正しいと言えます。ただ、どれが正しいかは、その時の状況によるかもしれません。

 「最適」を共有しているか
通常、テストをする際には、誰もが知らず知らずに「最適」を考えているはずです。大事なことは、みんなが考えている「最適」を、あらためて整理しみんなで共有しているかどうかです。「最適」になっていることを確認することがテストをする目的です。この「テスト目的」をテスト開始前に合意していれば、それがテストをどの程度やれば十分なのか？の答えになります。共有した「テスト目的」が無いと十分かは判断できません。

この「テスト目的」を十分に達成しているかを測るためには、目的を２つの観点で具体的にします。2つの観点とは、見方（網羅的、ピンポイント的）と見る位置（外観、中身など）です。

 「テスト対象とテスト目的の組み合わせ」を積み重ねる

もうひとつ、十分かどうかを測るために大事なことが、ソフトウェアの開発方法を考慮することです。

ソフトウェアは、いきなりソースコードを書いているわけではなく、ソフトウェアを利用する人の要求を段階的に詳細化して、ソースコードにしています。その段階ごとの成果物がテスト対象になります。例えば、要求のレベルであれば要求が実現できる程度に動くソフトウェアがテスト対象であり、要求が実現できていることを確認するのがテスト目的になります。そのため、システムが完成するまでの中でいくつかのテスト対象とテスト目的の組合せをテストしなければなりません。開発に合わせてテスト対象とテスト目的の組合せがいくつ必要かを決めておき、この組合せを、テストのスケジュールの中に配置していきます。この配置に必要な考え方が「バインディングタイム」です。これは、テスト結果を開発にフィードバックするのが最も適切な時期にテストを実行することを指します。

その組合せ毎の配置こそが、テスト計画での重要なアウトプットです。これは、戦争の映画などで、軍の参謀たちが地図を広げて、どこにどの部隊を配置させてどう進めていけばこの戦いに勝てるかと言ったシミュレーションをしていることと似ています。そう、この配置を考える行為は、言ってしまえば、テストの戦略なのです。（ISTQBではテスト戦略は組織的なものでプロジェクト単位のものはテストアプローチと呼びますので、ISTQBの用語に従うと、この計画の立て方は「バインディングタイムを考慮した（分析的な）」テストアプローチに基づく、です。）

配置したテスト毎に目的を具体的にしていき、最終的にテストケースにまでしていくことをテスト設計と呼びます。これは第三回でまた述べます。

テスト対象とテスト目的の組合せ毎のテストが十分であることを、テスト実行しながら積み重ねていき、が十分であることを積み重ねていき、最終的にテストが十分かを判断します。

3. 最後に

テストが十分かという質問の回答としては、「○件テストやれば十分です」ではなく、「プロジェクトでテストを計画して、目的に合うゴールを設定して下さい。それが十分かどうかを判断する指標です。」というものです。特に昨今の開発は、開発言語、アーキテクチャ、そして開発プロセスが変わってきたり、メンバーの入れ替えも激しくなったりしますので、過去の数字をそのまま適用しても役に立たないことが多くなります。単純に「○件テストする」という基準を鵜呑みにしないでほしいということです。