ソフトウエアテストがうまくいかない原因はテスト工程より前にもある。序盤で整備すべきプログラムや文書の管理の仕組みが不十分だと、終盤の不具合改修で機能に異常が出るようなトラブルに陥る。設計工程でつぶすべき仕様段階の欠陥を残したまま開発を進めてしまうと、テスト工程で深刻な不具合が見つかって改修作業が膨大になってしまう。

 ソフトウエアテストで発生する問題の原因は、必ずしもテスト工程内にあるとは限らない。テスト工程より前に実施しておくべきことができておらず、それがテストで問題として顕在化している場合もある。

 典型的なのが、不具合の改修や機能追加のためにバージョンアップを行った結果、それまで動いていた機能で異常が生じる「デグレード」である。必ずしも1つの理由に絞れるものではないが、多くの現場で問題となるのが「構成管理」の不備だ。構成管理とはプログラムや文書のバージョン、テスト環境や本番環境への適用状況を管理すること。不十分だと誤ったバージョンを基に開発やテスト作業を実施してしまう。

 このほか、そもそも仕様に欠陥があるという「仕様バグ」もテスト工程よりも前に問題がある例だ。仕様バグは要件定義や設計担当者の勘違いや文章作成ミスで生じる。ほかの仕様との間で矛盾があったり、実装やテストが不可能だったりする。この問題を抱えたまま開発を進めると、テスト工程で大きな手戻りを必要とする深刻な不具合が見つかる。設計工程の間にドキュメントの検証プロセスを実施して、問題を見つけるようにする必要がある。

改修したら品質が低下
構成管理と運用フローを整備

 結合テストフェーズでデグレード(デグレ)の発生に気づいた―。冷や汗が流れる瞬間だ。不具合の改修や機能の追加をしたところ、それまで正常に動いていた機能が動かなくなったりする。場合によっては、テストの全面的なやり直しが必要になる。

 筆者が経験したあるプロジェクトでは、結合テストの開始から1週間が経過した段階でデグレを発見した。業務フローの最初に登場する機能で発生していたため、後続する機能の全てに影響した。その結果、1週間分のテストをやり直す事態となった。別のプロジェクトでは、デグレに気づかずにデータ移行のプログラムを実行するというトラブルを経験した。テラバイト単位のデータがほぼ異常値となり、リリース時期を延期せざるを得ない状況に陥った。

 デグレが発生する原因は複数あるが、よく見かけるのがソフトウエアのバージョン管理を行う「構成管理」の不備だ。構成管理の整備が遅れた現場では、古いプログラムを基にバージョンアップ作業をしたり、誤ったプログラムをリリースしたりといったミスが起こりやすい。デグレとは異なる問題も引き起こす。開発環境には最新バージョンがあるのに、テスト環境には1つ前のバージョンがリリースされているといった状況になりやすいのだ。テスト環境に存在するソフトウエアが本来想定していたソフトウエアではないと、実施したテストが無駄になってしまう。

 こうした問題があると、最悪の場合にはテストの停止、全てのテストのやり直しにまで発展する。トラブルを未然に防ぐため、プロジェクトの早い段階で構成管理を整備しよう。

 構成管理とは、プログラムや文書などの成果物のバージョン管理を実施すること。テスト環境や本番環境にどのバージョンが適用されているかの記録と確認も実施する。「Subversion」や「Git」といったツールによる成果物のバージョン管理をする仕組みの整備に加え、構成管理の運用をするための体制や作業フローの整備も欠かせない。

 構成管理を整備できている現場では、プログラムのバージョン管理は構成管理の担当者が担う(図1)。そのためバージョン管理の不備によるデグレが起こりにくい。テスト環境へのプログラムのリリースは構成管理の担当者が実施し、開発環境とテスト環境で差異が発生する問題を避けやすい。

図1●構成管理の整備の有無による違い
[画像のクリックで拡大表示]

 一方、構成管理が整備できていないプロジェクトでは、開発者がローカル環境でプログラムを管理して、個別にビルドをする。誤ったバージョンで作業をして、デグレを引き起こしがちだ。また、テスト環境へのリリースで開発者の足並みがそろわず、古いバージョンがテスト環境に存在してしまったりする。

要件定義フェーズまでには方針を決める

 構成管理の整備では(1)構成管理工数の認識、(2)運用フローの整理、(3)アーキテクチャーの整理の3つが重要なポイントとなる。以下では、この3つを詳しく解説する。

 1つめの構成管理工数の認識は、見積もりのタイミングと見積もり方法が重要となる。

 タイミングとしては、できるだけ早い段階で実施する。構成管理の方針を要件定義フェーズまでに決める必要があるからだ。メンバーがプログラムや文書(成果物)の作成を始めてからでは遅い。方針を決めずにプロジェクトを進めると、メンバーが独自に成果物を管理せざるを得なくなる。成果物がいったんバラバラになってしまうと、それを集めて整合性を取るのに多くのコストや時間を要する。

 見積もり方法としては、作業をボトムアップで洗い出し、工数の積み上げで見積もりを行ったほうがいい。プロジェクトマネジャーの多くは「構成管理の工数は全体の規模や成果物に対して何%」といったざっくりとした見積もりで見切り発車しがちだ。往々にして工数が不足している。人員や予算に不足があると、構成管理の整備が遅れたり、運用が不十分になったりする。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら