[STEP3] 開発したシステムをテストしよう！テスト工程を効率よく着実に進めるためのポイント

第3回 テスト工程を効率よく着実に進めるためには

突然ですが、皆さんは「テスト」が好きですか？

学生時代のテストは、勉強した成果を測るためのものでしたが、システム開発におけるテストは、何のためにおこなうのでしょう？

システム開発における「テスト」は、プログラム中の不具合（バグ）やシステムの欠陥を発見するためにおこないます。つまり、システム開発における「テスト」では、できるだけ多くの不具合を発見できるテストが良いテストであるといえます。そして、テストの良し悪しはシステムの品質に大きな影響を与えます。

第1回目は要件定義、第2回目は開発と単体テストについてご紹介いたしました。

最終回である第3回目は、システム開発全体からみた各テスト工程の設計や概要についてご紹介するとともに、テストケースの洗い出し、テストの進捗管理や品質指標、また、要件トレースやBTS（バグトラッキングシステム）活用など、品質向上のための試みについてご紹介します。

・テストの設計はいつやるの？

第1回目の「システム開発の流れを体験してみよう！ システムの要件ってどうやって詰めるの？効率的に要件定義・設計を行う方法」の要件定義の工程で挙がった、いくつかの要件がありました。もう一度、軽く振り返ってみましょう。
ワークにチャレンジされた方は、ご自身の回答も確認してみてください。

要件が正しく実装されているかどうかの確認は、作成された機能を実際に動かして確認、つまりテストをする必要があります。

システム開発における「テスト」には、第2回目で紹介した「ユニットテスト（単体テスト）」以外に「結合テスト」、「システムテスト（総合テスト）」、「受入テスト」などがあります。（テストの種類については、後述）

皆さんは、これらのテストの設計をしたことがありますか？
もし、テストの設計をしたことがある方は、いつ、テストの設計をおこないましたか？

＊W字モデルとは：テスト計画とテスト設計を上流工程に移して、要求定義や設計工程、実装工程と同時に、 テスト設計に関わる作業を実施していく開発モデル。

W字モデルを実践すると、設計書の曖昧性や不確実性を減らすことができます。
例えば、『既存システムよりも使いやすくする』といった非機能要件があった場合、どのようなテストをおこない、どのような結果が出れば合格なのでしょうか？

『500人の利用者にシステムをテストしてもらい、業務Aのプロセスが全員8分以内に完了できれば合格とする』といった具体的なテストケースを作成することで、お客様と開発側の認識のズレをなくすことができます。

そして、W字モデルは、曖昧性や不確実性を減らすだけでなく、早い段階からテスト工数を見積もることができるといったメリットもあります。

例えば、利用者500人に対して、業務Aのプロセスを5回テストする場合と、代表者10人に対して3回テストする場合とでは、テスト結果だけでなく、テストにかかる時間と費用が異なります。

このようにW字モデルは、設計書の不備を早期に発見し、不備を次工程に持ち越すことで生じるバグを少なくしたり、手戻りを未然に防いだりすることができます。

結果として、システム全体の品質の向上や開発工数の削減につながります。

・テストの設計はいつやるの？

では、実際に個々のテストケースを考える場合、どのようにしてテストケースを考えるのでしょうか？テストケースを抽出する手法には、様々な手法があります。

例えば、テストケースを抽出する手法の１つとして、『デシジョンテーブル』と呼ばれる手法があります。

デシジョンテーブルを利用するとテストケースの抜けもれがなく、また、同じようなテストが重複することなくテストケースを抽出することができます。

『デシジョンテーブル』は、複数条件の組み合わせとその結果をまとめたテーブルです。
複数条件を組み合わせて、期待する結果はどうなのかを一覧表で俯瞰することができるので、誰が見てもわかり易くなります。

テーブルは4つの部分で構成されます。

デシジョンテーブルでは、原因(条件)と結果(処理)を分離して記述します。

たとえば、Typeスポーツでは、スポーツ振興目的と製品売上向上のため半期ごとに1か月間の製品セール月間を設定し、その際、以下のような年齢別割引を適用するとします。

「年齢割引」
* 12歳以下(購入者のこども)：20％割引
* 50歳以上の女性：20％割引
* 60歳以上の男性：20％割引

そうすると、下記のようなデシジョンテーブルを作成できます。

凡例）
条件部：
Y：条件が満たされている
N：条件が満たされない
-：条件は無関係、論理的に無い

動作部：
X：実行される
-：実行されない

更に、仕様変更で、以下の条件が追加された場合、図1-3のようなデシジョンテーブルを作成できます。

「女性割引」
* 水曜日は年齢無条件で20％割引！

「社員割引」
* 社員に限り追加割引としてプラス15％割引！

デシジョンテーブルは、単体テスト?受入テストまで使える手法です。

実際には、業務特性上の特殊なルートやマニュアル作業などイレギュラーな処理の観点、業務的に難しく複雑なパターンなど、お客さまの協力を仰ぎながらテストケースを洗い出しましょう。また、他システムとの連携、関連する業務との連動などの観点も必要ですね。

様々な観点や範囲を幅広く網羅できるテストケースを洗い出しながら、最小限のケースでテストができるようにしましょう。

そして、テストケースの抽出だけでなくテストデータの準備も必要ですね。

・テスト工程の全体像とは？

テスト設計のタイミングやテストケースの抽出方法については、先に述べましたがテスト工程でおこなうべき作業は、単にテストケースを作成し実施するだけではありません。

プロジェクトの計画を立てる際に、システム開発の目的・概要、役割や責任などの体制、開発作業により作成される成果物、開発プロセスや管理方法について決めます。

その中で、テスト全体の計画についても同様に決めます。

• ・目的、テスト範囲
• ・テスト実施の体制、実施スケジュール
• ・テスト実施する環境や、使用するツール類
• ・テスト進捗管理の方法
• ・バグ管理と対応方針
• ・品質管理の方法
• ・テストを終了する基準、または納品基準

そして、策定されたテスト計画にもとづき、テスト設計と実行を進めます。
テストケースの実施予実だけを管理するだけではなく、これらすべてを管理することがテスト管理です。

・○○テストって何するの？？

ここからは、皆さんがテストチームのメンバーであった場合、何をする必要があるのかを考えていきましょう！

テストチームにあなたと一緒に参画することになった新人の中村さんは、テスト計画書を見ながら戸惑っているようです。中村さんのギモンに答えながら、テストの定義について考えてみましょう。

中村さん： 先輩?スミマセン。結合テストって何をくっつけるのですか？

あなた： 簡単に言うと、Aという処理を実行するプログラムとBという処理を実行するプログラムのそれぞれの単体テストが終わったら、それらが連携して動く場合、「機能」としてそれらのプログラムが問題なく動くかどうかをテストするのよ。

中村さん： うーん？プログラムが連携して「機能」するっていうのは、顧客情報の登録処理のあと、確認メールが配信される、みたいな感じですか？

あなた： そうね。顧客情報の登録処理をA、確認メールの配信をBと考えると、A⇒Bが連携して正しく動作することを確認する必要があるわね。
そして、機能が正しく動作することを確認するのはもちろんだけど、AとBで受け渡しされるデータが正しいかどうかもテストする必要があるのよ。
さらに、機能面のテストだけでなく非機能面からみたテストも必要よ！ たとえば、性能として、顧客情報の登録処理は3ミリ秒で完了する、とかね！

すると、中村さんは、テスト計画書のスケジュール表を見て悩み始めました。

中村さん： 結合テストフェーズの後に総合テストってありますけど、もしかして、今度はその結合がさらにいろいろとくっつくのですか？！

あなた： そうね。
総合テストは、全プログラムを結合して、システム全体のテストをするの。
実際の「業務どおり」に、システムの各業務処理が正しく動作するかどうかをテストするのよ。
例えば、ある通常営業日「１日」を何サイクルかでテストし続けるとか、締め日だとか月末・月初とかの特殊な日を想定してテストする、なんて感じでね。
会計システムとかでは、年に一度だけ実行されるバッチ処理というのもあるのよ。
そういうものも、忘れずにちゃんとテストしないとね。

中村さん： うわぁー!! 本番の業務ですか・・・
Typeスポーツのサイトにお客様がログインして商品を選ぶ時におススメ情報が表示されて、実際に注文したら、そのあとカートに行って支払の処理をして、その裏ではリアルタイムで在庫管理が動いて商品残量の表示を更新して、顧客情報と連携させてお客様のお好みみたいな履歴を作って、さらに次の販促に結び付けるみたいな感じですか？
すごく、大変ですよね・・・

