基礎から学ぶソフトウエア・テスト

bgx5810

今こそテストの基本技術を学ぼう！
      　これから6回にわたってソフトウエア・テストの基本について解説します。テストの基本を理解することは，品質の良いソフトウエアを作るための大切な一歩となるはずです。今回から第3回まではソフトウエア・テストに必要な技術について，第4回から第6回は品質分析やマネージメントについて解説します。
　まず，あるソフトハウスの上司と開発者の会話に耳を傾けてみましょう。
上司●設計は進んでいるか？
開発者●仕様が固まらず遅れ気味です。
上司●それは困ったなあ。対策は？
開発者●とりあえず今の仕様のままで設計を止めて，コーディングを開始します。幸いテスト工程を多めにとってあるので，徹底的にバグ出しをすれば品質は問題はないと思います。
　　　　　　～1週間後～
上司●コーディングは進んだか？
開発者●それが…，仕様変更など手戻りが多くて遅れ気味です。
上司●おいおい，まずいなあ。対策は？
開発者●テスト工程の一部をコーディングにまわして，そのぶんの工数で吸収します。
　　　　　　～1週間後～
上司●単体テストは進んだか？
開発者●やってますが…バグが予想以上に多くて…。
上司●かなり遅れているぞ。対策は？
開発者●基本的な部分のテストはやったので，ここらで切り上げて，後はシステム・テストで対応します。
　　　　　　～1週間後～
上司●システム・テストは終わったか？
開発者●それが実は…1人月の遅れが出ています…。
上司●…。
開発者●でも，他のプロジェクトから5人，1人0.2人月ごとに工数を補てんしてもらえれば，対応できます！
上司●…。
——いやはや，なんとも，これから，この開発プロジェクトはどうなってしまうのでしょう？ ちょっとうすら寒い気がしますね。
　失敗に終わるソフトウエア開発プロジェクトにありがちなのが，要求分析や設計をおろそかにしてコーディングに走るパターンです。これを米国のソフトウエア技術者Steve McConnell氏は，「作ってから直す開発方式（code-and-fix development）」と命名しています＊1。この方式で，一番いいように使われてしまうのはソフトウエアのテスト工程です。まさに冒頭の会話はそのパターンと言えるでしょう。しかし，テスト工程をおろそかにしてしまうと，後でとんでもないしっぺ返しが待っています。
品質にまつわる問題はどんどん増えている　最近，ソフトウエアの品質にまつわるトラブルが大きく報道されるようになりました。携帯電話が特定条件で発着信が不能になった＊2，ウイルス対策ソフトのパターン・ファイルのアップデートによりパソコンの動作が不安定になった＊3などのトラブルは記憶に新しいと思います。検索エンジンで「プログラムミス」「システム障害」「ソフトウエア不具合」などのキーワード検索をすると，その検索結果の件数にビックリするかもしれません。
　これらのトラブルの原因がすべて，「テスト工程をおろそかにしたことにある」とは言えないでしょう。とはいえ「十分なテストをしていれば，ある程度は防げた」ということは言えるのではないでしょうか。テストは，品質を守る大切な役割を担っています。しかし開発の現場では，「ちゃんと作ればテストなどいらない」「テストまで考えてる暇はない」「テストをしっかりやりたくてもノウハウがない」などの様々な理由で，二の次にされてしまっていることが多いのです。
テスト担当者はゴールキーパーである　ソフトウエアの開発プロジェクトを，サッカーにたとえてみましょう。サッカーという競技は，各メンバーが自分たちの役割を果たしながら，かつメンバー間の不足を補いながらゴールに向かって攻めていきますよね。これは，ソフトウエアを開発していくときの，プロジェクト・マネージャ，設計者，プログラマの関係とよく似ています＊4。
　サッカーでは，メンバー全員が「攻め」だけではなく「守り」もできなくてはなりません。この，サッカーで言う「守り」がソフトウエア開発におけるテストに当たります。守りの専門職であるゴールキーパーがテスト担当です（図1[拡大表示]）。
　サッカーには，完全な防御方法はありません。点を入れられてしまう可能性は常にあるわけです。これと同じで，ソフトウエア・テストにもすべてのバグを発見する方法はありません。プログラムはいくらでも複雑に作ることができますし＊5，時間的，経済的な理由からテストをいつまでも続けることはできないからです。
　ここで，「完全にできないからがんばってもしょうがない」と結論付けたらそれまでです（この記事がいきなり終わってしまいます…）。大事なことは，不完全だからこそ，効果的な方法でテストする腕が必要だということなのです。
得点させない仕事はみんなの仕事　無得点に押さえるには，自陣にボールを持ちこませないようにする——つまり，他のメンバーが攻めて守って，ゴールキーパーは仕事をしなくても済むという状態が理想です。ゴールキーパーが常に忙しいような試合を見たら，たとえ無得点に押さえていても，誰もが危ないと感じるはずです。得点されないように守るのはゴールキーパーだけの仕事ではないんですね。
　「守り」をテストにたとえても同じことが言えます。開発の初期段階からテストを開始し，開発者自身が単体テストや結合テスト（後述）をきっちり行い，テスト担当が行うシステム・テストでは，もはや細かいバグは出ない状態を作ることを目標にするべきです。
　かといって，優秀なチームができたらゴールキーパーはいなくてもよい，もしくは誰でもよいとはならないですよね。試合の中では攻撃陣でうまく守れたとしても，フリーキックやPKがあります。ゴールキーパーも優秀でなければならないはずですし，そうなるように自分の技術を磨こうと日々練習に励むはずです。
　ソフトウエア開発も同様です。テスト担当者はいなくてもよい，もしくは誰でもよいということはありません。テストの技術を身に付けてスキルアップしていくことが必要なのです。
ゴールキーパーは試合状況を
一番良い位置から見られる　ゴールキーパーは，ピッチの中の一番いい位置から冷静に試合を見て，他のプレーヤーの配置などを指示していますね。どのように攻められると守りにくいかもよくわかっているので的確な指示が出せるのでしょう。
　これと同じで，テスト担当もテストするソフトウエアが来るのをただ待っているようではプロとは言えません。自ら設計まで関与することで，品質の作り込みに貢献することが大切です。
　テスト担当は開発の当事者ではないので，要件定義や設計の段階で冷静に状況をチェックできます。また，テスト設計のために開発資料を読み込んでいくため，詳細な部分まで見ていくことができます。開発者が自ら品質向上を行うという意識が高まるように，テスト担当はあの手この手を使う姿勢が必要でしょう。
　また，サッカーでは，ゴールでボールをとったら攻撃陣の攻めやすい適切な場所へボールを渡することもゴールキーパーには必要な技術です。テスト担当も，バグを見つけたら開発者がデバックしやすいように現象を切り分けて，バグ・レポートを開発者に伝えます。これも重要な技術です。
以上のことをまとめてみましょう。
・完全なソフトウエア・テストはできない。だからこそテストの腕を磨こう
・テストは開発メンバー全員の仕事なので，テスト担当だけでなく全員がテストについての技術を身に付けよう
・どんなに開発者が優秀でも，テスト担当自身も技術力を磨こう
・テスト担当は受け身にならず，常に開発全体を見渡してフィードバックをかけるための技術を身に付けよう

