試験工程管理の概論

SI業界では、開発に関する知識や経験が不十分なメンバーを試験工程の管理者として任命することが少なくありません。
本来であれば、応用情報処理技術者試験(最低でも基本情報処理技術者試験)に相当する知識、及びその知識を実務で使った経験を備えた者を管理者として任命するべきだと思うのですが、そうすることができない事情もあると思います。

そこで、今回の記事では試験工程の管理に必要な知識の概要を書いていきます。
現場毎で試験の進め方が微妙に異なりますので、現場の進め方に適宜合わせていただければと思います。

なお、当記事では、ウォーターフォール(要件定義→設計→製造→試験→リリース、という順番に沿って、数ヶ月~数年の大規模な開発プロジェクトを予定通りに進める開発手法)を前提とします。
アジャイル(要件をこまめに取り入れながら、1週間~数週間毎に小規模なリリースを繰り返す開発手法)の場合は、各々の開発者が試験に関しても自主的にコントロールする形になるので少し違う話になります。
(しかし、アジャイルのプロジェクトに関わる場合も、ウォーターフォールのプロジェクトで培った試験管理に関する知見を活かすことはできます)

【試験工程の分類】

試験工程はいくつかの工程(段階)に分かれます。
具体的には以下のように分かれます。

・単体試験(単体テスト、ユニットテスト、UT)

単独のプログラムを対象とした試験。
この工程では、プログラムの開発者自らが試験を行うことが多い。
あるプログラムから別のプログラムを呼び出すことがあるが、どちらかのプログラムが未完成の場合は「スタブ」や「ドライバ」といった仮のプログラムが使用される。
「スタブ」は呼び出し先のプログラムに相当する仮のプログラムであり、「ドライバ」は呼び出し元のプログラムに相当する仮のプログラムである。
試験で使用される仮のプログラムについては、比較的新し目の技術を使う現場では「モック」(完成品のような見た目に見せかけた仮のプログラム)と呼ばれることも多い。

・結合試験(結合テスト、IT)

あるプログラムから別のプログラムへの呼び出しの箇所の担保を取ることに着目した試験。
単体試験の延長線上のような体制で行われることもあれば、専任のテストチームが試験を実施することもある。

・総合試験(総合テスト、システムテスト、ST)

プログラム等の改修を行ったシステムについて、システム全体の挙動を確認する試験。
人数の少ないプロジェクトである場合や技術的なサポートが必要な場合は開発者が試験実施に携わる場合もあるが、原則としては専任のテストチームが試験を実施する。
他システムとの連携についても、この段階で行う。

・受入試験(運用テスト、UAT)

改修後のシステムについて、実運用上の問題がないかを確認する試験。
システムの実際の利用者が試験を実施するが、利用者が一般ユーザー(エンドユーザー)である場合、受入側の会社の社員が代わりに試験を行う場合が多い。

それぞれの試験の工程がウォーターフォールのプロセスの中でどのような立ち位置にあるのかは別の記事(ウォーターフォールモデルとV字モデル)に投稿していますので、よろしければそちらもご参照ください。

【試験工程のスケジュール】

それぞれの試験の工程では、一般的に以下のような順番で作業が行われます。
(いくつかの作業は省略される場合があります)

試験の計画の策定

試験項目の作成

試験の準備の実施(テストデータやテスト環境やテスト用プログラムの作成)

試験の実施とバグ対応(バグが頻出する場合はこの時点で品質強化を行う場合がある)

上長への試験結果の報告(試験の一部再実施や品質強化を指示される場合がある)

それぞれの作業については、プロジェクト初期の見積もり段階で
「どのような役割の人を何人投入して、いつからいつまで作業を行うのか」
という計画が原則として立っています。
この計画については、それぞれの作業についての工数を積み上げて計画が立てられている場合もあれば、全体の工数を見積もった後に「単体試験は全体の20%、結合試験は全体の15%…」といった形で概略的に立てられている場合もあります。
見積もりと計画についての詳細は、別の記事(「見積もり概論」社内勉強会用のパワポの公開)に投稿しています。
また、
「どのプログラムについてどのようなテストが必要か。そのためにどのような準備を行うのか。」
といった細かいことについては、各々の試験工程の序盤で行うことが多いですが、これは開発に携わっているメンバーでないと実施困難であり、必要となる知識も広範かつ各々のプロジェクトに寄る所も大きいので、この記事では詳細は書けません。
試験の準備の実施、その他バグ対応や品質強化の実作用についても同様に、開発に携わっているメンバーでないと実施困難な作業になります。

試験項目の作成方法については、いくつかのテクニックがあります。
キーワードだけ書いておくと、「ホワイトボックステスト/ブラックボックステスト」「デシジョンテーブル」といったテクニックが使われます。
(詳しくは、情報処理技術者試験の情報を参考にするのが良いと思います)
なお、試験項目を挙げ終わったら、試験の項目数を集計し、総件数/着手件数/完了件数を把握できるようにするべきです。
これは、試験工程の進捗を確認する上で必要になる情報の一つになります。

予定通りの試験実施を妨げる最も典型的な問題の一つとして
「特定のプログラムでバグが頻発し、そのことが原因で関連するプログラムの試験項目を消化できない」
という問題があります。
この問題の対処のために
「バグが頻発するプログラムについて追加レビューや追加テストを集中的に実施し、バグを見つけきって、見つかった全てのバグを直して、元の作業に戻る」
という追加作業を実施する場合があります。
この作業は、「品質強化」と呼ばれることが多いです。
品質強化については、別の記事(類似バグを効率的に見つけ出すための観点)に詳しくテクニックを紹介しています。

【バグ管理表の運用】

それぞれの試験工程では、試験で見つかったバグを一覧にして管理するためのバグ管理表(不具合管理表、障害管理表)を用います。
バグ管理表はExcel若しくはスプレッドシートで作成されることが多く、フォーマットのイメージについてはWEBで調べることができます(例:「バグ管理表」でGoogleでイメージ検索)。
プロジェクトによっては、BacklogやJiraといったチケット管理ツールが用いられる場合もあります。

バグ管理表には、一般的に、以下のような項目が含まれます。
それぞれの項目について、管理者が着目するべきポイントも合わせて説明していきます。

・通番、タイトル

見つかったバグを一意に特定するための情報です。
報告書上や会議の場でも、「『No.3 ○○システムで作成したユーザーでログインできない』の対応状況に関しましては…」といった書き方/言い方をするので、通番と完結なタイトルがあると便利です。

・発生日

バグが発見された日を記入します。
詳しくは後述しますが、試験工程の進捗を確認する一つの方法として、バグが何件発見されたのかを日毎に確認する、というものがあります。
その際に必要となる情報になります。

・ステータス

それぞれのバグについて、対応が現在どの段階にあるのかを記入します。
順番に書くと、最低限「起票」「原因調査中」「バグ修正中」「修正確認中」「対応完了」といった段階に分ける必要があるでしょう。
試験工程が予定通りに進んでいない場合、ステータスからどこがボトルネックになっているのかを掴める場合があります。
例えば、「起票」「原因調査中」「バグ修正中」で止まっているバグが多ければ、バグが多すぎて開発者の手が回っていないことが予想されますし、「修正確認中」で止まっているバグが多ければ試験担当者の手が回っていないことが予想されます。
どこがボトルネックになっているかで対策も変化します。例えば、開発者の手が回っていない状況で試験担当者を増やすことだけしても意味がありません(開発者が抱えている作業の一部を試験担当者に回す、という手を併用するなら意味があります)。
なお、バグではない事象が書き込まれたり、一つのバグが複数個所に重複されて起票されたりする場合もあるので、それを示すためのステータス(「バグではない」「重複起票」等)も必要でしょう。
詳しくは後述しますが、試験工程毎で見つけるべきバグ数を計測する場合があります。
その際に、バグとしてカウントする必要がないものは計測対象外とする必要があります。

・バグ内容

バグの内容やバグを発生させる手順を記入します。
ここを参照するのは基本的にバグを修正する開発者ですが、品質強化策を考えるヒントを得るための情報の一つにもなり得ます(ここからヒントを得るためには、開発に関する知見が必要になる場合があります)。

・原因、修正方法、対象プログラム

バグの原因や修正方法、修正する必要があるプログラム名、といった、バグ修正に必要な情報を記入します。
単純なバグであれば試験担当者が記入できる場合もありますが、基本的にはバグを修正する開発者が記入する項目であり、開発者のための項目でもあります。
この項目も、品質強化策を考えるヒントを得るための情報の一つになり得ます。
特に、対象プログラムについては、開発に関する知見が無くとも機械的に数を集計できる項目であるため、品質強化が必要なプログラムを特定する上で有用な項目になります。

・バグ修正予定日、完了予定日

開発者によるバグの修正が完了する予定日、及び試験担当者による修正確認が完了する予定日を記入します。
この項目は進捗管理に使用することができ、上がってきたバグの対応が試験期間内に終わるかどうかを確認することができます。
試験期間終了日が近づいてくればくるほど重要な意味を持ってくる項目です。

・発見するべき工程

そのバグがどの工程で発見するべきだったのか、ということを記入する項目です。
例えば、現在が総合試験工程である場合、システム内の修正対象外のプログラムとの連関で発生したバグなら「総合試験工程で見つけるべきバグ」となりますが、プログラム内の単純なロジックのミス(製造ミス、修正ミス)で発生したバグであれば「単体試験工程で見つけるべきバグ」となります。
これは、品質強化策を考える上で重要な項目になります。
ウォーターフォールでは「前工程が完全に終わってから次工程に進む」というのが前提となっており、この前提が崩れている場合、現工程の作業が前工程の問題により進めることができなくなり、予定通りに作業を完了させることができなくなります。
もし、前工程で発見するべきバグが多ければ、この前提が崩れているということになりますし、この前提が崩れているプログラムについては品質強化が必要となります。
これは私見ですが、目安として、前工程で発見するべきバグが全体の20~30%程度であれば品質強化を検討、50%を超えたら品質強化が必須、と考えて良いと思います。
現場によっては、品質強化を行うべきラインが計測・策定されている場合もあるので、そのような数字が現場あればその数字に従うべきです。

【バグの発生数と進捗の関係】

バグの発生数を見ることでも試験の進捗を見ることができますが、これには少々コツが必要です。
一般的には、一定のペースでバグの発生数し続けるということはなく、試験実施の初期はバグが発生しにくく、中期にバグが多量発生し、後期にバグの発生が少なくなる、という経緯を辿ります。

試験手順が確立していないため、バグがなかなか見つからない

試験手順が確立したため、順調にバグが見つかる

品質が向上し残りの試験項目もレアケースのみとなるため、バグが見つかりにくくなる

という流れに一般的にはなるため、先に挙げたような経緯を辿ることになります。
(これをグラフにして表したものをゴンペルツ曲線(信頼度成長曲線)と呼びます。詳しくは別の記事(ゴンペルツ曲線(信頼度成長曲線)とは)を参照して下さい。)

もし、このような経緯を辿らない場合は、何かしらの問題があることを示しています。

例えば、初期からバグが大量発生している場合や、いつまでもバグが大量発生し続ける場合は、プログラムの品質が悪いことが伺えますので、品質強化を考える必要があります。
逆に、試験手順が確立したのにも関わらずバグが発見されない場合は、テストケースの作り込みが甘いケースが考えられます。

なお、試験工程で見つけるべきバグ数については、現場によっては計測・策定されている場合があります。
そのような数字があれば、それに従ってバグ発生数が多い/少ないを判断すれば良いですが、無い場合は、肌感覚で判断せざるを得ない場合もあります。これには、開発に関する知見や開発経験が必要になります。


試験工程の管理者として任命された他社の若手が、試験工程について私に質問してきたことがあり、その回答として上記の文章を書きました。
質問者にのみこの文章を見せるのはもったいないので、公開に至りました。

境界値テストを行う場合には有効桁数に注意する

境界値テストについては、以前の記事にてデシジョンテーブルと共に紹介しました。
しかし、以前の記事では紹介しきれていないことがあるので、別に記事を書いて紹介しようと思います。


表題の通りなのですが、有効桁数については、コーディング時にも気を付ける必要がありますし、境界値テストを行う際にも気を付ける必要があります。
有効桁数を見誤ると、境界値付近の値が与えられた場合に意図せぬ挙動を示すことがあります。

例えば、株価に応じて処理を変える必要がある場面において、以下のような条件指定をしたとします。

そして、1つ目のif文と2つ目のif文の境界値を見るために、株価が99円・100円・101円・102円のテストケースを用意したとします。

