テストが単純作業だと思っているマネジャーは、今でも少なくありません。新人でも使えない奴でもいいから、とにかく人員を投入して残業をさせろ、という指示を出すタイプですね。こうしたマネジャーの興味を強く惹くのは、大きくわけて2つの誘惑です。一つは、とにかく安い外注を使うこと。パートでも、オフショアでも構いません。外注を叩いて叩いて、同じ予算でなるべく多くの人員を投入しようとします。もちろん技術力の評価など二の次で、せいぜい過去に同種のプロジェクトをこなしたかどうか程度しか確認しません。

もう一つは、テストの自動化です。テストツールを買いさえすれば、ノウハウいらずで大量のテストができるようになるのではないか、という発想ですね。皆さんの周りには、こうしたマネジャーはいらっしゃいませんか？

しかし、テストを自動化するだけでテストが楽になる、というのは幻想に過ぎません。最近はテストツールのベンダやリセラの営業さんだって、そんなヒドイ嘘はつきません（うちのツールを買えば万事オッケー、などという営業さんは追い返しましょう）。テストの自動化は、使いこなせば大きな効果を挙げられますが、何もしないと宝の持ち腐れになってしまいます。

テスト自動化の権威であるLinda Hayesは、StickyMindsのコラム"Fear of Automation"でこう語っています：スティーブン・キングがMicrosoft Wordに仕事を奪われると恐れているとは思えないわ。そう、テストの自動化を成功させるには、ツールではなく、どんなテストをしているのか、が重要なのです。

テストの自動化を成功させるには、いくつかのポイントがあります。まず、何を自動化すべきかをきちんと把握すること。次に、人手でどの程度きちんとテストできているかを判断すること。最後に、自動化できない部分や自動化による手間を評価することです。この３つを怠ると、せっかくテストツールを買っても活用できず、棚の上に眠らせることになってしまいます。残念ながら現在の技術では、買っただけで済むテストツールは存在しません。

テストにおいて自動化できるのは、大きく分けて6つあります。最も有名なのは、テストの実施ですね。人間が行うテスト作業の肩代わりと考えてもよいでしょう。e-TesterやWinRunnerなどマウスやキーボードの操作を記録し再生するツールや、xUnitなど開発環境上で関数やクラスに引数を与えて実行するツールを用いて自動化することになります。特に区別せずにテストの自動化という時は、テスト実施の自動化を指すことが多いようです。

自動化という言葉のイメージとは異なりますが、負荷テストツールもテストの実施の自動化にあたります。ただしテストの実施そのものを自動化するというよりも、実施の支援を行うという表現の方が的確でしょう。1000人同時アクセスが必要となる場合、人手を1000人分集めるのは大変ですから、負荷テストツールのようなテスト実施支援ツールを用いることとなります。

テストを実施したら、テスト結果を観測することが必要でしょう。誤字脱字やフリーズのようにテスト結果が簡単に分かる場合はともかく、バッファオーバーフローやメモリリークといったマシン内部の状態はツールを使わないと分からないことがほとんどです。またホワイトボックステストのカバレッジも人手ではなかなか測定できません。そこでPurifyやBoundsCheckerなどメモリの状態を観測するツールや、CodeTESTなどパスカバレッジを測定するツールを用いることになります。テスト技術者だけでなく、開発者が使うことも多いですね。

そもそもテスト項目を自動で設計してくれるツールはあるのでしょうか。少ないながら、特定のテスト技法（アルゴリズム）にしたがってテスト設計を行ってくれるツールが存在します。Jtestなどパステストを設計してくれるツールが良く知られていますね。また直交配列表や全ペア法にしたがって組み合わせテストを設計してくれるツールもあるようです。もちろん万能のツールではありませんが、出来ることと出来ないことをきちんと理解して使えば便利でしょう。

テストマネジャーやプロジェクトマネジャーには、テスト管理支援ツールやバグ管理支援ツールが有用でしょう。TestDirectorなどテスト項目の進捗を一元管理するツールや、ClearQuestやBugzillaなどバグ修正の状況を管理するツールを用いることになります。内製のツールを使っている場合もありますね。開発全体で使っているツールと不整合が生じないようにしないと、かえって手間がかかってしまったりします。

忘れてはならないのが、テスト環境の構築を自動化してくれるツールです。ハードディスクやデータベースを初期状態に戻すツールや、環境の自動配布を行ってくれるツールなど多岐に渡ります。何か特定のベンダのツールを用いるというよりは、知恵を絞ってフリーウェアのツールを活用する場合も多いようです。

このように何を自動化すべきかを把握したら、人手でどの程度きちんとテストできているかを判断し、自動化できない部分や自動化による手間を評価することが必要になります。特に重要なのは前者です。行き当たりばったりのテストをしている現場では、自動化の効果は極めて薄いでしょう。抜けが多くてバグがちっとも見つからないテスト項目を自動化しても、OKの結果が積み上がるばかりで、カバレッジも広がらなければ不具合検出率も向上しません。自分たちのテスト組織の実力を把握し、自動化をすることで何をしたいのかをよく考えないと、自動化という果実の旨みは味わえません。

こう聞くと、うちの組織はテストのレベルがイマイチなのでツールを買っても損をするだけなのか、と思われるかもしれません。皆さんの組織がずっとイマイチであるならば、答えはYesです。しかしツールを買っても買わなくても、こうした組織はズルズルと効果の低いテストを続け、残業ばかりなのにバグを見逃し、いつか破綻してしまいます。

ツールを買うメリットは、組織が現在行っている作業をツールに肩代わりしてもらうことではありません。ツールを買い使いこなそうとすることによって、組織のテストのレベルが向上することなのです。例えば、テスト設計もせず行き当たりばったりでテストをしている組織が、GUI自動操作ツールを買ってテスト実施を自動化したとしましょう。始めは、人手で行っていたテスト操作を記録して再生するだけしかできません。しかし似たようなテストを自動化していることに気付くと、まずは自分たちが行っているテストを紙に書いて整理するようになります。次に似ているテスト項目と似ていないテスト項目を分類するようになるでしょう。似ているテスト項目を眺めていると、なぜ似たようなテスト項目を何度も実施しなくてはならないのか、という点に疑問を持つはずです。ここまで来れば、重複したテストケースの優先順位を下げ、異なる狙いを持つテストケースの優先順位を上げるようになります。気が付くと、網羅的にテストを行うためにカバレッジを測定するようになっているでしょう。

テストツールは、銀の弾丸や魔法の杖ではありません。自分たちの実力をそのまま映し出す鏡なのです。鏡に映った自分たちを受け入れずにツールを投げ出すか、受け入れてテストの改善に結びつけるか、決めるのも自分たちです。ツールの導入をきっかけとして、テストの改善にぜひ乗り出しましょう。

テストをしていて一番悩むのが、どこまでテストすればよいのだろうか、という点です。勘と経験と度胸で終了判定を行っている組織もあれば、独自の方法を編み出している組織もあるようです。また信頼度成長曲線（Software Reliability Growth Model: SRGM）を始め、昔から研究テーマとしてもよく取り上げられます。しかし、これを考えれば万事オッケーというような、万能の判定基準はありません。信頼性を判定する指標も同様です。テスト対象やテストそのものの様々な側面を総合的に把握する必要があります。

その一つの側面が「カバレッジ（coverage）」です。どれくらい網羅したテストなのか、という指標を意味しています。最も有名なのはコードカバレッジでしょう。C0、C1などという用語を聞いたことはありませんか。もしくは命令網羅や分岐網羅、ノード網羅やリンク網羅という呼び方かもしれません。基本情報技術者試験の範囲にも入っているようですね。

コードカバレッジというのは、プログラム内部のロジック（制御パスと呼びます）をどのくらい網羅したテストなのか、という指標です。例えば、命令網羅というのはコードカバレッジの一種になります。デバッガでステップ実行をして全ての行（命令）を実行するのは、命令網羅と同等になります。