bgx5810

今こそテストの基本技術を学ぼう！
      

図2●開発とテストの関係を示すVモデル [画像のクリックで拡大表示]

リスト1 ●必ずしも正常に動作するとは言えないJavaのコードの一部 [画像のクリックで拡大表示]

図3●ソフトウエア・テストに必要な五つの技術/知識 [画像のクリックで拡大表示]

    テストといってもいろいろある　サッカーからの教訓で，テストは開発メンバー全員の仕事と書きましたが，それぞれのメンバーが行わなければならないテストは一言ではくくることができないくらい，いろいろな種類があります。
　では実際にテストはどのようなことをどんな順序で行っていくのでしょうか。その疑問に答えてくれるものの一つが，開発工程とテストとの関係を表す「Vモデル」です（図2[拡大表示]）。Vモデルでは，開発工程に対応した形でテストの種類を決めています。
　テストに工程を設けるのは，テスト対象への視点を整理することでテストが混乱しないようにするためです。例えば，メソッドのパラメータの組み合わせパターンのテストと，システムとしての使い勝手を評価するためのテストでは，テスト担当も違えば，テスト環境やテスト実施方法も違います。また，工程を分けてより早くテストを始めることで，問題の切り分けを楽にするという意味もあります。
　では，図2の下の部分から各工程のテストを順番に見ていきましょう。
静的テスト（コード・レビュー）　まず，最初に行うのが「静的テスト（コード・レビュー）」です。リスト1[拡大表示]を見てください。あるプログラムに書かれたJavaのコードの一部です。注目は2行目。doubleのような浮動小数点数を扱った場合，正確に答えがズバリ出るという保証はありませんよね。したがって，5行目のif文で，aと1が等しいかどうかを判定するにはやや無理があります。思った通りには動かない場合があるからです。
　このように，コンパイルは無事通ったとしてもバグになる（もしくはバグになりやすい）コードになっているのをチェックするのが静的テストです。たくさんのif文が入れ子構造になっているかどうかなどをチェックするメトリックス分析などの作業も含まれます。
　静的テストは，自分自身あるいは開発者同士でコードをレビューしあって行います。静的解析用のテスト・ツールを使い，コンパイルするときに一緒に確認してしまうのもよいでしょう。
単体テスト　次に行う「単体テスト」では，モジュール内のコードが正しいロジックかどうかをチェックします。ソースコードに対するテストの網羅度合いを測定したり，モジュール・レベルの機能仕様や予期しない例外について確認したりします。
　通常，単体テストはコードを書いた本人が行います。コーディングした直後であれば，書いた内容を理解した状態でテストするので，バグを見つけた後のデバッグも時間がかからないからです。最近では，xUnit（Java言語ならJUnitが有名ですね）のようなテスティング・フレームワークを使うことが多くなってきました。
結合テスト　「結合テスト」では，大きく分けて2種類のテストを実施します。
　一つ目は，関数の呼び出しや他のクラスへのメッセージングなど，モジュール間のつながりが正しいかどうかをチェックするテストです。もう一つは，GUIまで結合した状態で，ソフトウエアに実装された機能が仕様書と合っているかどうかをチェックするテストです。この二つは，ソフトウエアの規模が小さければ同一工程として行いますが，規模が大きい場合は，前者を「コンポーネント・テスト」とフェーズ分けする場合もあります。
　普通，結合テストは，結合する対象の関数が全部自分で書いたものならば自分自身で行えるでしょう。しかし，チーム内の別の人が書いたモジュールとの結合であれば，事前にメンバー間でテストする部分を分担しておきます。分担をし忘れると，誰もテストしていなかったなんてことになるからです。ユーザーがソフトウエアを使うまで欠陥が見つからない原因は，このような分担漏れにある場合が非常に多いのです。なお，結合テストの段階からテスト・チームがテストを行う場合もあります。
システム・テスト　「システム・テスト」は，開発の最終段階で，ユーザーの元に届くものと同じ状態でソフトウエアをテストして，製品としての品質を評価するテストです。システム・テストには様々な種類がありますが，基本はユーザーがそのソフトウエアを使う状況/手順に沿って動作させることにあります。
　例えば業務システムの場合，会社内で複数の人が行う業務の流れをシミュレートするようなシナリオを，本番と同様のデータ量，同様のトランザクション，同様の環境でテストします。
　また，セキュリティ面のテスト，障害が発生した後の対応についてのテスト，ネットワーク/周辺機器/制御対象のハードウエアなど，本番運用で使う機器と接続してチェックするテストも行います。システム・テストは，テスト専門チームが行う場合が多く，またそのほうが良いとされています。
受入テスト（ユーザー受入テスト）　本番運用直前に行う最終的なテストが「受入テスト」です。受託開発では「ユーザー検収」と呼ぶこともあります。受入テストでは，本番環境で，実際に使う人自身が本番稼働して良いかどうかを判断します。
　少なくともこの段階までに，もはやバグが出ないようシステム・テストまでのテストをしっかり行っておく必要があります。なぜなら，簡単なバグでもバグ修正が新しいバグを生み出す恐れがあり，本番運用時期に影響が出るからです。バグが出たときは，慎重に判断し修正するのは致命的なバグに限定する必要があります。
　以上，テストの工程とその中で行うテストを説明しましたが，ソフトウエア・テストを実施していく流れが見えてきたでしょうか。以降は，ソフトウエア・テストを行うための，より具体的な技術について説明していきましょう。
ソフトウエア・テストに必要な五つの技術/知識　図3[拡大表示]は，ソフトウエア・テストを行うために必要な五つの知識や技術を分類したものです。
　まず最初に必要なのは，なにはともあれテスト固有の技術ですね。固有の技術以外にも開発全般の技術を広く浅く（適度に深く）身に付けておく必要があります。詳細は後述します。続いて必要なのが業務知識です。これは，要件や機能をテストするために必要です。設計図の知識というのは，UMLやER図などの知識です。これらの図面を読めないとソフトウエアがどのように設計されているかを理解できず，テスト設計の効率が落ちてしまいます。
　また，OS，ハードウエア，ネットワークの基本知識も必要です。最適なテスト環境を準備するためです。一つのテスト環境で何人ものテスト担当がテストを行う場合，テスト環境のミスは人数分の工数を無駄にすることになります。
　プログラミングの知識は，単体テストのレベルのテストを設計/実施するためには当然必要です。単体テスト以降のテストでも，テスト用プログラムやスクリプトを書くためにプログラミングの知識は必要です。特に，結合テストでテスト設計を効果的に行い，バグを修正したあとの回帰テスト＊6のために影響範囲を分析するためにも，ある程度のプログラミング知識が必要になります。
では，前述したテスト固有の技術としては，どんなものが挙げられるでしょう。大きく分類すると，
(1)テスト設計技術
(2)テストの実施を効率化する技術
(3)テスト・ベースをレビューする技術
(4)バグ報告の技術
の四つに分けられます。以降は，これらを細かく解説していきます。