あなた： そうね、実際の本番業務では複数の業務が並行して動いているから、業務処理はもちろんその裏で動いているデータ連携もチェックする必要があるわね。
また、夜間で一括処理されるようなバッチ処理をテストしたり、非機能要件として、性能、信頼性、運用性、大容量テストなども行ったりする必要があるわね。

上記以外に、『リグレッションテスト』と呼ばれるテストもあります。リグレッションテストは、バグの改修後や仕様変更の対応後に行うテストのことです。
このようにシステム開発では、各工程において予め標準のテスト項目を設けて、日々繰り返しテストをおこなうことで、システムの品質を向上させていくことが大切です。

・バグ「０」が目標？！

テスト計画と管理を担当している佐竹さんが、あなたと中村さんの話している所にやってきました。佐竹さんはテストスケジュールや進捗管理、テスト環境の整備など、テストに関わるすべてをまとめる役割です。
ここでは佐竹さんの話を聞きながら、テスト管理の１つである品質指標について考えてみましょう。

佐竹さん： おー。なになに、テスト工程の勉強をしていたの？

あなた： 佐竹さん、今中村さんと一緒に確認していたら、まだまだわからないところがあるので教えてくださいませんか？

佐竹さん： もちろん！例えば、何がわからない？

中村さん： この「バグ密度」ってなんですか！？

あなた： 「バグ密度」というのは、「バグが製造規模あたりどの程度発生しているか」ということよ。システムを構成する場合業務に沿った単位で機能を構成するけれど、規模はバラバラだから同じ評価ができないでしょ。
だから、指標値を目安として品質の良しあしを判断するために設けられているのよ。

中村さん： なるほど。バグが発生している密度を比較することで、そのシステムの品質の高い、低いが評価できるということですね。

佐竹さん： 今回、規模はファンクションポイント(FP)という方法で算出したけれど、ステップ数(KSLOC)で見ることもあるよ。

あなた： 中村さん、「試験密度」は分かる？

中村さん： ということは、「製造規模あたりどのくらいテストケースこなしたか」ということですよね！

佐竹さん： 正解！実は、試験密度もバグ密度も値をどこに設定するかが、いつも悩みどころでね。これらは、テスト完了基準（いつテストを完了して、次の工程に進むか）や納品の際の品質評価を考える上でも重要。

あなた： 今回はどのようにして決めたのですか？

佐竹さん： 現行システムの開発時の品質状況を、Typeスポーツの菊池さんに教えてもらったけどあくまでもそれは参考ベース。
実際は、今まで、うちの会社が作ってきた他のシステムで、今回と似たような案件の開発時の品質状況をもとに算出するのが現実的だね。
また、許容範囲としては、目標値の±25%で上限・下限を設定したよ。
IPA/SECから出ているソフトウェア開発データ白書なんかには、世の中標準の値も出ているね。一度、目を通してごらん。 （参考：https://www.ipa.go.jp/sec/publish/tn12-002.html）

中村さん ：バグなんてない方がいいから、バグ密度「0」が一番の目標ではないのですか？

あなた ：確かに目標にしたいけれど、単に「バグ0です」なんて報告したら、お客様から「なにそれ、ちゃんとしたテストできているの？！テストしたの？！」って思われちゃうよね。

佐竹さん ：そうだね、まさに目標だね。最終的に納品するときには、バグ「0」になるまでテストして、大小のバグを出し切って、バグを全部解消しました！その状況がこの試験密度とバグ密度です。って、お客様に報告したらわかりやすいよね。

あなた ：つまり、目標値が低すぎても高すぎても問題ってことですね。

中村さん ：なるほど、低すぎたら「ちゃんとテストしているの？バグを出し切ったの？」って思われてしまうし、高すぎたら「元々のプログラムにバグが多すぎるのでは？」って評価されてしまうかもしれないってことですね。

・テストの進捗管理ってどうやるの？

テストの進み具合により、テスト計画が大きく左右されるため、テストスケジュールの管理はとても重要です。
ここでは、佐竹さんの話を聞きながら進捗管理について考えてみましょう。

あなた： テストを進めていって、バグが多すぎて改修が追い付かない！なんてことになった時はどうすれば良いですか？

佐竹さん： 残念ながら、そういう場合は何とか工程をずらすしかないよね。
けど、たとえ工程をずらしても本番稼働日はずらせないから、休日出勤して夜も遅くまで対応…なんてことになってしまうよね。
だから、そうなる前に、効率的なテスト計画とテスト管理が必要ってことだね。

あなた： 中村さん、以下のような「テスト項目の消化状況」を示したバーンダウンチャートと、「バグ検出状況」を示したグラフって見たことあるかしら？

中村さん： はい、あります。

佐竹さん： テストの進捗状況と、バグの発生の収束状況を確認できるツールの１つだね。
そういうツールを利用して、絶えず状況をチェックすることが重要だよ。
テスト計画では、テスト進行のステージごと、テスト序盤、中盤、終盤で、それぞれチェックポイントや対応プランを決め、リカバリプランの実施や、遅延リスクを最小限に抑える仕組みを盛り込んでおくことが大事だね。
たとえば、遅れを取り戻すために、要員を増やしてテストを実施することもあるだろうし、バグがたくさん発生している原因を探るために、設計またはコードのレビューを実施しなきゃならないこともあるだろう。
だから、進捗率やバグ発生状況を日々または週次でまめにチェックし、万一の場合は、早めに手配できるよう動くことだね！

あなた： 開発メンバーは、自分たちの首をしめないように管理意識を持つべきですよね。 面倒がらずに、日々のテストケースの予実の入力やバグ票の入力もきちんとしなければいけないですね。

佐竹さん： そのとおりだね！進捗をリアルタイムでチェックできるよう、活きたデータを収集するためにメンバー達にも協力をして欲しいね。
ぜひ、円滑なテスト管理と進行ができるよう協力してくれ！

ふたり： はい！頑張ります！

・更なる品質向上のための取り組みとは？

あなたが各設計書からテスト項目を洗い出し、テストケースを作成したと想定してください。
では、そのテストケースは、ちゃんと要件にあったテストケースなのでしょうか？あるいは、要件を検証できるテストケースを抜けもれなく作成できているでしょうか？
テストケースの精度を高めるためには、こういった観点での確認が必要です。この確認を『要件トレース』と言います。

「システムは完成したけれど、期待している要件が実装されていないじゃない！」
「適切なテストがおこなわれなかったために、思わぬバグが本番で発生！」
なんてことにならないよう、テストケースを作成した際に要件との紐付を行うことをおすすめします。
今回は、テストに着目したトレースとしてご紹介していますが、要件トレースという活動では要件定義書と基本設計書、要件定義書と詳細設計書というふうに、設計書が要件どおりの記載内容になっているかを確認するためのトレースも行います。

また、円滑にテストを管理するためにはテストケース仕様書を規定しておくと良いでしょう。各チームで独自のテストケース仕様書を作ってしまうと進捗データの収集がたいへん難しくなりますので、プロジェクトで共通のテストケース仕様書を規定しておくことをお奨めします。
テストケース仕様書の例としては、

• ・テスト内容
• ・テスト環境
• ・実施ステータス
• ・実施結果
• ・テスト開始予定/実績日
• ・テスト終了予定/実績日
• ・要件トレース(要件定義書、基本設計、詳細設計の記載個所入力)
• ・不具合管理(バグ票とリンク)など
  テスト管理に必要な項目を記載しておきましょう！

また、ただでさえ忙しくなりがちなメンバーの負荷を減らすためには、日々の進捗入力に対する工夫が必要です。入力項目は最小限、かつ、十分な情報が取得できるように工夫する必要があります。

後述するBTS では、要件、テストケース、バグ情報を入力し、要件×テストケース、テストケース×バグ情報などをリンクさせて管理することができます。要件トレースにも活用できるので、利用を検討してみるとよいでしょう。
BTSには、様々なツールがありますので、ASTERの『テストツールまるわかりガイド』などを参考にしてみて下さい。（参考：http://www.aster.or.jp/business/testtool_wg.html）