カバレッジは、コードカバレッジだけではありません。ランダムテストやアドホックテストを除くと、全てのテストでカバレッジを考えることができます。仕様書の要件をどれだけテストしたか、という指標は、仕様カバレッジや要件カバレッジと呼ばれます。ユースケースを網羅する場合はユースケース網羅ですし、機能を網羅する場合は機能カバレッジです。機能の組み合わせを網羅するテストをしたいのであれば、機能組み合わせカバレッジを考える必要があるでしょう。カバレッジは、テスト設計の種類に対応して存在すると考えることができます。

カバレッジのもう一つ別の側面は、「設計カバレッジ」と「実施カバレッジ」です。例として、機能カバレッジが90%でテストを終了したためにテスト漏れが起こってしまった、すなわち市場不具合が発生したという状況を考えてみましょう。再発防止のために、原因を分析して対策を打つ必要があります。もしかしたらプロセスの成熟度が低いために仕様書が無く、テスト項目が存在しないことが原因かもしれません。この場合は、要求分析プロセスの質を向上して仕様書を作成し、テスト設計時に機能が網羅できているかどうかを簡単に確認できるチェックシートを作る、などの対策を挙げることができます。しかし見積もりが甘かったり開発が遅れたりしてテスト工数が足りないために、テスト項目を実行できないことが原因であれば、対策は異なります。このようにテストの質を上げるためには、設計カバレッジと実施カバレッジを分けて検討することが重要なのです。

さてカバレッジを出荷判定や信頼性評価の指標の一つに使う際には、2つの概念を整理して検討する必要があります。それが「カバレッジ基準」と「カバレッジ率」です。

例えば、ちょっと体調が悪いなと思って病院で検査を受けることを考えてみましょう。忙しいために１時間で終わる簡単な検査で済ます場合もあれば、2日かけて泊まり込みで人間ドックに入る場合もありますね。1時間コースの方が安く済むでしょうが、病気を見落とすかもしれません。2日コースの方がたくさん検査をする分だけ安心ですが、その分手間や費用がかかります。どちらを選ぶかは、必要とする安心度と費用のトレードオフです。

一方、2日コースできちんと2日受診する場合もあれば、忙しくて1時間で帰ってきてしまう場合もあります。同じ1時間の検査であっても、１時間コースを全て受診した場合と、2日コースなのに1時間しか受診しない場合とでは、ずいぶん異なるかもしれませんね。1時間コースを全て受診した場合は、精度は低いものの、身体全体を検査してくれるでしょう。しかし2日コースで1時間しか受診しない場合は、精度は高いかもしれませんが、身体の一部しか検査されていないかもしれません。

もうお分かりでしょう。カバレッジ基準とは、どれくらいテストをすべきか、という概念です。検査であれば、1時間なのか2日なのかという受けるべき検査の量（日数）にあたります。カバレッジ率とは、テストすべきカバレッジ基準をどれくらい達成したか、という概念です。検査であれば、1時間や2日といったそれぞれのコースを全て受診したのか、半分で帰ってしまったのか、にあたります。

命令網羅（C0網羅）や分岐網羅（C1網羅）というのは、カバレッジ基準です。基準が厳しいほど、見つけられる不具合の種類が多くなりますが、必要なテスト項目は同じか増加します。C1基準の場合、C0基準で見つからない飛び先誤りという不具合を見つけることができるようになりますが、飛び越しやループの数だけテスト項目数が増えていきます。一方、命令網羅で10本のテストパスが必要となった場合、5本しか実施しなければ、カバレッジ率は5本÷10本＝50%となります。

テスト項目の数を減らしたい場合は、2つの選択肢があります。一つはカバレッジ基準を緩めることであり、もう一つはカバレッジ率を下げることです。大差ないように感じますが、カバレッジ率を下げることはリスクを伴います。病院の検査の例から分かるように、カバレッジ率が低い場合は全体をテストできず、丸ごと抜けてしまう部分が発生してしまうのですね。しかも多くの場合はカバレッジ率の数値が一人歩きするため、どこが抜けてしまったのかを検討しないまま、市場に不具合が流出してしまうことになります。しかしカバレッジ基準を緩めるのであれば、その際にどんな不具合を見逃すのかをきちんと検討しておけば、レビューの結果などを併用することでリスクを抑えることができます。私見ですが、カバレッジ率は常に100%を達成すべきでしょう。C0基準で70%程度という基準の組織もあるようですが、実行できないパスが異常系で実行確率が低く、テストで実行するにはコストがかかりすぎ、かつレビューなどで不具合が無いことを十分検討しておいた場合にのみ有効だと思います。

