文書ドリブン開発テスト文書編：システム開発プロジェクトの現場から（27）（2/2 ページ）

» 2009年09月14日 00時00分公開

[宮本和洋，アクセンチュア・テクノロジー・ソリューションズ]

テスト関連文書は品質保証書

　時計などの品質保証書であれば「耐圧水深100m」などと書かれていたり、貴金属であれば「純度99.99％」など、その製品の品質がかなり定量的に示されています。これがソフトウェアになると定量的に示すことが非常に難しくなります。せいぜい「数キロステップ当たりに数件のテストを実施」といういわゆるテスト密度と呼ばれる指標と、テスト実施当たりのバグ発生件数、いわゆるバグ密度くらいが定量的に示せる限度でしょうか。しかしCOBOLなどで書かれたプログラムであればまだしも、昨今のオープン系の言語では「キロステップ」を指標に使うことには疑問を感じるところがありますし、そもそもテスト密度とバグ密度がどの程度であれば高品質であるか明確ではありません。お客さまにシステムの品質を説明する際にこういった定量的なものであっても納得してもらうのが難しいため、お客さまにどのようにソフトウェアの品質を納得してもらうのかは常に悩みの種なのですが、実は品質保証にはほかの観点もあります。

　品質保証の別の観点とは「プロセスの保証」（という観点）です。つまりどういう過程を経てテストを実施したのか、テストの確認体制はどのような形になっていたのか、それらは正常に機能しているのかということを確認するものです。例えばテストプロセスを定義した文書が存在しているか、テストレビューにどの程度の時間を費やしたか、テスト結果についてお客さまの確認と承認を得られているかなどが「プロセスの保証」をするものとなります。

　よって「プロセスの保証」をするための文書を作成しておくことはテストの品質を保証するという意味で必須であることが分かります。この文書に記述されている手順に従ってテストを実施することで成果物の内容、記述レベル、テストのアプローチをテスト実施者のスキルや経験によらずに実施することが可能になります。

テストデータの再利用

　テスト工程ではテストの再利用を目的としてテストコード、テストデータなどを残しておく場合もあります。そもそもプログラムのテストは特定のデータを実行した際に得られる結果を検証する作業ですから、テストデータの再利用はテストケースの再利用と同等の意味を持っています。テストデータの保存の仕方は、エクセルで保持する場合、テスト用データベースに丸々残しておく場合、テストコードにテストデータ投入の処理を埋め込む場合などさまざまですが、いつでもそのテストを再現できるように何らかの形で残しておくことに変わりはありません。

　テストデータの作り方はテストの効率とテストの再現性に大きく影響を及ぼすものであるため、テストデータ作りのルールは厳密に規定しておくべきであると考えます。以下に簡単にテストデータの作り方に関するルールの例を紹介しておきます。なお、ここで触れるテストデータの作り方に関するルールの例はテスト条件（同値分析や限界値分析）を満たすためのテストデータの作り方の観点とは異なりますのでご注意ください。


ルール（例）	ルール内容（例）
マスタデータはチームまたはプロジェクト共通のものを利用すること	・テスト時のデータはプロジェクト共有フォルダ内にあるダンプデータをインポートしてから実施してください・共通マスタデータはたびたび更新されます。更新情報は関係者に連絡をしますので、連絡受領後は速やかに各テスト環境のマスタデータをアップデートしてください・各テスト環境に個別にデータを追加することは原則認めません。テストに必要なデータが不足している場合はテストデータ管理チームにデータ追加申請をしてください
トランザクションテーブルの定義変更は即時実施すること	・トランザクションテーブルは更新される場合があります。更新情報は関係者に連絡をしますので、連絡受領後は速やかに各テスト環境に更新用のスクリプトを実行してください
正常系と異常系のデータ範囲は分けること	・正常系テストについては顧客番号10000～39999までを、異常系テストついては顧客番号40000～69999までを使用してください・システム例外を敢えて発生させる異常系テストは70000～79999までを使用してください
参照系と更新系のデータ範囲は分けること	・売上データの追加・更新をする場合、売上番号は40000～69999までを使用してください
図2　テストデータの作り方ルール（例）

　ここで述べたことはテストの条件とデータの再利用というテストの効率を上げるためだけの取り組みと考えがちですが、これはテストの品質を均一にするという意味でも重要です。テスト実施の前提条件が異なっていてはテストの実行結果で何を信じていいのか分からなくなってしまうのです。前提条件を合わせることでテスト品質を維持します。

　よって、テストの前提条件（データ以外にも環境、モジュールのバージョンなども含みます）を合わせるためにも、この前提条件は明文化しておくことが望ましいのです。単独で文書として存在させる必要はなく、テスト計画書の中の章の1つとして記載することでも構いません。

テストに必要な文書とは

　ここまででテストに必要な文書に関するヒントを説明してきました。最初に書いた問い（「どういうインプットが必要なのか？」）に対する答えは以下です。

テストプロセスに関すること
テストすべき機能の仕様
テスト実施の前提条件（主にデータ面）

　こうして書いてしまうと至ってシンプルですが、果たしてこの3つをしっかり示したうえでテスト作業を指示できているでしょうか。2のテストすべき機能の仕様だけを渡して「テストよろしく！」と簡単に作業を依頼してはいないでしょうか。前述しましたが、テスト文書というのはソフトウェアの品質保証書ですから、どういった目的と手順、方法があるのかをまずはしっかりと示し、そのうえでテストの結果を示すというのが「非の打ちどころのないテストの実施」を証明する最短の方法なのだとわたしは考えています。

連載を振り返って

　わたしが文書というものにこだわりを持つようになったのは、ペーパーレスを推進するためのITシステム構築のはずなのに、構築する作業そのものの過程で大量の紙資源が消費されることに驚きを感じたことがきっかけです。そこで今回のわたしの連載はすべてシステム開発プロジェクトで作成される文書というものを中心に据えて連載してきました。

　連載ではさまざまな文書を紹介してきましたが、これは無駄に文書を作ることを推奨するわけではなく、むしろ逆に文書作りの手間を必要最小限にすることで、よりエンジニアが「考える・作る」という作業に専念する方法はないのかという問題提起をしてみたかったためです。

　この連載が、システムの品質を維持しつつ、構築作業での紙資源の大量消費を防ぎ、エンジニアの仕事量の削減の一助になれば幸いです。

筆者紹介

アクセンチュア・テクノロジー・ソリューションズ　マネジャー

宮本和洋（みやもとかずひろ）

メインフレームからWebシステムまで数々のシステム開発を経験し、実装可能なプログラム言語は10を超えるシステム開発のエキスパート。「システム開発者だって楽をしたい！」をモットーにし、楽をするための苦労なら買って出るというやや矛盾したポリシーを持つ。風呂場やトイレでいいアイデアが浮かぶことが多いので、狭い空間が大好き。特技は同時に2台のPCでまったく別のプログラミングができること。

「システム開発プロジェクトの現場から」バックナンバー