通常はテストを全て完了し、バグも全て改修できた状態でリリースしますが、実際のところ、『どうしても改修が間に合わないけれど、本番稼働する』という状況もあります。
そのような場合は運用対処となったり、制限事項として取り扱う間に改修を完了させたりすることになります。
皆さんがテスト業務に関わるときには、目前のテストケース予実に着目するだけではなく、工程の初めから終わりまで品質を意識した管理や試みを実践していきましょう。

・受入テストとは？

新人・中村さんとともに、「テスト」とは何か？をご理解、または再認識していただけたでしょうか。
システム開発における最後のテストは、ユーザー側（システム開発を発注した側）で、要件どおりにシステムが動くことを確認したり、誤りや要件の抜けもれがないかを検証したりする『受入テスト』です。
ユーザー側のテストになりますが、開発側として協力するシーンが多々あります。
ここでは、そんな一例を見てみましょう。

受入テストを担当するTypeスポーツの菊池さんから、テストについて相談をされました。

菊池さん： テストも順調そうですし、品質も上がっているようですね！我々も、納品されたら直ぐに受入テストが始められるよう、準備を進めています。
予定では、受入テストを3つのフェーズにわけて実施しようと思っています。
もはや、そう多くのバグは出ないだろう、とは思っていますが、バグが出て改修をお願いする場合に備えて、我々とＭＫテクノロジーサービスさんとの間で、バグ情報や改修状況を共有したいと思っています。
いま、弊社で使っているＢＴＳを開放しますので、入力をお願いしたいのですが。

あなた： はい、弊社佐竹からもＢＴＳの協力については聞いています。
原因の調査内容、対応予定日や完了日を入力し、対応をご報告したいと思います。
納品したものが突き返されないよう、納品までに更にテストを頑張ります！

菊池さん： あはは！我々も容赦なくテストを頑張りますよ！
あと１つ相談があるのですが・・・ 受入テストの際に、我々も大量データ投入テストを行いたいと思っているのですが、テストデータを作るのに少し手間取っています。
確か、ＭＫテクノロジーサービスさんで大量データ作成ツールを作って、それでテストをすると総合テスト工程に入る前の品質評価会議で伺いました。
大変恐れ入りますが、我々にもそのツールを使わせて貰えないでしょうか？

あなた： あぁ、あれはホント簡単なExcelのツールですよ。
でも便利に使えると思いますので、ぜひ使ってください。佐竹にも報告しますのですぐにご提供しましょう。

菊池さん： ありがとうございます！これで受入テストもやりやすくなります。

あなた： そういえば、受入テストを3つのフェーズに分けて実施されるとのことですが、最終フェーズは、運用受入テストですよね。
運用手順書の作成も弊社で進めていますので、運用受入テストにおける正常系テストと異常系のテストについて、弊社もご協力させていただきます。

菊池さん： そうですね、ＭＫテクノロジーサービスさんには、沢山サポートして頂きたいと思っています。
この前試しに新システムをテストさせてもらいましたが、なかなか使い勝手も良いし、オススメ情報なんかも楽しく提案してくれますね。
早くお客様にも、このシステムでお買い物して頂きたいなぁと思いましたよ！

あなた： ありがとうございます！そうおっしゃっていただけて嬉しいです。

菊池さん： それでは、本番稼働まで、良いシステムを一緒に作っていきましょうね！

ユーザーの受入テストも無事完了した後は、いよいよ本番環境へのシステム移行です。
システム移行を失敗しないためには、移行にかかわる計画、移行後に実施するテスト準備、本番稼働可能とする基準などを作成しておくことが必要です。

例えば、連休を利用して金融機関がシステム移行を行うことがあります。この場合システム移行の翌日、関連する会社などが参加して取引のテストが行われます。大きな問題がなければ本番稼働へGOサインが出ますが、問題が発生した場合は旧システムに戻す作業や問題となる処理を停止するなど、機能縮退して本番稼働することになります。
こうして、本番稼働の直前のさらに直前まで、テストし続けていると言っても過言ではありません。

さて、今回はテストに関わる手法や作業などについて、広く浅くではありますがご紹介しました。テストは単に動くモノを確認することだ、バグを見つける厳しい作業だ！なんて思うと辛くてやる気も削がれます。
しかし、いかにそのシステムをより良くしていくか、使う人が喜んでくれることを期待しながら臨むと、テストも楽しく好きになってきませんか？
さぁ、本番稼働まであともう一息です。皆さん、頑張りましょう！