カバレッジの検討は、出荷判定や信頼性評価だけでなく、自分たちのテストの質の把握にも使うことができます。皆さんの組織では、どのようなカバレッジ基準を採用していますか？カバレッジ基準を定められるようなテスト設計を行っていますか？カバレッジ基準の策定には、どのような検討を行いましたか？自分たちが採用しているカバレッジ基準では、どのような不具合を見逃すリスクがありますか？開発側のテスト（単体テストや結合テスト）でのカバレッジ率はどの程度ですか？出荷時のカバレッジ率はどの程度ですか？なぜ100%にならないのですか？100%に満たないテスト項目はレビューで押さえていますか？見逃した不具合は、カバレッジ基準を定めたテスト項目で見つけられるものでしたか？不具合を見逃したのは、設計カバレッジが低いからですか、実施カバレッジが低いからですか？・・・まずは自分たちがどんなテストをしているのかをカバレッジで把握して、テスト改善のきっかけにしてみましょう。

入力用のテストデータを設計するというのは、非常に重要なテスト設計ですね。皆さんは、どのようにテストデータを設計していますか。最も重要なテスト技法は、境界値テストです。しかし今回は、異なる観点でのテストとして「サニタイジングテスト」を紹介します。

サニタイジング（sanitizing）というのは、殺菌する、とか、衛生的にする、という意味です。主にWebアプリ開発の分野で使われるのですが、入力データが意図したものと別の意味で解釈されることを防ぐ技術のことです。もともとセキュリティ分野で使われている言葉ですね。ソフトウェア工学分野で、予防的／防衛的プログラミング（preventive / defensive programming）と呼ばれている概念と同じようなものです。

例えば
<script>alert('Not sanitized');</script>
という文字列を表示させるWebページを考えてみましょう。正直にこの文字列を書くと、実は文字列は表示されません。やってみて下さい。ダイアログボックスが開くと思います。理由は明らかですね。スクリプトのタグだと解釈されてしまい、文字列だとは解釈されないからです。この文字列を表示させようと思ったら、
&lt;script&gt;alert('Not sanitized');&lt;/script&gt;
と書かないといけません。"<"の代わりに、"&lt;"と書き換える必要があるわけです。この書き換えをサニタイジングと呼びます。

何が問題になるのでしょう。例えば入力された名前をそのまま表示するようなWebアプリ（占いなど）を考えてみて下さい。もし名前の代わりに<script>～</script>を入力したらどうなるでしょう。スクリプトが実行されてしまいますから、やり放題ですね。これは非常に重大なセキュリティホールになってしまいます。ですからリリース前に、サニタイジングがきちんと行われているかどうかをテストする必要があるのです。これが、サニタイジングテストです。

サニタイジングテストは、Webアプリだけに必要なテストではありません。例えば文字化けが起こらないかどうかテストする、というのは昔から行ってますね。海外製のアプリに2バイト文字を入力してみる、というのもサニタイジングテストの一種と考えてよいでしょう。基本的にはWebアプリに限らず、文字コード体系が複数ある言語の場合、ローカライズの場合、入力データに文字列だけでなく制御コードやスクリプト／プログラムが混在する場合、にはサニタイジングテストが必要です。

またWebアプリの場合、実害のないと思われるタグはサニタイジングしないことがあります。しかしIPAのサイトで紹介されているように、コメントタグやスタイルシートでの<BR>タグでも不具合は発生します。こうしたTIPSをいくつ知っているか、がサニタイジングテストの決め手になります。

Webアプリでは、入力データ以外も実はテスト設計の対象になります。入力データがそのままURLになって送られる（GETされる）場合は、URLの文字列を書き換えてWebサーバに送ってやるというテストも必要です。クライアントからは送られないかもしれませんが、セキュリティホールとしてクラッカーに狙われるわけですから。特にSQL文が送られるような場合（SQLインジェクション）や、ディレクトリ名やファイル名が送られるような場合（ディレクトリ・トラバーサル）は、致命的なダメージを食らう可能性があるので重点的にテストする必要があります。

意外に忘れやすいのが、リストボックスやHiddenフィールド、環境変数（HTTP_REFERERなど）、Cookieなどです。リストボックスは送られるデータが決まっていますし、Hiddenフィールドのデータはユーザから認識されないので、開発者はチェックしない可能性があります。環境変数やCookieなど暗黙で送られるものもチェックされないことがありますね。油断せず、サーバに送られる全てのデータについてテスト設計しないといけません。

サニタイジングテストの設計方針は簡単です。文字化けのように意図通り表示されなかったり、スクリプトやプログラムとして実行されるような文字列を、テストデータとして設計すればよいのです。しかしそれだけではテスト設計できませんから、サニタイジングテストで用いる代表的なテストデータを挙げておきましょう。

• 改行文字（システムによって異なることに注意）
  
• 円マーク（\）
  
• セミコロン（;）
  
• Webアプリのタグ（<,>,&）や引用符（",'）
  
• CSVを扱うアプリのカンマ（,）
  
• シェルやDB、OSのコマンド
  
• ディレクトリ名、ファイル名
  
• IDとパスワード
  
• conやprn、aux
  

もちろん、これで全部ではありません。テスト対象やミドルウェア、DB、OSの仕様をよく読んで判断して下さいね。

テストケースの粒度の話を覚えていますか。「○○というユーザ名、××というパスワードでログインする」というテストケースに対して、「ログインする」というテストケースは粒度が粗い、という話でしたね。

仮に自分の組織のテストケースが前者の粒度だったとしましょう。もしユーザ権限が4つあった場合は、それぞれの権限に合わせたアカウントで、最低でも4種類のテストケースを作成することになります。では逆に、権限の異なる4つのテストケースをレビューすることになったら、皆さんはどうしますか？

まず4つのテストケースの違いを考えますね。ふむふむ、ユーザ名が違うなぁ、なぜ違うんだろう、と考えながら仕様を思い出したり、仕様書をめくったりします。なるほど、ユーザ権限が異なるわけか、では必要な権限は網羅されているかな、なんて考えながらレビューしていくと思います。面倒ですね。

では、4つのテストケースに対して「すべての権限のアカウントでログインするためのテストケースです。この4つはセットです。」という注意書きがついていたらどうでしょう。テストケースのレビューがとても楽になります。テストケースを考えた担当者の思考プロセスを追うことができますから。

言い換えると、テスト担当者は「すべての権限のアカウントでログインする」という粒度の粗いテストケースをまず考えて、それから4つの粒度の細かいテストケースを導き出したわけです。テストケースを漏れなく考えるためには、粒度の粗いテストケース（すべての…ログインする）をまず考えて、制約条件（権限は4種類）を挙げ、粒度の細かいテストケース（○○というユーザ名…ログインする）に詳細化すると便利です。これを私はテストの「設計」と呼んでいます。またテスト設計の中間成果物を示すと、テストのレビューが容易になってテスト漏れを防ぎやすくなります。

テストの設計を行うと、仕様変更に強いテストケースができますね。テスト設計をせずに細かいテストケースを一つ一つ挙げるだけだと、要求事項の変更に関係するテストケースが分かりにくくなってしまいます。先ほどの例で、権限が3種類に減ったらどうやってテストケースを変更すればよいでしょうか。4つのテストケースを全て見直さなくてはなりません。しかしテスト設計を行うと、それぞれの詳細化のプロセスで考慮する制約条件が明示されますから、全て見直す必要は無くなり、仕様変更によるテストのモレやムラは減りやすくなります。

仕様変更に強いということは、再利用が楽になるということです。再利用した要件と変更した要件の差をきちんと認識しておけば、再利用できるテストケースの粒度と、再設計が必要なテストケースの粒度を分けることができます。先ほどの例で、新しいシステムでログイン手段がキーボード入力でなく指紋認証になった場合でも、粒度の粗いテストケース（すべての…ログインする）はそのまま流用できます。