これは一見正しそうに見えるのですが、有効桁数が見落とされており、バグを引き起こすコーディングであり、バグを発見できないテストケースです。
実は株価は1円単位とは限らず、0.1円単位のこともあります。
もし、ここで100.1円という株価が与えられた場合、1つ目のif文も2つ目のif文もすり抜けてしまい、意図せぬ分岐に進んでしまいます。
そして、テストケースでは100円より大きく101円より小さい値が設定されていないので、このバグを見つけ出すことができません。

正しくは、以下のようにコーディングするべきです。

そして、1つ目のif文と2つ目のif文の境界値を見るテストケースとしては、最小桁数での境界を見ることができるように、株価が99.9円・100.0円・100.1円のテストケースを用意するべきです。


いかがでしたでしょうか。

今回紹介した例は、私が本当に目にしたことがあるバグです。
金融案件のように数字を扱う案件では発生しがちなバグだと思うので、有効桁数に気を付ける必要があるということを心に留めておきましょう。

ゴンペルツ曲線(信頼度成長曲線)とは

ゴンペルツ曲線(信頼度成長曲線)とは、テストで発見されるバグ数をグラフにしたものです。
横軸に時間、縦軸に累積バグ数をとる場合、下記のようなグラフになります。

テストを開始した直後は、テスト手順が確立していないため、バグはなかなか見つかりません。
テスト手順が確立した後は、時間が経つにつれて順調にバグが見つかります。
テストが終盤に近づくと、残っているテストケースはテスト困難なレアケースになるので、再びバグを見つけにくくなります。

具体的にいくつのバグが出るかは、プロジェクトの特性によって変化します。
現場毎に、プロジェクトの規模と発見されるバグ数の統計を取り、その統計を元にいくつのバグが出るのかを具体的な数値に落とし込みます。

もし、バグが大量に見つかる(aのケース)ようであれば、テスト開始時点の品質が悪い疑いがあります。
この場合、品質管理者は、バグの原因を確認し、前工程で見つけるべきバグが大量に見つかっていないかどうかを見る必要があります。
前工程で見つけるべきバグが大量に発見された場合は、バグの対応でテストの進捗が悪くなることを防ぐために、もう一度前工程に戻って品質強化を行う必要があります。

また、発見されるバグが少ない(bのケース)ようであれば、テストケースの作り込みが甘い疑いがあります。
この場合、品質管理者は、テストに使われているテストケースを確認し、テストの目的に照らし合わせてテストケースの網羅性が十分かを見る必要があります。
テストケースの網羅性が不十分な場合は、現在のテスト工程で見つけるべきバグが見つからないことにより次工程やリリース後に悪影響を及ぼすのを防ぐため、テストケースの修正を指示する必要があります。

品質管理者には成果物の一つ一つを細かく見る程の時間はないため、上記のような数値管理を行い、プロジェクトの状況を把握しようとします。
(人間の体に例えると、健康診断で数値を出し、疑わしい数値が出た場合に医師が検査を行う、という例えになります)
そのため、作業者としては、正直に数値を出すことで、品質管理者が適切に管理を行えるようにする必要があります。


あけましておめでとうございます!

昨年、何のためにバグ数を報告する必要があるのかと問われたので、今回の記事を執筆しました。
作業者目線では報告はうんざりするかもしれませんが、プロジェクトを円滑に進めるためだということを知っていれば、頑張って報告する気になれると思います。

実は昨年は適当に報告してしまっていた…という方、新年は是非報告も頑張ってみましょう!

現新比較の方法

情報処理技術者試験では出題されないのですが、IT技術者として当然知っておくべきテスト手法として「現新比較」というものがあります。
これは、システムを改修した際に思わぬ箇所に影響が出ていないことを確認する(無影響確認)ための手法であり、改修前の出力と改修後の出力を比較し、改修の影響を受けるべき箇所以外は差異がないことを確認する、というものです。

この手法は単体テストからリリース後の確認まで工程を問わず使用される手法です。
例えば、プログラムを製造する場面で、「販売情報管理システムの取引ファイル出力プログラムについて、ポイント払いのレコード(ポイント払いされた場合)にポイントの有効期限を更新するように改修する。それ以外の箇所は変更しない。」という改修を行った場合、単体テストでは「ポイント払いのレコードはポイントの有効期限以外は現新で差異が無いこと」「ポイント払い以外のレコードは現新で差異が無いこと」を検証するべきです。

