【中級】無駄なく確実にテストする 総論 テストの3つの基本知識

表1●ソフトウエア・テストを実施する上で知っておくべき項目（■は本記事で解説する項目)

[画像のクリックで拡大表示]

図1●設計工程を意識してテストする<BR>Vモデルでは，設計工程とテスト工程が対応している。例えば，結合テストは基本設計に対応しているため，このテスト設計書は基本設計書を参考に作成する。また，テスト工程が進むほど，発見されたバグの修正にコストがかかる。そのため，設計工程でテスト項目を考えることで，仕様の曖昧さを排除しておきたい

[画像のクリックで拡大表示]

図2●テスト工程に応じてテスト実行者は変わる<BR>テスト工程が進むにつれ，テストに関わる部門や人数は増える。ユーザーや運用部門など，参加が必要な部門にあらかじめテスト・スケジュールを伝え，早めに準備を進めておくことが重要だ

[画像のクリックで拡大表示]

　大規模なシステム障害が後を絶たない。みずほ銀行のシステム移行トラブル，航空管制システムの停止，ジャパンネット銀行のシステム・ダウン——。社会的なインフラと呼ぶべきシステムも多く，私達の生活にも少なからず影響を及ぼしている。

　システムの信頼性や品質は「テスト」でしか確認できない。上記のトラブルも，テストやテスト管理の不足により，バグが発見できなかったり，発見できても的確な対策が打てなかったことに起因している。では，果たしてどれだけの開発者が「自分達のシステムは“十分な”テストを実施した」と言えるだろうか。

　本記事では，ソフトウエア・テストの流れに沿って，その知識と手法を解説する。開発期間が短期化する一方，システムはより複雑化している。このような厳しい状況にもかかわらず，基本を押さえた上で，漏れのない的確なテストを整然と実施することが求められている。テストの手法を学ぶ前提として，テストの流れ，テストの目標，テスト管理という3つの基本知識を整理しておこう。

　企業システムの開発で実施すべきテスト項目を表1[拡大表示]に示した。テストの流れは，システム構築の上流工程と表裏の関係にあり，「Vモデル」で表現できる（図1[拡大表示]上）。要求定義で決定される品質目標は，基本設計，詳細設計，コーディングと進むにつれて詳細化される。詳細化された品質の目標は，単体テスト，結合テスト，システム・テスト，運用テストの各工程で確認する。そして品質を積み上げた結果が，本番稼働するシステムになる。

　テストの作業は，計画，設計，実施から成る。テスト計画では，開発工程のどの時期にどのテストをどのように実施するかを決定する。計画は，開発プロジェクト発足時に立案する。

　設計とはテスト・ケースを作成する作業である。これは，要求定義や設計工程と並行して手掛けておきたい。コーディング終了後にテスト設計を始めると，システムの表面的な機能や操作に着目した狭いテストで満足してしまうことが多い。システム品質を大局的にとらえたテストが設計しにくくなる。テストすべき項目は，要件定義や設計工程で定めた仕様と対応するものだ（図1下）。そのため，例えば基本設計書を基にして結合テストのテスト設計書が作れない場合，基本設計が妥当性を欠いている可能性がある。

「バグ0」は目標にしない

　テストを効率的に実施するには，その目標を明確にする必要がある。筆者の経験上，目標を明確にするのとしないのでは，テストに対する“やる気”やバグ対策の立案などに大きな差が出てくる＊1。

　テストの目標は，大きく2つある。一つは，問題の早期発見/対策を目指した「バグ取り」。もう一つは，問題がないことを証明するための「保証取り」である。テスト工程の早い時期（単体/結合テスト）ではバグ取りを，後工程（システム/運用テスト）ほど保証取りを重視するのが一般的だ。

　テスト前のコード100行当たりには，平均1個～3個のバグが潜むといわれる。複雑化したシステムではコード以外にもバグや問題は多く潜む。加えて，テスト期間は「システム開発期間全体の3分の1」が理想だが，昨今の短期開発では圧縮される一方だ。

　当然だが，システムごとに求められる品質には差があり，“十分な”テストのレベルは異なる。社会インフラを担うシステムと社内利用に限るシステムでは，コストや開発期間，求められる信頼性は段違いだ。

　ただし，優先度を持ってバグをつぶし，バグが無いことを保証していく，というステップは共通している。後述する制御パスの実行基準などから，摘出したいバグの数の目標や必要なテスト期間を設定したい。

管理が品質を左右する

　テスト工程は，参加人数も実施項目も多く，しかも入り組んでいる。各人の作業プロセスを最適化して，明確な品質目標までテストを導くためには，管理作業が欠かせない。

　テストの工程が変われば，テストを実施する主体者は変わる（図2[拡大表示]）。例えば，運用を知らない開発部門では適切な運用テストを実施することは難しい。そのため，単体/結合テストは開発部門が，移行/運用テストは利用/運用部門が主体となる。システム・テストは，その中間に位置付けられ，品質保証部門が主体となる場合が多い。

　このように工程が進むにつれ，テストの規模は大掛かりになる。発生したバグの修正にも時間がかかる。限られた期間の中でより効率的に品質を向上させるには，次のテスト工程で何をテストすべきかを事前に知り，その土台となるように現在のテストを実施する必要がある。それぞれの工程で十分に品質を上げてから，次のフェーズに移るべきことは言うまでもない。

　テストを担当する開発者は，要求分析や設計レビューに立ち会い，システム要件や設計指針，何よりシステムに求められている品質を十分に理解する必要がある。

　さらに管理者には，豊富なテスト経験と勘所を押さえた立ち回りが求められる。テスト管理では，随時品質の状況と向上度合いを把握して，計画を調整していく。このテスト管理がうまくいくか否かで，同じ品質を達成するまでの時間は大きく変わる。管理項目や使用する資料も多いが，読者にはぜひここまで到達して，高い品質を確保できるプロのエンジニアになってほしい。それでは表1に従い，単体テストからテスト工程を解説していく。