ちなみに私は、最も細かい粒度のものをテストケース、テストケースよりも粗いものをテストアイテムと呼んで区別しています。テストアイテムには何レベルも粒度がありますね。何をどう呼ぶかは好みですが、テスト設計だけは忘れないようにして下さい。

皆さんは、テストケース、と聞くと何を思い浮かべますか？

例えばWebアプリのログイン画面を思い浮かべて下さい。「ログインする」がテストケースだと答える場合もあれば、「○○というユーザ名、××というパスワードでログインする」と答える場合もあります。同時にログインしているユーザが何人いるか、もテストケースに書くと考えた方もいるでしょう。ユーザ名の入力とパスワードの入力の順序を考えた方もいるかもしれません。もしかしたら、GUI自動操作ツールのスクリプトを意味する場合もあるかもしれませんね。

このように、テストケースには色々と細かさのレベルがあります。このレベルのことを、テストケースの「粒度」と私は呼んでいます。粒度は粗すぎても細かすぎてもいけません。

例を挙げましょう。「ログインする」というテストケースを、テスト実施担当者（テストオペレータ）に渡したとします。テストオペレータは、テストケースにアカウント情報が書いてありませんから、適切と思われるユーザ名とパスワードでログインするでしょう。しかしこれでは、毎回ログインするアカウントが異なってしまうかもしれません。アカウントによって権限が異なるため、バグが見つかったり見つからなかったりするのです。したがって、テストケースを実施するたびにテスト結果が異なってしまいます。これは粒度が粗い例です。一般的に、粒度が粗いと誤解が生じやすくなります。

ではテストケースの粒度を細かくすればよいのでしょうか。全てのテストケースに「ユーザ名は○○で、パスワードは××で、同時にログインしているユーザはAとBとCで、ログインする前にPとQとRの操作をして．．．」なんて書いていると、書く手間ばかりかかってしまいます。一般的に、粒度が細かいと工数が増加します。工数の問題でテストケースの粒度を細かくできない場合は、テスト実施の記録を細かく取るようにするとよいでしょう。ただし記録に手間がかからないように工夫する必要はありますが。

適切なテストケースの粒度は、どの程度でしょう。それはテスト組織ごとに異なります。新人にテストを実施させる場合には、粒度を細かくすることを意識した方がよいでしょう。一方長年連れ添ったテストオペレータばかりの組織なら、粒度が多少粗くても誤解は生じないでしょう。とはいえ、随時ミーティングを実施して粒度の意識統一を行っておくことが必要です。

テストケースの粒度を意識するのは、良いテストの始まりだと私は考えています。ぜひ一度、自組織のテストケースの粒度を確認してみて下さい。

ハードウェアの信頼性の分野には、「3H」という言葉があります。不具合の起きやすいパターンのことで、「変化」「始めて」「久しぶり」の頭文字を集めたものです。設計変更した部分は不具合が多い、始めて採用した機構部分には不具合が多い、久しぶりに扱った部品とのインターフェースには不具合が多い、というような意味だそうです。

3Hはソフトウェアのテストでも当てはまります。バグの多そうなところを頭に入れてテストケースを考えると、効果の高いテストが可能になりますね。。ただハードウェアと同じだとつまらないので、ちょっと拡張してみました。

はじっこ

境界値のこと。境界値の周りはバグの温床ですね。

ひさしぶり（久しぶり）

すいぶん昔のシステムに変更を加えたり再利用すると、前提条件を忘れやすいので思わぬバグが入り込んでしまいます。

ふぁーすと（ファースト）

初めて扱う製品、初めてのアーキテクチャ、初めて使うプロトコルなど、とかく初めてのところにはバグが多いものです。とはいえ、慣れたところには慣れによるバグが入り込んだりするので大変なのですが。

へんこう（変更）

変更を加えた部分にはバグが多いです。仕様変更、設計変更、プログラムの変更の際にバグを作り込んだり、構成管理でミスをしたり。プロジェクトが混乱していたり、納期直前でプレッシャーをかけられている時は、さらにバグが入る確率が上がります。

ほんねとたてまえ（本音と建前）

仕様が曖昧な部分やコミュニケーションがうまくいってない部分のことです。これを「本音と建前」と呼ぶのは、ちょっと無理があるかもしれませんね。