直すべきところだけ直したつもりなのに、知らず知らずの内に他の箇所にも影響していたというのは意外とよくあります。
現新比較を行わないと、本来見つかるはずのバグが見つからず、後でバグが見つかることになってしまいます。
システム開発に慣れ始めた頃が危ないです。「この改修で他に影響するわけないだろう」と思わず、現新比較はしっかり行うようにして下さい。

現新比較の具体的な方法としては、以下のようなものがあります。

1.ファイル・テーブル・電文のレコード等、出力が文字列の場合

・WindowsのfcコマンドやLinuxのdiffコマンド

完全一致する場合等、ごく簡単な場合に。

・WinMerge等の差異比較用のソフトウェア

1レコードの内の一部が異なっている場合がある等、少し複雑な場合に。

・Excelやjava等で作成した独自ツール

複雑なデータ加工が必要な場合に。
改行コード付与や一部項目除外等で済むなら、Linuxのfoldコマンドやcutコマンド等を組み合わせるだけでも十分です。

2.Windowsで生成した帳票・ハガキ等、出力がPDFファイルの場合

・2つのPDFファイルを開き、画面を切り替えて目視

アナログですが、簡単な比較なら結局これが一番早いです。

・AdobeAcrobatやDiffPDF等のPDF比較用のソフトウェア

大量のPDFファイルを機械的に比較する必要があるなら必要です。

3.Web画面のキャプチャ等、出力が画像の場合

・2つの画像を異なるファイルの同じ個所に張り付け、画面を切り替えて目視

アナログですが、簡単な比較なら結局これが一番早いです。

・ImageMagick等の画像比較用のソフトウェア

ソフトウェアを導入することで、流行りの自動化も可能になります。

4.プリンターで出力した帳票やハガキ等、出力が紙媒体の場合

・出力された紙を重ねて透かして目視

アナログですが、これしか手段がない気がします。


いかがでしたでしょうか。

現新比較について研修という形で座学で教わることは少ないと思いますが、実務では重要になります。
まだ実務で現新比較をあまり行ったことがないのであれば、こういったことを実務では行っているということを知っておいた方がスムーズに仕事に取り掛かれると思います。

次回からも役に立つ情報を提供していきたいと思います!

デシジョンテーブルを使用したテストケース設定

条件分岐が複雑な場合、テストケースの設定に漏れが発生して、テストでバグを洗い出しきれなくなることがあります。
そのような場合は、デシジョンテーブルを書いてテストケースを明示的に洗い出すのが有効になります。

デシジョンテーブルの書き方について、例を挙げて説明していきます。
今回も、在庫管理システムの在庫発注処理の例を使用します。
発注するべき条件(在庫切れ、若しくは人気上昇)を満たしている時に、発注関数を呼び出し、発注量や発注日等を計算するという仕様を想定します。
また、最後の発注日から3日以上経過しないと新たに発注できない、という仕様を想定します。
フローチャートは以下の通りです。

この例の場合、以下のようにデシジョンテーブルを書くと、これらの条件からテストケースを洗い出すことができます。
「入力」欄に条件の組み合わせを、「出力」欄に各々の条件の組み合わせの結果を書きます。

発注経過日のように境界値分析が必要になる箇所は、「境界値以下(代表値2)」「境界値と同じ(3)」「境界値を超える(代表値4)」の3パターンを洗い出した方が良いです。
分岐を網羅するだけであれば「境界値以下」「境界値と同じ」の2パターンのみで十分なのですが、コーディングの誤り(IF文の「≧」を「=」としてしまう誤り)で境界値と同じ場合のみ条件が真になるという実装になってしまっていることがあるため、上記3パターンでテストを行うのが無難です。
(本当にこのような誤りを見たことがあります)

また、今回は12パターンのテストケースを洗い出していますが、テストケースが多すぎてテストする時間が取れない場合は、デシジョンテーブルを見ながら不要なテストパターンを抽出するのが有効となります。
今回の例で言うと、発注経過日が3日未満の場合については、在庫切れフラグや人気上昇フラグが発注有無に関与しないことを確認できれば良いので、テストケース2やテストケース3は削っても問題ないでしょう。発注経過日が3日を超える場合についても、前述のようなコーディング誤りがないことを確認できれば良いので、テストケース10やテストケース11は削っても問題ないと思います。