もう一つは、テストの自動化です。テストツールを買いさえすれば、ノウハウいらずで大量のテストができるようになるのではないか、という発想ですね。皆さんの周りには、こうしたマネジャーはいらっしゃいませんか？
しかし、テストを自動化するだけでテストが楽になる、というのは幻想に過ぎません。最近はテストツールのベンダやリセラの営業さんだって、そんなヒドイ嘘はつきません（うちのツールを買えば万事オッケー、などという営業さんは追い返しましょう）。テストの自動化は、使いこなせば大きな効果を挙げられますが、何もしないと宝の持ち腐れになってしまいます。
テスト自動化の権威である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自動操作ツールを買ってテスト実施を自動化したとしましょう。始めは、人手で行っていたテスト操作を記録して再生するだけしかできません。しかし似たようなテストを自動化していることに気付くと、まずは自分たちが行っているテストを紙に書いて整理するようになります。次に似ているテスト項目と似ていないテスト項目を分類するようになるでしょう。似ているテスト項目を眺めていると、なぜ似たようなテスト項目を何度も実施しなくてはならないのか、という点に疑問を持つはずです。ここまで来れば、重複したテストケースの優先順位を下げ、異なる狙いを持つテストケースの優先順位を上げるようになります。気が付くと、網羅的にテストを行うためにカバレッジを測定するようになっているでしょう。
テストツールは、銀の弾丸や魔法の杖ではありません。自分たちの実力をそのまま映し出す鏡なのです。鏡に映った自分たちを受け入れずにツールを投げ出すか、受け入れてテストの改善に結びつけるか、決めるのも自分たちです。ツールの導入をきっかけとして、テストの改善にぜひ乗り出しましょう。
その一つの側面が「カバレッジ（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%に満たないテスト項目はレビューで押さえていますか？見逃した不具合は、カバレッジ基準を定めたテスト項目で見つけられるものでしたか？不具合を見逃したのは、設計カバレッジが低いからですか、実施カバレッジが低いからですか？・・・まずは自分たちがどんなテストをしているのかをカバレッジで把握して、テスト改善のきっかけにしてみましょう。
]]>テストのフェーズで最も有名なのは、単体テスト、結合テスト、システムテスト、受け入れテストの4つのフェーズです。Boehm御大が1979年に書いた"Guidelines for Verifying and Validating Software Requirements and Design Specifications"という論文が初出でしょうか。
単体テストは、モジュールを対象としたテストです。C言語では関数、Javaではメソッド（もしくはクラス）、Pascalでは手続きのレベルですね。モジュールとして詳細設計し実装したロジックのバグを検出します。主に使う手法は、制御パステストや境界値テストです。データフローパステストを使う場合もあるかもしれません。ほとんどの場合、テストを実施するのは開発者になります。最近はテストファーストでテスト設計を行いますね。
結合テストは、モジュール間のインターフェースや組み合わせを対象としたテストです。C言語などではモジュールの呼び出しや戻り、Javaなどではメッセージのやり取りになります。モジュール間のインターフェースに食い違いがあるバグや、（単一のモジュールでバグが見つからないのに）複数のモジュールを組み合わせた時にだけ見つかるバグを検出します。モジュールを順次一つずつ組み合わせていくインクリメンタルテストという手法や、いきなり全てモジュールを組み合わせるビッグバンテストという手法が代表的です。もっともビッグバンテストが推奨される場合は、ほとんどありませんが。
構造化設計を用いている場合は、モジュール構造図の最上位、すなわちC言語におけるmain関数から組み合わせていくトップダウンテストや、デバイスドライバなど最下位のモジュールから組み合わせていくボトムアップテスト、両方同時に行うサンドイッチテストなどの方針で進めていきます。オブジェクト指向設計を用いている場合は、メッセージシーケンスにしたがって組み合わせたり、スレッドごとに組み合わせていきます。単体テストと同じように、開発者がテストを実施することがほとんどです。
システムテストは、全てのモジュールを結合した一つのソフトウェア（ビルド）を対象としたテストです。負荷をかけて初めて発生するバグ、デバイスやOS、他のソフトウェアなどとの組み合わせで発生するバグ、（単一の機能にバグが見つからないのに）複数の機能を組み合わせた時にだけ見つかるバグなどを検出します。もちろん単に機能が動かないというシンプルなバグも見つけなければなりません。また性能や操作性、セキュリティ、障害発生時のふるまいなどの評価も行います。開発者がテストを実施する場合もありますが、テストチームが担当することもありますね。仕様書を字面通り確認すればよいわけではなく、暗黙の仕様によって開発者が見落としている状況や、いかにもバグが発生しそうでユーザが操作してしまいそうな状況を想定できるか、が腕の見せどころです。
受け入れテストは、システムテストを通過したソフトウェアで問題ないかどうか、をユーザがチェックするテストです。検収と呼ばれることもありますね。ユーザ側で厳しい検収基準を用意していることもあれば、何となくユーザが触ってバグが出なければOKといった場合もあります。開発側（もしくはテストチーム）で用意したテスト項目でバグが無いことを、ユーザが監査するだけかもしれません。契約形態や作業の実態によって千差万別です。本番環境や実データでテストする場合は、並行で、または事前に移行作業が必要です。受け入れテストを実運用で行う時は、運用テストという名前で呼ばれることもあります。またパッケージソフトウェアや組込みソフトウェアの場合は特定のユーザがいない場合がありますので、サンプルのユーザ（βテスター）に頼むこともあるでしょう。
こうしてテストを複数のフェーズに分けると、なぜ混乱しないのでしょうか。それは、一度に多くの視点からテストを考えずに済むからです。各モジュールのロジックのバグを考えながら、負荷をかける環境を準備しつつ、操作性を評価するそばで、ユーザに受け入れテストをしてもらうタイミングを検討しなければならない状況を想像してみて下さい。それぞれの作業はおざなりになってしまいますね。人間は、一度に雑多な視点でモノを考えることがあまり得意ではありません。そのため似たような視点ごとにフェーズ分けを行い、一度に考える視点を絞ることで、テストの質を向上させるわけです。
視点を絞ると、網羅的なテストが楽になります。一度に雑多な視点で考えようとすると、どうしても一つ一つの視点できっちり考え抜くことが難しくなります。そのため網羅的なテストをしたつもりでも、テストに漏れが生じてしまいます。
またフェーズ分けによって、バグの切り分けコストも減少します。単体テストや結合テストをせずに全てシステムテストでまかなおうとすると、バグが見つかっても原因の特定に時間がかかってしまいます。例えば負荷テストを行ってバグを見つけたとしても、単なるロジックのミスなのか、モジュールのインターフェースがおかしいのか、メモリリークを起こしたのか、など原因の候補を一つ一つ切り分けていかねばなりません。しかしきちんとフェーズ分けを行うと、ロジックのミスは単体テストで全て潰しており、モジュールのインターフェースは結合テストで全てチェックしているはずです。したがって負荷のみに起因するバグだと絞り込むことができ、時間を節約することが可能になります。
テストマネジメントの面では、マイルストーンが決めやすいというメリットがあります。フェーズ分けを行うことで、特定の視点によるテストを一つのフェーズのみで実施するようにすると、マイルストーンをそのテストが完了したかどうかという基準にできます。フェーズ分けをしないと、どこにマイルストーンを定めてよいか、を判断するのが難しいですね。どうしてもズルズル進んでしまい、進捗管理も難しくなってしまうかもしれません。
フェーズ分けで気を付けておかねばならないのは、単体テスト・結合テスト・システムテスト・受け入れテストという４つのフェーズが、必ずしも自分の組織に合っているとは限らない点を理解しておくことです。組織によっては、単体テストの前にコードインスペクションのフェーズを設けた方がよいかもしれませんし、結合テストの後に内部状態遷移など設計に着目したテストのフェーズが必要な場合もあります。システムテストの前に機能テストというフェーズを置いている組織もあるようです。自分の組織では、どんなソフトウェアを、どんな作り方で開発しているか、をしっかり考えて、自分の組織にあったテストのフェーズを確立し、継続的に改善して下さいね。
サニタイジング（sanitizing）というのは、殺菌する、とか、衛生的にする、という意味です。主にWebアプリ開発の分野で使われるのですが、入力データが意図したものと別の意味で解釈されることを防ぐ技術のことです。もともとセキュリティ分野で使われている言葉ですね。ソフトウェア工学分野で、予防的／防衛的プログラミング（preventive / defensive programming）と呼ばれている概念と同じようなものです。
例えば
<script>alert('Not sanitized');</script>
という文字列を表示させるWebページを考えてみましょう。正直にこの文字列を書くと、実は文字列は表示されません。やってみて下さい。ダイアログボックスが開くと思います。理由は明らかですね。スクリプトのタグだと解釈されてしまい、文字列だとは解釈されないからです。この文字列を表示させようと思ったら、
<script>alert('Not sanitized');</script>
と書かないといけません。"<"の代わりに、"<"と書き換える必要があるわけです。この書き換えをサニタイジングと呼びます。
何が問題になるのでしょう。例えば入力された名前をそのまま表示するようなWebアプリ（占いなど）を考えてみて下さい。もし名前の代わりに<script>～</script>を入力したらどうなるでしょう。スクリプトが実行されてしまいますから、やり放題ですね。これは非常に重大なセキュリティホールになってしまいます。ですからリリース前に、サニタイジングがきちんと行われているかどうかをテストする必要があるのです。これが、サニタイジングテストです。
サニタイジングテストは、Webアプリだけに必要なテストではありません。例えば文字化けが起こらないかどうかテストする、というのは昔から行ってますね。海外製のアプリに2バイト文字を入力してみる、というのもサニタイジングテストの一種と考えてよいでしょう。基本的にはWebアプリに限らず、文字コード体系が複数ある言語の場合、ローカライズの場合、入力データに文字列だけでなく制御コードやスクリプト／プログラムが混在する場合、にはサニタイジングテストが必要です。
またWebアプリの場合、実害のないと思われるタグはサニタイジングしないことがあります。しかしIPAのサイトで紹介されているように、コメントタグやスタイルシートでの<BR>タグでも不具合は発生します。こうしたTIPSをいくつ知っているか、がサニタイジングテストの決め手になります。
Webアプリでは、入力データ以外も実はテスト設計の対象になります。入力データがそのままURLになって送られる（GETされる）場合は、URLの文字列を書き換えてWebサーバに送ってやるというテストも必要です。クライアントからは送られないかもしれませんが、セキュリティホールとしてクラッカーに狙われるわけですから。特にSQL文が送られるような場合（SQLインジェクション）や、ディレクトリ名やファイル名が送られるような場合（ディレクトリ・トラバーサル）は、致命的なダメージを食らう可能性があるので重点的にテストする必要があります。
意外に忘れやすいのが、リストボックスやHiddenフィールド、環境変数（HTTP_REFERERなど）、Cookieなどです。リストボックスは送られるデータが決まっていますし、Hiddenフィールドのデータはユーザから認識されないので、開発者はチェックしない可能性があります。環境変数やCookieなど暗黙で送られるものもチェックされないことがありますね。油断せず、サーバに送られる全てのデータについてテスト設計しないといけません。
サニタイジングテストの設計方針は簡単です。文字化けのように意図通り表示されなかったり、スクリプトやプログラムとして実行されるような文字列を、テストデータとして設計すればよいのです。しかしそれだけではテスト設計できませんから、サニタイジングテストで用いる代表的なテストデータを挙げておきましょう。
もちろん、これで全部ではありません。テスト対象やミドルウェア、DB、OSの仕様をよく読んで判断して下さいね。
多くの組織でテストケースが消化できない最大の原因は、テスト対象のソフトウェアにバグが多すぎることです。テストをする度にバグが発生していては、いつまで経ってもテストが終わりません。試しに、バグの発生しない（OKの）テストケースと、バグの発生する（NGの）テストケースの両方について、テストケースあたりの実施時間を測定してみて下さい。圧倒的にNGの場合の方が時間がかかるでしょう。
NGテストケースの方が実施時間が長いのは、現場にいらっしゃる方なら肌でお分かりのことと思います。少なくとも不具合報告書（バグ票）を書く時間はかかりますね。OSごと落ちてしまうバグの場合は、再起動の時間がかかります。ファイルやDBの中身を壊してしまうバグが発生すると、テスト環境を全て初期状態に戻さなくてはなりません。気の利いたテスト技術者であれば、バグの切り分けを行うために、似てるけど異なる機能やパラメータ、操作手順で再テストするでしょう。もしかしたらテスト仕様が曖昧で、開発者に電話をかけなくてはいけないかもしれません。再現性を確認するために再テストも必要です。もし再現性が低かったら．．．。
したがってテストの進捗をスムーズに行うには、バグが少ないテスト対象をテストするようにすればよいのです。え？そんなこと分かってる、そんなことができれば苦労しない、そもそもそれならテストなんて要らないじゃないか、ですって？もちろん、バグの数をゼロにすることはできません。しかし「なるべく」少なくする工夫はできますよね。
その工夫の一つが「スモークテスト」です。ハードウェアの「焼き入れ試験（違うかな？）」が語源のようですね。作ったばかりのハードウェアに電源を通してみて、煙がモクモク上がってこないかどうか確認する、というテストになります。ソフトウェアの場合は、テスト対象のビルドに対してテストを開始する前に、簡単なテストを行うというものです。テスト開始資格審査と呼んでもいいでしょうし、「テスト側受け入れテスト」と呼ぶこともできます。
内容はとても簡単です。最も重要な機能や、過去に致命的なバグを起こした機能を中心に、短時間でできるテストを抜き出しておき、ビルドがテストチームにリリースされたら、ササッと実行するのです。テストプロセスに依存しますが、短ければ30分～2時間、長くても半日～1日程度で終わるようなテスト項目に絞っておきます。また凝ったバグ票は書く必要がありません。チェックリストがあれば十分でしょう。
なぜスモークテストは有効なのでしょうか。開発プロセスがきちんと機能しており、整然と管理されているプロジェクトであれば、それほど効果はないでしょう。スモークテストが有効なのは、混乱しているプロジェクトです。混乱しているプロジェクトでは、構成管理のミスによって先祖返りが起きたり、十分な数のバグが潰される前にビルドがどんどんリリースされたりします。こうしたプロジェクトでは、ビルドリリースの度に、テストチームが以前指摘したはずの不具合を検出したり、重要な機能に致命的なバグがあって他の機能のテストができなくなったりします。そこで、必要最低限の品質が確保されているかどうかをスモークテストでチェックすることにより、本来不必要なテストの遅延を防ぐのです。
またスモークテストを始めることで、ビルドリリースのタイミングを整えるきっかけができます。混乱しているプロジェクトではテストチームの都合を考えずにビルドリリースが行われるため、テストしたばかりの機能に手が入れられて再度ビルドがリリースされてしまったりします。1日に3回もビルドリリースされるプロジェクトもあります。こうなると、テスト結果が無効になってしまい、同じテストケースをビルドリリースの度に実施しなくてはならなくなってしまうのです。とてもムダですね。スモークテストをテスト側が行い、その時期をテストチームが指定すれば、開発チームにビルドリリースを我慢してもらうことができますので、落ちついてビルドごとに品質を安定してもらうきっかけになります。
スモークテストはビルドリリースの度に行うので、テストツールによる実施の自動化が効果的です。組織によっては、ビルドの直後に自動でスモークテストを実施し、スモークテストでNGが出たらビルド失敗とみなすところもあります。こうしておけば、テストチームが時間を割く必要はありません。
自動化しなくても、スモークテストのテストケースを開発チームに提示しておき、ビルドリリースの際に開発チームに実施してきてもらっても構いません。テストチームは、ビルドごとに開発チームの実施したスモークテストの結果のチェックリストを確認するだけです。これも大げさなドキュメントは要りません。
やや高等な技としては、開発チームに提示したスモークテストを、ビルドごとに少しずつ高度にしたり、数を増やすというテクニックがあります。スモークテストは開発チームにとって「当たり前に動くはずの」ハードルばかりです。ハードルを少しずつ上げていくことで、開発チームの品質意識を向上してもらうのです。致命的な不具合が発生したテストケースを中心に増やしていくとよいでしょう。また自動化を行っている場合であれば、数を増やすのも難しくありません。
スモークテストは、通過して当然のテストです。スモークテストに何度も失敗するようなプロジェクトは、非常にまずいプロジェクトだと認識するようにして下さい。そもそも仕様変更が多かったり、設計に必要な考慮事項が不足していたり、プロジェクトマネジメントがメタメタだったりします。プロジェクトが終わったら、またはプロジェクト進行中に、スモークテストの様子を確認してプロジェクト全体を見直し改善するようにしましょう。スモークテストのせいで開発チームとテストチームが対立するようなことは、絶対にないようにして下さいね。
]]>さてテストとV&Vの違いは、どう書いてあるでしょうか。邦訳から引用してみましょう。
11.2.2 SQAおよびV&Vの目的と計画V&Vは、より直接的にプロダクト品質を目的とし、テスティング（testing）をベースにして逸脱（deviation）を発見し、修正する。しかし、V&Vは、中間プロダクトの妥当性確認（validation）も行うために、したがってソフトウェアエンジニアリングプロセスの中間ステップの妥当性確認（validation）も行うことになる。
ちょっと難しい記述ですね。要するにV&Vはテストだけでなく、レビューやインスペクションなども入るということが書いてあります。V&Vとは、ソフトウェア開発の成果物にバグがないかどうかチェックする作業すべてだと考えておけばよいでしょう。プログラムを実行してバグを叩き出すのがテストで、プログラムやドキュメントなどを「実行させないで」バグを叩き出すのがレビューやインスペクションなどです。その両方を含むのがV&Vになります。両者を区別するために、テストを「動的テスト」と呼び、レビューやインスペクションを「静的解析」と呼ぶことがあります。静的解析には他に、メトリクス分析やデータフロー解析なども含まれるようです。でも、だからといって、始めのVがテストで、後ろのVが静的解析とは限りません。
V&Vの始めのVは、"verification"のことです。フロッピーディスクやCD-Rにデータを書き込んだ後に正しく書き込めたかどうか確認することを、ベリファイ（verify）と言いますね。僕は、2つのものが同じかどうか比較する、という意味だと捉えています。SWEBOKには、どう書いてあるでしょうか。「11.2.2.3 V&V計画」に説明があります。
検証（verification）アクティビティは、特定のプロダクト、すなわちプロセスの成果物を検査し、定められた要求が満たされたという客観的証拠を提供する。「定められた要求」とは、検査（examine）される成果物の要求のことを指し、それが導出されたプロダクトと相関がある。例えば、コードは、設計記述の要求に関連して検査（examine）され、ソフトウェア要求はシステム要求に関連して検査（examine）される。
verificationについて理解するには、「プロセス」という考え方を理解しておく必要があります。ここでいうプロセスとは、ウォーターフォールプロセスとかスパイラルプロセスとかラショナル統一プロセス（RUP）という“ソフトウェア開発の流れ全体”ではありません。プログラミングとか要求定義といった、“ソフトウェア開発の一つ一つの作業のまとまり”のことです。「アクティビティ」と呼ぶ方が適切という意見もあると思います。
プロセスとは、入力を出力に変換する作業のことです。難しい表現ですね。どういうことでしょうか。例えばプログラミングプロセスであれば、詳細仕様を見ながら、その仕様を満たすようにソースコードを書いていくと思います。この場合、詳細仕様が入力で、ソースコードが出力になります。詳細仕様は、その前の詳細設計プロセスの出力になるわけですから、ソフトウェア開発はプロセスが数珠つなぎになったものだと捉えることができますね。それぞれの数珠の玉がプロセスです。数珠の間で受け渡しされるのが、前のプロセスの出力であり、後のプロセスの入力です。これを中間成果物と呼びます。
さてverificationの話に戻りましょう。verificationとは、プロセスの入力と出力が合致しているかどうかを付き合わせて比較し、間違いがないかどうかチェックすることです。プログラミングプロセスのverificationは、コードレビューであり、単体テストです。コードレビューでは、プロセスの入力である詳細仕様と、プロセスの出力であるソースコードを付き合わせてチェックしますね（もちろんコードレビューでは他にもやることがあるのですが、とりあえず考えないことにします）。単体テストでは、プロセスの入力である詳細仕様と、プロセスの出力であるソースコードの代わりとしてソースコードの実行結果を付き合わせてチェックします。プロセスの出力か代用品かという違いはあるものの、プロセスの入力と出力を付き合わせてチェックすることには変わりありません。
ではV&Vの二つ目のVは何でしょうか。"Validation"のことです。validaitonの語源はラテン語のvalidusだかvalereで、力強いとか、健康になるとか、幸せとか、価値があるとか、そういうことのようです。僕は、良いかどうか調べる、とという意味だと捉えています。SWEBOKには、どう書いてあるでしょうか。やはり「11.2.2.3 V&V計画」に説明があります。
妥当性確認（validation）は、特定されたプロダクトを検査（examine）し、特定の意図された効用に対する要求が達成されたという客観的証拠を提供する。妥当性確認（validation）は、プロダクトがソフトウェアシステム要求へと遡及追跡し、それを満たしていることを確認する。このことは、システム及びソフトウェア要求プロセスと、多かれ少なかれ並行して、システムテスティング（system testing）を計画することを含む。妥当性確認（validation）のこの側面は、一般に要求検証（requirements verification）アクティビティの一部として機能する。
要するに、ソフトウェアが要求を満たしていることをチェックする、ということのようですね。プロセスとか何とか難しいことは置いといて、とにかくソフトウェアがお客さんを満足させているかどうか、がvalidatoinのようです。これは分かりやすい考えです。
理詰めでモノを考える人は、ここで疑問を感じると思います。verificationを全てきちんとやっておけば、ソフトウェア開発の一番最初の入力である要求と、一番最後の出力であるソフトウェアが合っているかどうかチェックできるのではないでしょうか。すなわち、verificaitonがあればvalidationはいらない、と思いませんか。
まぁ理屈としてはそうなのかもしれませんが、実際には両方必要です。プロセスの入力と出力が全て対応できるとは限らないからです。例えば顧客の要求は、全て仕様には反映されません。要求仕様をきちんと全て反映している設計ばかりであれば苦労しません。伝言ゲームと同じように、プロセスが複数連なると大きなずれが生じてきます。ですからverificationとvalidationは両方必要です。賢い人ほど誤解しますので、気を付けてくださいね。
ところでverificationとvalidationの違いは、Boehm御大が分かりやすくまとめています。
ところでvalidationは、「妥当性確認」と訳すのが普通なんですが、僕はあまり好きではありません。妥当性が意味するのは、必要最低限の満足なような気がしませんか。validationで行うべきなのは、必要最低限の満足が提供されているかどうかを確認するのではなく、上を見ればキリがない顧客の満足をどの程度達成できているかどうかを「評価」することだと思います。テスト技術者の仕事が仕様の確認ことから、お客様にどのくらい満足して頂けるかどうかを評価すること、になっていくといいですね。その方が楽しいじゃありませんか。
「もう２流のテスト技術者はいらない」とまぁ、刺激的なタイトルです。中身を見ていきましょう。まず
「"We have world-class developers, but our testers are second class." I hate hearing that. Too often, it's true―and it's not the testers' fault.」
「Testing a complex system is just as difficult as creating a complex system. Just creating unit tests that test each path or object individually is not sufficient testing for a complex system. Sometimes we also need product experts to test the system. Sometimes we need people who understand the design of the system, even if they don't have any coding background. Sometimes we need fabulous exploratory testers, people who want to see how they can break the software. And sometimes we need testers who can develop maintainable automated tests―the larger the system, the more likely the system will hang around for more years than anyone can believe, and well-designed, well-developed automated regression tests that don't require much maintenance can save you money.
…
If you don't associate testers with each development function, or you think that testers exist only to find defects, you're not receiving the full potential value of your testers. And the new testers you hire won't be able to keep up with the developers. You'll have a second-class test group.」
複雑なシステムをテストするのは、開発と同じくらい難しい。そのため色々なテスト技術を持った技術者が必要になる。開発ではGUIや通信、アーキテクチャ構築、データベースなど様々な技術が必要になるため、それぞれ区別して考えるものの、テストでは様々なテスト技術を一括りにして考えることがほとんどだ。しかしそれでは、２流のテストグループになってしまう。
日本では“テスト技術者”と区別して呼ばれればマシな方ですが、本当はその中でも色々な分野があるんですよね。
「Testers have at least three unique sets of customers: the developers, the product's users, and the people who make release decisions. To the developers, testers provide information about where they were confused, or how easy it was to test a particular product area, or what doesn't work about the product―feedback about the developers' efforts. To the product's users, they supply information via a support group that understands the problems in the product. To management, they provide information relevant to assessing the risk of release. To serve all of the testers' customers, you must have first-class testers.
…
So how do you create a first-class test group? We don't live in a perfect world, but one way to improve your test group's skill is to imagine what a test group would look like in a perfect world, and then to hire or train against those requirements.
…
Testers don't just test the product; testers can fulfill numerous other roles on the project. I've used testers as project coordinators, as technical review readers and moderators, as design team members, and as testware developers.」
テスト技術者には、開発者、ユーザ、マネジャーという３つのお客さんがいる。開発者には製品に関するフィードバックを、ユーザには不具合に関する情報を、マネジャーには出荷時のリスクに関する情報を提供するために、１流のテスト技術者が必要となる。１流を目指す一つの手段は、理想のテスト技術者をイメージすることだ。プロジェクトのまとめ役、レビューのリーダーや取りまとめ、設計チームの一員、テストハーネスやテストツールの開発を行うのもテスト技術者の役割である。
一番良くないのは、テストチームを組織するフリをしてテスト技術者を押し込めることです。風通しが悪くなり、上流の技術者にフィードバックがかからないばかりか、「テストの連中がバグを見つけてくれるから、俺たちは早く仕事をあげちまおう」と品質に対する責任感を弱めてしまうことにつながってしまいます。上流からテスト技術者をなるべく参加させることが、トータルで品質のよいシステムを作るために重要ですね。で、保険システムと超音波システムでの体験談の後に、テスト技術者を組織する側の姿勢を述べています。最後に、
If you're already managing a test group, think about where your testers are successful and where they are not successful. Supplement the staff you have with other talent when it's time for you to hire, and make sure you have auditions or other interviewing techniques to hire the kinds of testers you need.Testers don't have to be second class in your organization. Hire and train your staff appropriately so that they fulfill the needs the organization requires.
読者がテストマネジャーなら、自分の組織のテスト技術者のスキルをガッチリ把握して、適材適所を守ること。新たに人を増やすなら、しっかりスキルを見極めること。２流のままにさせないように、きちんとトレーニングを行うこと。
とテストマネジャーに渇を入れてます。人を増やせば何とかなる、と思っているうちは、良いテストマネジメントなどおぼつきません。自分の組織にはどんなスキルの技術者が必要なのか、をよく考えて人材育成を行うのが、やはり王道なんです。そのためには、まずテストマネジャーの心構えが１流でないといけませんね。
ちなみにこの記事は、彼女のWebサイトでも読むことができます。こちらには「テスト技術者の２流度チェック」「テストグループの付加価値度チェック」「テストと開発の関係度チェック」「テスト技術者のスキル」というコラムもありますので、ぜひ原文を読んでみてください。
仮に自分の組織のテストケースが前者の粒度だったとしましょう。もしユーザ権限が4つあった場合は、それぞれの権限に合わせたアカウントで、最低でも4種類のテストケースを作成することになります。では逆に、権限の異なる4つのテストケースをレビューすることになったら、皆さんはどうしますか？
まず4つのテストケースの違いを考えますね。ふむふむ、ユーザ名が違うなぁ、なぜ違うんだろう、と考えながら仕様を思い出したり、仕様書をめくったりします。なるほど、ユーザ権限が異なるわけか、では必要な権限は網羅されているかな、なんて考えながらレビューしていくと思います。面倒ですね。
では、4つのテストケースに対して「すべての権限のアカウントでログインするためのテストケースです。この4つはセットです。」という注意書きがついていたらどうでしょう。テストケースのレビューがとても楽になります。テストケースを考えた担当者の思考プロセスを追うことができますから。
言い換えると、テスト担当者は「すべての権限のアカウントでログインする」という粒度の粗いテストケースをまず考えて、それから4つの粒度の細かいテストケースを導き出したわけです。テストケースを漏れなく考えるためには、粒度の粗いテストケース（すべての…ログインする）をまず考えて、制約条件（権限は4種類）を挙げ、粒度の細かいテストケース（○○というユーザ名…ログインする）に詳細化すると便利です。これを私はテストの「設計」と呼んでいます。またテスト設計の中間成果物を示すと、テストのレビューが容易になってテスト漏れを防ぎやすくなります。
テストの設計を行うと、仕様変更に強いテストケースができますね。テスト設計をせずに細かいテストケースを一つ一つ挙げるだけだと、要求事項の変更に関係するテストケースが分かりにくくなってしまいます。先ほどの例で、権限が3種類に減ったらどうやってテストケースを変更すればよいでしょうか。4つのテストケースを全て見直さなくてはなりません。しかしテスト設計を行うと、それぞれの詳細化のプロセスで考慮する制約条件が明示されますから、全て見直す必要は無くなり、仕様変更によるテストのモレやムラは減りやすくなります。
仕様変更に強いということは、再利用が楽になるということです。再利用した要件と変更した要件の差をきちんと認識しておけば、再利用できるテストケースの粒度と、再設計が必要なテストケースの粒度を分けることができます。先ほどの例で、新しいシステムでログイン手段がキーボード入力でなく指紋認証になった場合でも、粒度の粗いテストケース（すべての…ログインする）はそのまま流用できます。
ちなみに私は、最も細かい粒度のものをテストケース、テストケースよりも粗いものをテストアイテムと呼んで区別しています。テストアイテムには何レベルも粒度がありますね。何をどう呼ぶかは好みですが、テスト設計だけは忘れないようにして下さい。
]]>さて、なぜ生産技術は競争力の源泉になるのでしょう。それは、真似のできない技術だからです。決して日本人は手先が器用だからではありません。オートバイをバラして同じものを作ってしまう方が、よっぽど手先が器用かもしれませんよ。
技術の真似には2種類あります。1つは現地企業に技術供与をしたり、生産委託をすることで技術水準が追いつくケースです。もう1つは、製品のリバースエンジニアリングによって技術を盗まれるケースです。前者は技術水準を引き上げようとしているわけですから、今回は除外しましょう。技術を真似されて困るケースは後者ですね。
リバースエンジニアリングをされると、製品に作り込まれた技術は真似されてしまいます。では逆に考えましょう。製品に跡形も残らないような技術であれば、真似はされません。そんな技術はあるんでしょうか。それが生産技術です。いかに早く安くきちんとモノづくりをするか、という技術を磨き上げることが競争力の源泉になるわけです。
では、ソフトウェアで真似されない技術とは何でしょう。その一つが、テスト技術です。テストをいかに早く安くきちんと行うか、という技術を磨き上げても、その技術は決して製品に残りません。製品に残るのは、バグが無いという事実だけですから。テスト技術は、リバースエンジニアリングによって真似されることもありません。すなわちテスト技術は、ソフトウェアのモノづくりを支える重要な技術になるわけです。
テスト工程は、ソフトウェア開発のボトルネックになっています。現状のソフトウェアの開発工程は、最低でも3割、多い場合には9割近くもテストに割いています。テストの改善は大きなコストダウンの源泉であり、ひいては競争力の源泉にもなるのですね。ぜひ自社のテスト工程を見直して、改善を図ってみてください。
例えばWebアプリのログイン画面を思い浮かべて下さい。「ログインする」がテストケースだと答える場合もあれば、「○○というユーザ名、××というパスワードでログインする」と答える場合もあります。同時にログインしているユーザが何人いるか、もテストケースに書くと考えた方もいるでしょう。ユーザ名の入力とパスワードの入力の順序を考えた方もいるかもしれません。もしかしたら、GUI自動操作ツールのスクリプトを意味する場合もあるかもしれませんね。
このように、テストケースには色々と細かさのレベルがあります。このレベルのことを、テストケースの「粒度」と私は呼んでいます。粒度は粗すぎても細かすぎてもいけません。
例を挙げましょう。「ログインする」というテストケースを、テスト実施担当者（テストオペレータ）に渡したとします。テストオペレータは、テストケースにアカウント情報が書いてありませんから、適切と思われるユーザ名とパスワードでログインするでしょう。しかしこれでは、毎回ログインするアカウントが異なってしまうかもしれません。アカウントによって権限が異なるため、バグが見つかったり見つからなかったりするのです。したがって、テストケースを実施するたびにテスト結果が異なってしまいます。これは粒度が粗い例です。一般的に、粒度が粗いと誤解が生じやすくなります。
ではテストケースの粒度を細かくすればよいのでしょうか。全てのテストケースに「ユーザ名は○○で、パスワードは××で、同時にログインしているユーザはAとBとCで、ログインする前にPとQとRの操作をして．．．」なんて書いていると、書く手間ばかりかかってしまいます。一般的に、粒度が細かいと工数が増加します。工数の問題でテストケースの粒度を細かくできない場合は、テスト実施の記録を細かく取るようにするとよいでしょう。ただし記録に手間がかからないように工夫する必要はありますが。
適切なテストケースの粒度は、どの程度でしょう。それはテスト組織ごとに異なります。新人にテストを実施させる場合には、粒度を細かくすることを意識した方がよいでしょう。一方長年連れ添ったテストオペレータばかりの組織なら、粒度が多少粗くても誤解は生じないでしょう。とはいえ、随時ミーティングを実施して粒度の意識統一を行っておくことが必要です。
テストケースの粒度を意識するのは、良いテストの始まりだと私は考えています。ぜひ一度、自組織のテストケースの粒度を確認してみて下さい。
]]>3Hはソフトウェアのテストでも当てはまります。バグの多そうなところを頭に入れてテストケースを考えると、効果の高いテストが可能になりますね。。ただハードウェアと同じだとつまらないので、ちょっと拡張してみました。
以前ある組織の方から「うちの組織では新人を半年テストに従事させます。新人は現場の厳しさが実感できますし、現場は人手が足りないので大助かりです。良い制度でしょう。」というお話しを伺ったことがあります。テストの現場は、どこでも人手が足りません。それこそ、猫の手でも借りたいところばかりでしょう。
しかし気になったのは、新人でもこなせる仕事だと認識されているのではないか、という点です。新人でもこなせるほど簡単な仕事だと思われている、すなわちテストに“技術”が必要だとみなされていないのではないでしょうか。もちろん、マシンに向かって書かれたとおりにテストケースをただ実行するだけなら、技術はいらないと思っても無理はありません。
テストは立派な技術分野です。一人前にテストをこなすには、とても多くの技術を身につけていないといけません。最も単純と思われるテスト実施だって、色々な技術が必要です。あいまいなテストケースを詳細化する技術、出てきたバグを見逃さない技術、精確かつ簡潔にバグ報告書を書く技術、回避手段を迅速に見つける技術、バグが見つかる範囲を適切に切り分ける技術、テスト環境の段取り換えを素早く行う技術、他のテスト担当者とコミュニケーションを取ってムダなテストを防ぐ技術、開発者とコミュニケーションを取ってバグになりやすい部分をやんわり伝える技術、UIの使いにくさなどをリコメンデーションとして報告する技術。ちょっと考えただけでも、たくさんあります。さらに、テスト設計やテスト管理の技術も必要になります。
テストが技術分野として認知されるには、テストに必要な技術を整理すること、現場同士の技術交流をもっともっと活発にしてテスト技術を発展させること、教育カリキュラムを確立していつでもどこでも誰でもテスト技術を学べるようにすること、テストの良い技術書を増やすこと、産学の連携を高めること、テスト技術の高さがエンジニアの給料や単価に反映されること、上司や開発者、経営陣がテストを技術分野だと認識すること、など多くのことが必要です。
どこまでできるか分かりませんが、一歩一歩進めていかないといけません。バグの少ないソフトウェアを開発できるようテスト技術が向上して、少しでも現場に笑顔が増えるといいですね。
]]>