bgx5810

(1)テスト設計技術テスト設計のポイントは少ないテストでモレなく網羅 テスト設計には図4[拡大表示]のようなポイントがあります。テストはやろうと思えばきりがありませんから，最小限の労力で最大の効果が得られるように知恵を絞ろうというわけです。
      

[size=-2]図4●テスト設計の心得 [size=-3][画像のクリックで拡大表示]

[size=-2]表1●漏れがないようにテスト対象を網羅するための三つの視点 [size=-3][画像のクリックで拡大表示]

[size=-2]図5●表1の三つの視点とテスト実施工程との関係 [size=-3][画像のクリックで拡大表示]

[size=-2]図6●コード・ベースの視点によるテスト設計の例 [size=-3][画像のクリックで拡大表示]

[size=-2]図7●デシジョン・テーブルの例。TはTrue，FはFalseを表す。しかし，本当にこれでいいのか… [size=-3][画像のクリックで拡大表示]

[size=-2]図8●作成し直したデシジョン・テーブル [size=-3][画像のクリックで拡大表示]

[size=-2]表2●テストすべき値の検討結果。MAXの値は不明。( )の数値は，他と重複するのでテストする必要はない [size=-3][画像のクリックで拡大表示]

[size=-2]リスト2●Webアプリケーションのログイン・テストに使うWSH（VBScript）のプログラム例 [size=-3][画像のクリックで拡大表示]

 「より少ないテスト・ケース」にするために必要な考え方として「同値クラス」があります。同値クラスは，テストに使う入力値が同じ結果をもたらす場合，その入力値を「同値」と呼ぶことからきています。例えば，判定の条件になる数値範囲が1～100の場合に，テストするときの値を100個全部入れていたら時間が足りませんよね。100個の値が全部同じ判定をするのならば，代表になる値を何個か選択してテストするほうが断然効率的です。そこでテストする際は，入力値，出力値，判定条件，時間的な範囲，仕様上の範囲などあらゆるものの「同値」を見つけることでテストの数を減らしていこうというわけです。
 「より多くのバグが見つかる」ための代表的な方法として「境界値分析」があります。同値クラスの中から代表を選ぶときに「境目」，つまり境界の値がどこかを分析してテストに使う値とするのです。なぜ，境目の値を狙ったテストで，多くのバグを見つけられるのかというと，境界値は要求分析でも実装でも，勘違いしたり間違えたりしやすいからです。例えばある数字「以下」と仕様書には記載してあるのに，開発者が「未満」だと思い込んで作り込むケースがあったとします。この場合，「境目」の値をテストすれば簡単にバグを見つけることができます。
 「漏れがないようにテスト対象を網羅」する視点としては，要件ベース，設計ベース，コード・ベースの三つの視点があります(表1)[拡大表示]。この三つの視点と各テスト工程の関係は図5[拡大表示]のようになります。このようにどのテスト工程でも三つの視点をもってテスト設計を行うことで，網羅したテスト設計が行えるようになるわけです。
コード・ベースと要件ベースの
テスト設計をしてみよう 三つの視点のうち，要件ベースとコード・ベースの二つについて，具体的にテスト設計を行ってみましょう。まずは比較的考え方がシンプルなコード・ベースからです。
 コード・ベースの視点では，代表的なテスト設計方法である制御パス・テストでテスト設計を行います。制御パス・テストは関数やメソッドのロジックの処理経路(パス)を動かすテスト方法です。まず図6[拡大表示]のようにソースコードをフローチャートなどでモデル化します。その後にプログラムの処理経路を洗い出します。
 図6の例では，A，B，Cの処理経路を洗い出しました。この三つの処理経路を通るためのデータは，それぞれ，A(0～80)，B(81～99)，C(100)の三つになります。この三つのパスのどの値を使うかは，前述した境界値分析の考え方を使います。したがって
A：-1，0，80，(81)
B：(80)，81，99，(100)
C：100，101
の値が挙げられるでしょう＊7。つまり，7個のテスト・ケースが考えられます。
 次は要件ベースのテスト設計です。あるイベントのチケット代金の支払いについて，仮に次ページのような要件仕様があったとします。
「年齢が6歳以上18歳以下，現住所が埼玉県，学生証の提示ありの場合に，チケット代金を学割金額とする」
 この記述には，たくさんの組み合わせ条件のうちの正常になる一つのパターンしか書かれていません。そこで，デシジョン・テーブルを使って全パターンを洗い出します。デシジョン・テーブルとは，図7[拡大表示]のように条件と動作の関係を表形式で表現したものです。このケースでは，年齢や住所の条件をT(真：True)とF(偽：False)で判断することで，8個のパターンがあることがわかります。
 ただ，ここでよ～く考えてみてください。図7には落とし穴があります。わかりますか？それは，年齢が6歳以上18歳以下という条件だけで年齢を判断してしまっている点です。これでは，0歳から6歳の人と，19歳以上の人の金額はFalseということで同じチケット代金ということになってしまいます。それはどう考えてもおかしいですよね。つまり，これは“仕様の確定漏れ”なのです。こういう場合は勝手に判断せず，正しい仕様はどういうことなのかを確認し直すようにしなければなりません。そこで作り直したのが図8[拡大表示]のデシジョン・テーブルです。
 実際にこの組み合わせを全部テストするかどうかは，各条件の依存関係によって変わってきます。特に依存関係が無い場合は，No.1，No.2，No.4，No.5，No.9の五つのテストを行えば良いでしょう。
 確認用のデータは，年齢は三つの同値にしているので境界値分析の考え方を使います。表2[拡大表示]のようになるでしょう。このとき，MAX値がいくつであるかも，確認することを忘れないでください。

(2)テストの実施を効率化する技術テスト・ツールの有効活用でテストの効率化をはかる テスト固有の技術の二つ目は，いかにテストを効率化して実施するかという技術です。
 テストはソフトウエアを手動で操作して結果を目視するのが基本的な方法です。しかし，動作ミスや目視したときの漏れという問題があります。操作にかかる時間も担当者によってバラツキがあるでしょう。そこで活躍するのがテスト・ツールです＊8。テスト・ツールを使うと，(ユーザー・インタフェースがないので)手動ではできないテストを行う，マニュアル操作を自動化する，テスト実施環境の整備を自動化する，実施結果の収集を自動化する，期待結果と実施結果の比較を自動化するといったメリットが得られます。
 とはいえ，実際にテスト・ツールを使っても，本当に自動化できる部分はテスト全体の10％から最大40％くらいまででしょう。各テスト・ツールの使用方法を理解し，適用箇所をどれだけ増やせるかは，テスト担当者の腕次第というわけです。
 また，短時間で行えるテスト効率化の方法をいくつ知っているかというのも重要です。バッチ・ファイル，シェル・スクリプト，VBScriptやJavaScriptなどのスクリプト言語，スプレッドシート(Excel)などを活用するのは必須テクニックと言えるでしょう。
 例えばリスト2[拡大表示]は，Webアプリケーションのログインのテストに使うスクリプト(VBScript)の例です。test.csvというCSVファイルにユーザー名とパスワードを記録して実行すれば，指定のURLのサイトに接続してログインを試みるテストを行ってくれます。このような機能テストの効率化には，マウスやキーボードの操作を記録して再生するキャプチャ/リプレイ型ツールがありますが＊9，例のような簡単な画面操作の自動化ならスクリプトを使って自作する方法でも十分に効果的なのです。
(3)テスト・ベースをレビューする技術テストの設計と実行を
効率化させるテスト・ベースのレビュー テスト固有の技術の三つ目は，(3)テスト・ベースをレビューする技術です。テスト・ベースとは，テスト設計に使う設計資料一式のことを指します。テストベース・レビューの狙いは三つ，テスト設計の効率化，テスト実施の効率化，テストしやすさの設計への反映です。
 テスト設計のために仕様を理解する中で，前述のデシジョン・テーブルの例のように，記載内容が不十分な仕様を見つけたら，テスト実施の前に開発へその点をフィードバックすることで，テスト設計，テスト実施を効率化できます。また，テストしやすさの設計への反映としては，テスト結果を確認するためのログ機能などがあるか, また, ソフトウエアそのものが，テスト数が少なくて済むような設計になっているかどうかなどを確認します。
(4)バグ報告の技術バグ報告の技術では想像力を試される テスト固有の技術の四つ目は，(4)バグ報告の技術です。これは，バグを見つけたら，バグ・レポートを作成して，修正されたことを再テストして確認するまでを意味します。
 しかしそう書くと，「バグの報告は，テスト技術というよりも，人にわかりやすく伝えることができる“文章力”の問題ではないですか？」という意見が聞こえてきそうですね。確かにその部分はあります。しかし，それだけでもありません。
バグらしき現象を見つけたら，まずそれを表面で判断してはいけません。そのバグが本当にバグなのか，そうでないかの判断が必要です。そのためには，さらに深刻な状況にならないかテストを深堀すること，手順や状況を変えると目立つバグになるかどうかをテストすること，確実な再現手順がないかどうかを調べること…などをしないといけません。これらはある意味，想像力(探索力)が必要な分野です。実は，この探索力こそ，最も重要なテストの能力だと言えるかもしれません。

☆　　　　　☆　　　　　☆

 以上，3回にわけてテストの技術に焦点を絞っていろいろ説明しました。いかがだったでしょうか？ソフトウエア開発では，全員がテストを行わなければならない，またそのテストにも技術が必要であることを理解してもらえたかと思います。次回以降は，ソフトウエア・テストの他の側面として，品質分析とマネージメントについて解説します。お楽しみに！

bgx5810

テストのマネージメントとレポート
　まずは，あるソフトハウスでの納品前の会話に耳を傾けてみましょう。

開発者●テストも全部終了し，納品の準備が完了しました。
上司●よし。残業すれば何とか間に合いそうだな。で，バグの状況は？
開発者●全部直しました。
上司●バグの収束状況を聞いているんだよ。
開発者●忙しかったもので，まだまとまっていません。納品が済んだら調べます。
上司●おいおい，それくらいちゃんとまとめておいてくれよ。じゃあ，制限事項になる部分や，テストが不十分で品質に心配がある部分などは残っているのか？
開発者●いや，特に問題ありません。
上司●このWebアプリケーションは一般ユーザー向けだったな。ブラウザの種類ごとのテストはどの程度やったんだ？
開発者●…テストに使ったブラウザは，Internet Explorer 6（IE6）だけです。
上司●IE6のみ？！ FireFoxやNetscapeでは動作確認してないのか？ まずいなあ。ところでそのIE6のマイナー・バージョンは？
開発者●開発用のパソコンを見ないとわかりませんが…。
上司●それくらいちゃんと調べろ。あと，納品はユーザーが使う他のブラウザでもテストしてからだ！
開発者●えーっ（いまさらバグ出たらどうすんの？ もうかんべんしてよ…）。
——このプロジェクトの開発者は，これから納品までの間，帰れない日々を続けることになりそうですね。こんなときは，テストが余計な作業に見えて仕方ないかもしれません。
　でもこれは，自業自得というものです。あらかじめテストする範囲を計画的に決めておかないと，このような事態になるのです。また，納品前には品質を判断する指標を用意しておくことも，テストの大事な仕事です。これらを怠るといつまでたっても納品後のクレームに悩まされることになってしまうでしょう。
ソフトウエア・テストは何のために行うのか？　皆さんは，ソフトウエア・テストは何のために行うのだと思いますか。書籍「ソフトウェアテスト293の鉄則」＊1には，「つまるところ，テストする理由はただ一つしかない。重要な部分が動かない恐れがあるからだ」と書かれています。確かに，“人間は間違いを犯す生き物である”という言葉があるように，間違いをせずにソフトウエアを作るということは現実的には無理です。テスト工程にリリースしたプログラムのうち，だいたい100行に1～3行は誤りが残ってしまうという報告もあります＊2。プログラミングより前工程の要件定義，設計にも同様のことが言えるでしょう。したがってテスト工程では，そのソフトウエアが意図した通りに動くのか，それとも動かないのかを，きちんと確認しなければなりません。
      

[size=-2]図1●ソフトウエア・テストは家計簿と似ている [size=-3][画像のクリックで拡大表示]

　ソフトウエア・テストの定義は，専門家によっていろいろなものが提案されています。例えば，米国のテスト・コンサルタントであるRick D.Craig氏は，テストを「ソフトウエアの品質を測定して改善するための，テストウエアをエンジニアリングし使用しかつ保守しながら同時並行的に進めるライフサイクルプロセス」と定義しています＊3。この定義は，後述する「テストの全体像」を理解するうえではとてもよいと筆者は思うのですが，ちょっと読んだだけでは今ひとつわかりにくいかもしれません。そこで，ここではもう少し身近な例ということで，テストを「家計簿」にたとえて考えてみたいと思います（図1[拡大表示]）。

ソフトウエアのテストは
家計簿を付けることと似ている　主婦向けの雑誌には「食費2万円実現のための家計簿テクニック」などというタイトルで，家計簿を付けて節約をするノウハウが掲載されていることがあります。筆者の家にもこのたぐいの雑誌が何冊かあるので，暇なときにパラパラとめくってみたりします。
　この「食費2万円実現のために家計簿を付ける」というのは，食費を2万円に抑えることができない“恐れ”があるので，家計簿を付けることで，食費の出費状況を“測定”する行為と言っていいでしょう。
　ソフトウエア・テストも家計簿と同じ理屈です。期待通りにソフトウエアが動かない“恐れ”があるので，ソフトウエア・テストをすることで「大丈夫もしくは大丈夫ではないこと」を“確認（測定）”するのがテストだからです。
　また，家計簿を付けても，その結果を「どうやって節約に結び付けるか」がないと，いつまでたってもただ記録しているだけになってしまいますよね。雑誌に書いてある通りに家計簿を付けても，月2万円の食費を実現することはできないことはおわかりでしょう。でも，家計簿の結果をベースに，夕飯のおかずの金額を調整するなど生活にフィードバックさせれば，月2万円という目標が達成できるようになるかもしれません。
　ソフトウエア・テストも一緒です。テストをしたから品質が上がる，わけではありません。テストした結果をバグ・レポートなどで開発チームに報告し，開発者がプログラムを修正することによってはじめて品質を向上できるようになるわけです。
　つまり，テストとは品質向上のための情報サービスなのです。開発中はバグ情報を，開発終了時にはマネージャや経営者（または顧客）にソフトウエアの品質を評価した情報を，というようにあらゆる人に有益な情報をもたらし，その情報が品質向上のための改善につながっていくことにこそ価値があるわけです。
家計簿/テストは余計な手間ではない　とはいえ，家計簿を付け続けるのはなかなか大変な作業です。買い物をしたらレシートを捨てずに取っておかなければなりませんし，そのレシートを家計簿に転記する時間も確保しなければなりません。最近でしたら，家計簿ソフトを使う方もいるでしょうが，その場合もソフトを使いこなせるようになるまでには，それなりの学習時間が必要です。
　しかし，ここが肝心なところです。こういった導入や運用の手間を惜しむか惜しまないかが，（節約という）目標を達成できるか否かの分かれ道なのです。テストも一緒で，形だけのテストではなく，価値あるテストをするとなると，テストを計画/設計/保守していくエンジニアリングが必要です。また，テストを効率よく設計/実施するための技法やツールなどの技術も習得しなければなりません。これらの手間を惜しむと，結果的には納品後のバグ修正や顧客からの信頼回復などの不毛な手戻り作業が発生してしまうでしょう。
火が噴いてからでは手遅れ　家計簿を付けるときは，その日に使ったお金をその日のうちに記録するのが基本です。お金が足りないと感じてから家計簿を付けだして，結果として「お金の使い方がダメだった」というのでは役に立ちません。問題が大きくならないうちに，日々の結果からその日の課題を家計にフィードバックすることが重要です。また，計画した金額で収まるようにするため，あらかじめ一定の金額を封筒に小分けしておくなどの技も雑誌には紹介されてます。
テストも，「プロジェクトが火を噴いてきたからテストに人を追加投入しよう」という考え方ではうまくいきません。バグだらけのソフトウエアをテストをしても，テスト工数がかさむだけです。テスト工数が計画以上にならないようにするためには，バグを早めに見つけなければなりません。開発の初期段階から設計内容をテストの視点でレビューし，テスト実施前にバグを予防できるように，開発と同時並行的に進めていくのが重要です。
　さて，以上のことをまとめてみましょう。
・テストとは情報サービスだ。品質向上のための改善につながることに価値がある
・テストのための手間を惜しまないのが成功の分かれ道
・早めにテストを行うことで，無駄にテストの工数を増やさない

bgx5810

テストのマネージメントとレポート
      

[size=-2]図2●開発とテストのWモデル。AndreasSpillner氏のモデルをもとに筆者が修正した（オリジナルは，http://www.stickyminds.com/sitewide.asp?ObjectId=3572&Function=DETAILBROWSE&ObjectType=ARTを参照） [size=-3][画像のクリックで拡大表示]

[size=-2]図3●ソフトウエア・テストの全体像 [size=-3][画像のクリックで拡大表示]

[size=-2]表1●テスト計画の例 [size=-3][画像のクリックで拡大表示]

[size=-2]図4●筆者がMicrosoft Accessで自作した障害レポートの入力フォーム [size=-3][画像のクリックで拡大表示]

　たいていの場合，ソフトウエア・テストというと，どうやってテストをするのかといったテストの実施部分だけを思い浮かべるのではないでしょうか。しかし，テストを実施面だけでとらえていると，効果的なテストはできません。
　そこで，米国のソフトウエア技術者であるAndreas Spillner氏が提唱している「Wモデル」という考え方を紹介しましょう（図2[拡大表示]）。このモデルでは，開発とテストは最初から並行して進んでいくプロセスとして表現しています。先ほど，「テストは同時並行的に進めるライフサイクルプロセスである」という定義を引用しましたが，まさにそのイメージがWモデルになるわけです。
　この考え方をベースに，さらにソフトウエア・テストの作業（アクティビティ）を細かいプロセスに分けたのが図3[拡大表示]です。これを見ると「テスト実施」というのが，ソフトウエア・テストの全体の中で，ほんの一部でしかないことがわかりますね。つまり，図3に挙げたそれぞれの作業を確実にこなすことで，テストをマネージメントすることができるのです＊4。では，図3の各プロセスで行う作業（アクティビティ）をそれぞれ詳しく見ていきましょう。
効率のよいテストは優れたテスト戦略/設計から　まず開発プロジェクトにおけるテストの位置付けとして，最初に考えることが「テスト戦略」です。
テスト戦略　「ユーザーの使用頻度が高い部分を中心にテストする」「変更部分を中心にテストする」「すべてのテスト要件を確実にテストする」「イテレィティブな開発に合わせて繰り返しテストを行う」などのように，目指すべき品質に対するテストの方向性を決めます。
テスト分析（テスト対象，品質リスク）　続いて重要なのが「テスト分析」です。作業は大きく分けて二つあります。一つは「テスト対象の分析」です。テストするシステムやソフトウエアの要件や設計を理解して，テストの対象になるテスト要件を洗い出す作業を指します。
　もう一つが「品質リスクの分析」です。これはテスト分析でわかったテスト対象の全体から，テストをどの程度行うか強弱を付ける作業です。本来ならテストすべき部分をすべて完璧にテストすることが理想ですが，現実には，時間的/経済的な制約からすべてをテストすることはできないでしょう。そんなときに，限られた時間と費用で最も価値のあるテストを実施できるように，力を入れてテストする部分と力を抜く部分を選別するわけです。これは医療における「トリアージ＊5」と同じ考え方です。では，テストに力を入れるべきか入れないかを判断する基準はどうすればいいのでしょうか。その基準が「品質リスク」になります。
　品質リスクとは，「その機能が正しく動かないことによって受ける（かもしれない）損害」のことを指します。品質リスクを考える場合は，重要な機能が動かないほどユーザーの損害が大きくなるため，ユーザーが重要視している度合いと，ソフトウエアの修正コストが大きくなるため技術的に困難な度合いの二つの面からとらえるのが良いでしょう。
　このように，テストを品質リスクの軽減策の一つだと位置付け，テストの仕方を決めていくことをリスク・ベース・テストと呼びます。ここでいう“リスク”は，プロジェクト・マネジメントの文献などに出てくる「プロジェクト計画上のリスク」とは少し考え方が異なるので，混乱しないようにしてください。
テスト計画　「テスト計画」では，図3のテスト計画の矢印より後の作業をどう行うかを決めていきます。肝になることは二つあります。
　まず一つ目が，「テスト戦略」と「テスト分析」を元にアプローチの方法を考えることです。どのようなテスト・レベル（単体，結合，システムなど）を誰が行うのか，また，どのようなテストのタイプ（ホワイトボックス・テスト，機能テスト，パフォーマンス・テスト，構成テストなど）をどのテスト・レベルで適用するのかを決めます。どんな技法で設計して，「テスト実施」を自動化するかどうか，また設計レビューやコード・レビューなどの方法も決めていきます（表1[拡大表示]）。　もう一つは，日程計画の中で「テスト・サイクル」をどう回していくかを決めることです。それには，
・いかにして効率よくテストを進めることができるか
・いかにして早く不具合を見つけることができるか
の2点を念頭においておくべきでしょう。
　テスト・サイクルは，テスト設計で作ったたくさんのテスト・ケースをどういう順番でテストしていけば，早く多くテストしていけるかを組み立てる作業です。品質目標が違えばテスト・サイクル数は変わりますし，テスト担当のスキル，テスト環境の充実具合，開発チームの体制（修正リリースがどの程度のスパンで行えるのか）によっても変わってきます＊6。
テスト設計　テスト設計は，「どうやってテストするか」を考える作業です。テスト戦略，テスト分析，テストのアプローチを元にテスト・ケースを作成していきます。具体的なテスト設計の方法は，前回解説したので割愛します。
テスト・ベース・レビュー　テスト・ベース・レビューについても前回触れていますので細かくは書きませんが，テスト実施前にテスト・ベース・レビューを行い，開発へフィードバックしてバグを予防することが，テストを効率的に行うためにとても大切な作業になります。
テスト環境/テスト・データ準備　テスト設計が終わると，テスト環境の構築，自動テスト・スクリプトの用意，テスト・データの用意，日程計画の作成，テストを実施するメンバーへの事前教育など，テストを実施する前に多くの準備があります。また，テストを効率良く行うためのインフラになる部分の準備をして，テスト実施中の“つまらない”手戻りを少なくすることも重要です。
　例えば，テスト・ケースの実施状況を把握し，見直すべきテスト・ケースを検索できるように，テスト・ケースを管理する必要があります。そうでないと，テストの状況が見えなくなって，テストを確実に実施できなくなってしまうからです。テスト・ケースの管理には専用のツールを使うと効率的です。代表的な支援ツールとして，Test Case Manager（http://www.pb-sys.com/），e-Manager Enterprise（エンピレックス，http://www.empirix.co.jp/），Mercury Quality Center（マーキュリー・インタラクティブ・ジャパン，http://www.mercury.com/jp/）などが挙げられるでしょう。
　どのビルドでどこまでテストしたのかバージョンを管理する構成管理も必要です。構成管理を支援するツールとしては，CVS（https://www.cvshome.org/）が有名ですね。
　また，コードができてからテスト開始までの作業を効率化させる仕組みも重要です＊7。Bugzilla（http://bugzilla.mozilla.gr.jp/）などのバグ・トラッキング・ツールを使い，テストで見つけたバグがどうなったのかを一目瞭然にしておくことも必要でしょう。また，テスト結果の分析（後述）のため，メトリクス用データ収集の仕組みをこれらのインフラに埋め込んでおくと，データ収集の効率が向上します。
　これらの作業をきちんと全部やろうとすると，とても面倒に感じられるかもしれません。しかし，だからこそツールをうまく活用してインフラを準備しておくことが重要なのです。
テスト結果の適切なレポートが
品質向上のカギを握る　テスト対象のプログラムがそろって，それらをテスト環境にインストールすると，テストの開始となります。
テスト実施　「テスト実施」のプロセスでは，テスト・ケースを日程計画に沿って実施して，結果（OK/NG）を記載していきます。NGの場合は不具合レポートを記載し，修正要求を出します。テストを行ったログ（結果）は，確実に残していかなければいけません。テスト結果こそがテストの成果物だからです。どのようなデータを使ったのか，どのようなテスト環境で動作させているのか，どのような手順で行ったかなどの情報は，もう一度同じテストを再現できるように十分な内容を残すようにします。不具合が出たときに再現できないと，開発者が修正するのが困難になりますし，テスト担当としても修正されたプログラムを再度確認する手段がなくなってしまい，手戻り工数がどんどん増えていきます。結果を確実に残すことが，無駄な手戻り工数を増やさないコツだということです。
　また，テスト・ケースを追加，修正することもあるでしょう。テストをしているとテスト対象のシステムへの理解が深まってくるので，テスト・ケースを追加したくなるものです。その場合も，追加したテストが実施結果として必ず残るようにしておきましょう。
バグの追跡　「バグの追跡」は，ソフトウエア・テストが情報サービスとして有益な情報を流すために最も大事なアクティビティです。バグ追跡は，バグの検出からバグ・レポート（図4[拡大表示]）の起票とプログラム修正結果の確認までを指します。
　前述したようにバグ・レポートはテストの成果物です。開発にバグ・レポートを提出することで，バグを取り除くことができるのです。問題になった現象を正しく再現できるように調査したうえで，開発担当がわかりやすいように記載するようにしましょう。バグの対応が適切か，バグの修正が怠っていないかなどを確認するのもテストの重要な仕事です。また，バグ・レポートの件数は品質を測定する指標として使うことができますし，バグの内容を分析し，その傾向をフィードバックすれば，長期的なバグの予防にもつながります。
　つまり，バグ・レポートをうまく使う仕組みを確立して運用できるようにすることは，テストの命だといっても過言ではありません＊8。
テスト結果評価・報告　「テスト結果評価・報告」は，テストの本来の目的“ソフトウエアの品質を測定して改善する”ための情報を，開発メンバー，マネージャ，経営層に流すための作業です。大きく分けると，
・リリース（納品）のための判断材料の提供
・今後の改善のための材料の提供
の二つがあります。
リリース（納品）のための判断材料の提供とは，言い換えると「テストを終了してよいかどうかの判断材料の提供」です。計画したテストをどの程度実施したか，仕様変更が入った部分のテストを実施しているか，バグの発見件数は減ってきているか（バグの収束状況），バグの対応はどこまで済んでいるか，制限事項にしたバグについて課題はないかなどの様々な判断条件を使って，テストを終了してよいかを判断します。この判断はマネージャや経営者が行いますが，誤った判断をしないためにもテスト結果を元にした判断材料が重要になってきます。
　今後の改善のための材料の提供は，開発にかかわったメンバーで行う事後レビューの場で行います。バグを分析してレポートすることで，バグの傾向がノウハウとして蓄積していくようになり，開発チームはノウハウを元に“間違えないように作る”ようになれるでしょう。また，テスト担当は“間違えそうなところを先にテストする”ようにもなれます。テストをなくすことはできませんが，バグを予防するためのノウハウを共有することで，バグによる手戻りの工数が減り，“狙った工数以内に収める”ことが可能になるわけです。

bgx5810

テストのマネージメントとレポート
テスト結果の分析/報告にはグラフを駆使しよう　さて，ここまでテスト結果の適切な報告が品質向上に重要だと繰り返し説明してきました。では具体的にどのようにレポートすればいいでしょうか？ ダラダラと文章ばかり書いても開発者やマネージャは読んでくれないかもしれません。
　そこで最後に，ソフトウエア・テストが情報サービスとして有益な情報を流すためのメトリクス（指標）の例ををいくつか紹介しましょう。
品質把握：リリースのための判断材料の提供      

[size=-2]図5●バグのオープン・クローズ・チャートのサンプル [size=-3][画像のクリックで拡大表示]

[size=-2]図6●バグ検出件数の予測グラフのサンプル [size=-3][画像のクリックで拡大表示]

[size=-2]図7●工程別にバグ発生原因を表したグラフのサンプル [size=-3][画像のクリックで拡大表示]

[size=-2]図8●欠陥除去効率（DRE）のグラフのサンプル [size=-3][画像のクリックで拡大表示]

[size=-2]図9●DREの計算方法 [size=-3][画像のクリックで拡大表示]

　品質を把握するためのグラフとしては，図5[拡大表示]のようなバグのオープン・クローズ・チャートが挙げられます。バグ検出数，未対応バグ数，対応バグ数の累計と，テスト・ケースの残数（実施件数）を時系列に折れ線グラフにしたものです。
　このグラフからは多くのことが読み取れます。まず，バグ・レポートで指摘したバグが，どこまで対応されているのかがわかります。バグが直っていなければ納品はできませんから，とても重要な判断材料となります。また，バグの累計数の曲線がなだらかになっていくことでバグの発生が収束し，品質が安定していることを確認できます＊9。
　また，テスト・ケースの残数を同じグラフ内に別軸でグラフにすることで，テストの進ちょく状況も把握できます。バグの曲線がなだらかになっていても，テストの残数が減っていかない場合は，ただテストをしていないだけで，バグが収束したとはいえません＊10。このようにバグの件数とテストの残数を一緒に見ることで，バグの収束状況をより正確に把握することができるわけです。
　また，図6[拡大表示]のような回帰分析の計算値によってバグ検出件数を予測する方法もあります＊11。ただ，これだけで品質がいい，悪いを決めつけるのはよくありません。あくまで判断材料の一つであり，テストを実施するなかで気付いた具体的なバグの状況やテスト実施の状況を加味して判断するのがよいでしょう。
原因分析：今後の改善のための材料の提供　開発力を向上させるための情報としては，図7[拡大表示]の工程別の原因種類グラフを作成するのが有効です。要件定義，設計，コーディングのどの工程で何が原因で混入したバグが多いか，その傾向をつかむことができます。
　図の見方を説明しましょう。凡例の「過剰」というのは，勝手な解釈で仕様を決めてしまい追加した機能のことです。設計やコーディングの工程で多いことがわかります。「欠如」は，考慮されていない機能，漏れている機能です。これは圧倒的に要件定義の段階で多く発生していますね。「理解不足」は，スキル不足，環境/ツールについての調査不足など知識が足りないこと，「単純ミス」は，文字通りタイプミスや記述ミス，「手順ミス」は，構成管理やデータ作成の失敗などです。工程が進むにつれて，理解不足や単純ミスが原因となるバグが増えていくこともわかるでしょう。
　テストの効果を把握するための指標としては，欠陥除去効率（Defect Removal Efficiency）という指標があります（図8[拡大表示]）。納品前と納品後に出たバグ検出件数との合計から，各テストのレベルで見つけることができたバグの割合を算出します。これを，各工程ならびにテスト全体で，どれだけバグを見つけることができたかをグラフにしたものです。この結果から，テストの組み立て方の改善につなげることができるというわけです。DREの計算方法は図9[拡大表示]を参照してください。
　DREのグラフを作るには，納品後のバグの状況もきちんと調査する必要があります。そのため，バグの調査を納品後も継続する必要があるという難しさはありますが，テストの効果を見るにはとても役立ちます。調査可能な環境にある方は，ぜひ作成してみてください。
さて，6回にわたってソフトウエア・テストの基礎を解説してきましたが，いかがだったでしょうか？
　テストは，テスト技術を使って効率良く効果的に行い，開発力向上のための情報サービスとして機能してこそ価値があります。本稿では基礎の部分しか説明できていませんが，最近はソフトウエア・テストに関する書籍，雑誌，シンポジウムなど情報を入手する機会も増えてきています。ぜひ，それらを活用し，ユーザーに喜ばれるソフトウエア作りができるように，開発力を向上させてください！

duruo