システム開発における「第4コーナー」テスト工程で注意すべきポイント：明日から使えるシステム開発プロジェクトの進め方 再入門（5）（1/3 ページ）

本連載では、システムを外部に発注する事業会社の側に立ってプロジェクトをコントロールし、パフォーマンスを最大化するための支援活動をしてきた筆者が、これまでの経験を基に、プロジェクト推進の勘所を解説していく。今回は、製造工程の後に控えるテスト工程で注意すべきポイントや6つの品質特性、品質分析について解説する。

[前岩浩史，ウルシステムズ]

テストは緻密に計画し、結果を分析すべし

　システム開発プロジェクトの進め方をあらためて解説する本連載「明日から使えるシステム開発プロジェクトの進め方 再入門」。前回の「基本設計をスムーズに進めるための5つのポイント――要件定義書の読み合わせ、データ構造、IPO、外部接続」では、設計工程のうち基本設計の進め方を解説した。基本設計以降は、開発プロジェクトは詳細設計、製造、テスト、移行と進んでいくものだが、詳細設計と製造の各工程は採用する技術によって進め方やポイントが異なるため本連載では対象外とする。今回は製造工程の後に控える“テスト”を取り上げる。

　テストはシステム開発における「第4コーナー」だ。プロジェクトメンバーは疲れを感じ始める一方、いったんは形を成したという安堵感も出てくる頃だろう。これが落とし穴になる。「動いているから大丈夫だろう」「決められた期限までにやれるだけテストしよう」といった油断や無計画が横行しやすい。

　システムは実際にリリースし、安定稼働して初めて完成といえる。テストをおろそかにすれば本稼働後に問題が発生して業務に影響を来しかねない。あるいは本来の目的が達成できずに「使われないシステム」になってしまうこともある。そうならないためにテストはしっかりと実施しておきたい。

システム特性とテスト内容を早期に明確に策定する

　テスト工程の最大の眼目はコスト・期間と「品質」のバランスである。いくら「品質」を高めるためとはいえ、際限なくテストすることはできない。テストに費やせるコストと期間は限られている。両者のバランスをとるのは意外と難しい。必要十分かつ効率的にテストするにはどうすればよいのか。

　場当たり的ではムダなテストを繰り返すハメになる。必要なのはテストの戦略を持つことだ。「単体テスト」「結合テスト」「ユーザー受け入れテスト」など、各テストで何を検証するのか目的を明確化し、メリハリを付けて工数を投下する。

　その上で、実施結果を定性的・定量的に分析する。

6つの品質特性を踏まえて、各テスト工程でテストの観点を網羅する

　テストを実施するポイントを確認する前に、テストによって高めるべき「品質」とはそもそも何なのかを確認し直してみよう。

　エンジニアは「一つ一つの機能が正しく動作し、システム全体の整合性が取れていればよい」と考えがちだ。しかし、実際にはそれだけでは不十分である。例えば、使い勝手。入力すべき項目が散逸していたり、処理結果がなかなか表示されなかったりするシステムの完成度は「高い」とは言えない。

【中途半端なシステムの例】

• ボタンの位置や名称が画面ごとに異なっている
• エラーの発生時に具体的な内容を利用者に提示していない（例：システムエラー）
• エラーの原因究明に必要な情報をログに出力していない
• 処理結果を表示していない（正常終了なのか異常終了なのか分からない）
• アプリケーションをリリースするたびにシステム全体を停止する必要がある

　要件定義の段階でこうした項目を見落とすことは少ない。しかし、テスト工程になるとすっぽりと抜け落ちていることがよくある。しかし、いずれも立派なシステムの「要件」である。テストでは、こうした機能をチェックするための「観点」を盛り込む必要がある。

ISO/IEC 9126で定める6つの品質特性

　テスト観点を網羅するためにはソフトウェア品質特性の考え方を取り入れるとよい。ISOはソフトウェアの品質評価に関する国際規格「ソフトウェア品質特性：ISO/IEC 9126」を定めている。これによれば、ソフトウェアの品質は「機能性」「信頼性」「使用性」「効率性」「保守性」「移植性」の6つで構成される。

　これらをどのテスト工程で確認するのかを決めておけば、抜け漏れがなくなる。テストケースのレビューでは、「これらの観点を確認するためのケースが含まれているか」をチェックするのだ。

プロジェクトごとにテストの戦略を立てる

　テストに対するイメージは人によって異なるし、あるべき姿はシステムの性質によって変化する。だからこそ、プロジェクトごとにテストの戦略を立てる必要がある。ただ漫然とテストをこなすだけでは、「どのテストで何を検証するのか」「どんな要素に重点を置くべきなのか」など、本当はやらないといけないテストを漏らしたまま、あるいは深掘りできないままテスト期間が終わってしまう。

　個別のテストの計画（総合テスト計画など）はそれぞれ実施前に検討すればよいが、全体のイメージはなるべく早い時期に「方針」を打ち出していくべきだ。具体的には要件定義が完了した時点で「システム特性」を見極め、「品質」をどう作り上げていくか検証の道筋を定義するのがよいだろう。

　システム特性は非機能要件から導き出すことが多い。例えば、以下のようなイメージだ。

【システム特性】

• 加盟店からのAPI同時接続数は100とする
• 各APIのレスポンスは500msec以内とする
• 毎日12時までに、前日分の集計情報をA、Bシステムからの取得できるようにする
• データベースのデータは13カ月保持する。データの最大保持件数は日次集計情報であり、月次で2500万件のデータ量を想定している
• 登録、更新、削除はログだけでなく、データベースに保存し、ユーザー側で確認できるようにする
• 月次の請求情報は月初4時までにファイルサーバで出力し、ダウンロードできるようにする
• ユーザー情報はデータベース収録時に暗号化し、ログにも暗号化前の情報を出力してはいけない
• デプロイではシステムを止めずにリリースできる。バッチ処理は個別の処理終了をチェックしたリリースを考慮する
• ユーザーのロールは8タイプあり、権限によって利用できる画面のみならず、表示する情報も変動する
• ロック機構は楽観ロックとし、先勝ちとする
• 締めの検証のために、テストではシステム日付を先日付けに設定した検証ができる
• などなど

　特性を考える際、機能要件はひとまず脇に置くといいだろう。なぜなら、内容があまりに細か過ぎるからだ。例えば、「XX業務は申請受付から5営業日以内に完了させる。申請受付から4営業日時点で完了していないものはアラートを上げる」といった要件を特性とすると、記載すべき項目は数限りない。結果として目を通さなくなってしまう。機能要件に関わる事項は各テストの計画書に検証事項のサマリーとして記載しよう。