テスト計画・不具合やバグは分類の仕方と記録する項目を決めて置く
テスト計画では不具合やバグの分類の仕方と記録に残す項目を具体的に書いておく
テスト計画書には不具合の分類の仕方やバグの管理方法についても書いておく必要があります。不具合とバグは混同し易いですが、不具合はテストで見つかった問題点でバグは不具合のうちソースコードの間違いで起きるものと分類すると判り易いです。
ソフトのテストをすれば不具合やバグが見つかります、この記事では不具合とは装置や機器を使う時の問題点を指しバグは不具合の原因になるソフトの間違いを指す事としています。もう少し具体的に言うと、ソフトのバグやテスト手順の間違いなどが原因で起きる装置や機器の動作の問題点は全て不具合で、不具合の中でもソフト設計のミスやコーディングのミスが原因でおきるソフトの間違いがバグです。バグは不具合の中の具体的な１項目です。
この不具合の分類の仕方やバグの管理方法はテスト計画の時点で具体的に決めておく必要があります。複数のソフトエンジニアとテストエンジニアが参加する開発プロジェクトでは、テストで見つけたバグの情報共有と管理のためにバグトラッキングシステムやテスト支援ツールを使う事も多いです。これらのシステムやツールはあくまでも道具なの、でそれをうまく使うための決めごとはテスト計画の時点で具体的に決めておきましょう。
テスト設計の時点で不具合やバグの管理のために具体的に決めておく項目は主に以下の様なものになります。
- 不具合の分類（バグ、テスト設様間違い、テスト実施ミス、環境不備 など不具合をどう分類するのか）
- 不具合の記録（不具合の記録では不具合の再現方法と管理情報を漏れなく書く）
- 不具合の記録方法（何かのシステムに入力するのか EXCEL 表に書くのか）
- 状態定義（個々の不具合やバグはどんな状態を遷移して最終的に終了状態に行きつくのか）
- 終了判断（誰がどんな基準で不具合の対応が終了したと判断するのか）
- 優先度付け（不具合やバグの調査や対策の優先度は誰がどうやって決めるのか）
- トラッキング（個々の不具合の状態遷移は誰がどうやって監視して遅れの対策をするのか）
この記事ではまず最初の１から３の項目について紹介します。それではひとつひとつの項目についてもう少し具体的に見ていきましょう。
１．不具合の分類（不具合をどう分類して記録しどんな対応をするのか）
テストを実施した結果、テスト手順書等に書いてある本来得られるはずの正しい結果と違う結果が得られたら、そのテスト項目は不具合として記録します。記録した個々の不具合は原因別に分類して、その不具合がソフトのバグならばソフトの設計・実装チームに引き渡してデバッグして貰わないといけません。このデバッグサイクルを回してソフトのバグを取り除きソフトの品質を良くする事が、テストの大きな目的の一つです。
不具合には以下の（Ａ）から（え）のようにソフトのバグ以外にも幾つかの分類があります。（Ａ）のソフトバグは設計・実装チームに引き継いいでデバッグをしてもらう必要があり、（Ｂ）～ （Ｄ）はテストチームの中で問題点を解消して再テストをする必要があります。また、（Ｅ）のような不具合が見つかった場合には、ソフトの要求仕様を決めている企画部門などに対応をしてもらう必要が出てきます。不具合の分類によってその後の対応を行う部門が変わってくるので、計画書では不具合として扱う問題点の分類を明確にしておきましょう。
（Ａ）ソフトのバグ
ソフトの設計ミスや実装ミスのためにソフトの動作が要求仕様と違っている。例えば、Ｃ＝Ａ＋Ｂという計算式の要求仕様に対してＣ＝Ａ＋Ａというソフトの設計ミスや実装ミスのために、計算結果が違っているのは、ソフトのバグです。
（Ｂ）テスト設計の間違い
テスト設計にミスがあり間違ったテスト結果の判断をしている。例えば、Ｃ＝Ａ＋Ｂという計算式のテスト仕様としてＡ＝１、Ｂ＝２の入力に対してＣ＝５という結果が出る事を確認する、というようにテスト結果の判定方法を間違えているのはテスト設計の間違いです。
（Ｃ）テスト実施のミス
テスト設計は正しいが、テストを実施する時に間違えてしまっている。例えば、Ｃ＝Ａ＋Ｂという計算式のテスト仕様としてＡ＝１、Ｂ＝２の入力に対してＣ＝３という結果が出る事を確認する、というテスト手順に対して、Ａ＝０と入力を間違えてしまい、Ｃ＝２という結果が出たので不具合として記録していたとすると、これはテスト実施のミスです。
（Ｄ）テスト環境不備
テストに使う環境に問題があってテスト結果が間違えている。例えば、通信のテストの時に使う通信用ケーブルのコネクタが接触不良で、そのためにテストで行った通信がエラーになったので不具合として記録して、というのはテスト環境の不備です。
（Ｅ）要求仕様の妥当性に問題あり
ソフトの要求仕様が一般的な常識に照らし合わせて問題があるために、テスト結果が不具合になっている。例えば、Ｃ＝Ａ＋Ｂという計算式のテスト仕様としてＡ＝１、Ｂ＝２の入力に対してＣ＝３という結果が出るまでに１分以上かかる。要求仕様上は応答性は２分以内となっているので仕様を満たしてはいるが、一般的には１分以上待たされると故障と誤認される可能性が高い。このような場合、テストの目的が妥当性確認の場合には、テスト結果は不具合と記録して、その理由は要求仕様の妥当性の問題です。
２．不具合の記録（不具合の管理情報をと再現方法を漏れなく書いておくか）
不具合の記録として最も大切な情報は不具合の再現方法です。特に不具合がソフトのバグの場合には、そのバグをソフトの設計・実装チームの担当者が再現して調査・対策を進めないと不具合が解消されません。不具合が再現できないと調査も対策もできないので、確実に再現できるだけの情報が具体的に記録されている事がとても大切になってきます。
バグや不具合が再現できれば調査や対策を進める事になるので、その不具合を管理するための管理情報も重要になってきます。では不具合の管理情報や再現方法についての情報にはどんな項目があるのでしょうか、グータラ親父が良く見ていた不具合記録をサンプル例として、順番に見てきましょう。
まずは不具合の管理情報についての項目です
(1) 不具合のID番号：その不具合を一意に識別するためのID番号は必須です、バグトラッキングシステムを使っていれば自動で不要されます
(2) 不具合のタイトル：ID番号では何の不具合か判らないので不具合の内容が判り易いタイトルも必要です
(3) 発生ソフト：不具合を検出した時のテスト対象ソフトを一意に識別できる詳細なバージョン番号等の情報が必須です
(4) 不具合事象：テストの結果としてどんな想定外の結果が得られたので不具合と判定したのか、でいるだけ詳細で具体的な事象が必要です
(5) 不具合状態：その不具合が再現待ちなのか調査中なのか修正中なのか、どんな状態にあるかの項目は管理情報として必須です
(6) 担当者：不具合について現時点で担当しているエンジニアの名前は、特定のエンジニアへ作業の集中の判定や管理に必要です
(7) 影響範囲：不具合がバグの場合にはバグが潜在するソフトのバージョンが対策の適用範囲の決定に必要になります（原因判明の後で書きます）
(8) 対策の適用範囲：不具合がバグの場合には、バグ修正を行うソフトのバージョンの記録も必要です（場合によっては計画と実績）
次に不具合の再現方法についての項目です
(7) テストID番号：どのテスト設計書のどのID番号のテストで不具合が見つかったのか、これが不具合再現のための基本情報です
(8) テスト環境：ターゲットハードのSER.番号や使ったサーバや周辺機器や通信ケーブルの個体識別番号もできる限り記録します
(9) テストデータ：不具合を発見した時のテストに使ってたテストデータは機器の設定や通信データ等、できるだけ具体的に記録します
(10) テスト担当者：記録だけからでは不具合が再現できな時、誰に再現の状況を聞けば良いのかを記録しておきます
(11) 再現状況：再現に成功しているのか未再現なのか何回かに１回は再現できるのか、これまでの再現試行の結果を記録します。
不具合の記録としてはこれらの他にもいろいろな項目が必要になりますが、基本的には上記のような項目があればまずは不具合の調査・対策を円滑に進める事ができると思います。
３．不具合の記録方法（システムに入力するのかＥＸＣＥＬに書くのか）
テストで不具合が見つかったら、その後の対応を行うチームや担当者に不具合を引き継ぐために、不具合の内容を記録します。この不具合の記録がテストにとって一番重要な成果物で、その後多くの担当者がその記録内容を元にいろいろな作業を進めていきます。ですので、不具合の内容をどんな方法で記録して関係する担当者と共有するのかは、テスト計画の時点で具体的に決めておく必要があります。
不具合の記録方法として一番よく使うのは、バグトラッキングシステムのような管理システムです。オープンソース系では、Bugzilla、Mantis、Redmine 等が有名どころですね、他にも有償版の物も各社から出ています。オープンソース系でも有償版でも、バグトラッキングシステムを使いこなすには様々な定義や設定が必要になるので、初めて導入する時は若干壁が高いです。しかし一旦導入してしまえばそのメリットは大きいので、特に10人以上のチームでソフト開発やテストをする場合や、複数の拠点に分かれてソフト開発やテストを行う場合には、バグトラッキングシステムの導入を推奨します。
バグトラッキングシステムを使わない場合によく使うのは、EXCEL で作ったバグリストと呼ぶ一覧表による記録です。１つの不具合EXCEL の１行に記録する事にして、表の横方向には不具合のID番号、不具合のタイトル、発生したテスト項目番号、不具合の内容、現在の状態（ステータス）、など必要な項目を並べた表の使い方が一般的です。このバグリストを、設計者やテスト担当者がアクセスできるサーバ等において関係者で共有して、不具合情報を共有します。この場合、同時書き込みによる書き壊しを起こさないように、EXCEL の共有機能等をうまく使った運用方法を担当者全員がしっかりと守るように注意しましょう。
不具合やバグの管理やトラッキングには状態の定義が必要です
テストで発見した不具合やバグの情報を記録したら、次は原因の調査や対策の実施が始まります。これらの作業を管理する上で大切なのは、不具合の状態の定義や、不具合やバグの対応の終了を判定する方法です。次の記事ではこれらの事につてい紹介します。