PR

 2004年6月、記者はこの欄で、ソフトウエアのテストに関するある記事を執筆した。タイトルは「なぜ『テスト』は軽視されるのか?」である。この記事では、IT業界で“テスト軽視”の風潮が広がっている現実を語り、その改善を訴えた。「その通りだ」「今その対策を打っている」――。読者の皆様から、さまざまなご意見をいただいたことを覚えている。

 それから6年半近くが経った今、この状況はどうなったのか。記者は日経SYSTEMS 2010年12月号で「バグをなくそう 悪条件に負けないテストの秘訣」と題して、テストに関する特集を担当した。ここで多くの開発現場を取材した結果、今ではテスト軽視の風潮はほとんど見られなくなったと感じている。現場にはテストの計画書がしっかりあって、品質目標も明確になってきた。テストの技法や管理に関する教育も、かなり進んでいるようだ。

どんどん難しくなる「テスト」

 ところが、テスト軽視の風潮が弱まる一方で、肝心のテストは以前よりもどんどん難しくなっている。背景には、外部システムとの連携が増えたことでテストそのものが大規模化・複雑化したこと。あるいは、システム開発の短納期化によってテストの時間が削られたり、コスト削減のあおりでテストを担当するメンバーの数が絞られたりしていることが挙げられる。テストの不備がシステム障害に発展して問題化する例も多いだけに、もはや“軽視”している状況ではないようだ。

 むしろ最近は「テストフェーズこそPM(プロジェクトマネジャー)の力量が問われる」とさえ言われるようになった。もちろん要件定義や設計、実装フェーズも難しさを増している。だがテストフェーズの難しさはそれ以上。テストを成功させるには、PMのスキルが非常に重要になってきた。

 今回の特集記事では、第一線のPMの方々が実践する、具体的な取り組みを紹介している。いったいどんな取り組みなのか。以下では、3人の例を紹介したい。

複雑なテストを見渡す「1枚計画書」

 一人目のPMは、中堅ベンダーに勤めるAさんだ。Aさんの問題意識は「分かりづらいテスト計画書」にある。テスト軽視の風潮が弱まると同時に、何十枚にも及ぶテスト計画書が現場に現れた。その難解さゆえにメンバーが内容を理解できず、認識のズレや誤解を生んでいるという。

 Aさんがこの状況を打開するために取り入れたのは「1枚計画書」である。A4用紙1枚にまとめたテスト計画書には「単体テスト」「結合テスト」「総合テスト」のように工程を区切り、その概要をコンパクトに記載した。ここに、スケジュールや主体、作業場所のほか、テスト環境の種類やテストデータの入手先などを記載。テスト対象や対比すべき仕様、粒度やカバレッジ(網羅率)、テストと並行する作業なども簡潔に明記している。

 詳細なテスト計画書も作る。だが、テストに関する用語は人によって想像するものが異なることが多い。Aさんは、こうした問題を1枚計画書によって解消することを目指した。

利用者目線をテストに盛り込む

 大手メーカーでPMを務めるBさんは、V字モデルを前提にしたテスト計画に異を唱える。V字モデルとは、開発の流れをフェーズに分けて、要件定義の結果をシステムテストで、基本設計の結果を結合テストで、詳細設計の結果を単体テストで検証する開発プロセスである。テスト計画時には、設計書や仕様書からテスト対象やテスト観点(どのようにテストするか)を抽出していく。

 V字モデルに沿ったテスト計画は手法として確立されており、それ自体に問題があるとはこれまでされていなかった。そもそも設計書や仕様書通りにシステムができているかどうかを検証するのがテストだ。これを徹底するために、PMは力を注いできた。

 しかしBさんは、(利用者がテストに参加する)受け入れテストや運用テストの段階で、大きな手戻りが発生するという事態に何度か見舞われた。このため仕様書・設計書だけでなく、利用者目線を早い段階からテストに盛り込まなければ、プロジェクト後半の手戻りは避けられないと判断したという。

 そこでBさんは、テスト計画時に設定するテスト観点について、V字モデルだけでなく、旧システムを操作して抽出したり、運用マニュアルに記載している内容を参考にしたりしている。またテスト観点を探るために、テスト開始前に利用者による「内覧会」も開催。システムに対する利用者の意見を事前に聞く場を設けている。

テストツールは「Excel」から

 テスト軽視の風潮が薄れるにつれて、テストツールの導入に挑んだ現場も少なくないだろう。しかし、単体テストなど一部を除いて、テストの自動化を取り入れている現場はまだ少ない。

 中堅システムインテグレーターに勤めるCさんも、テストの自動化を推進してきた。だが、コストや習熟の負担が大きく、たびたび挫折。そこで行き着いたのが、Excelを使ったテストツールの開発だった。

 Cさんは「Excelを使ったテストツールは、手軽な上に効果が大きい」と語る。例えば、テストデータを生成する作業をExcelで自動化した。テスト対象のDBのテーブル定義とデータ定義をExcelシート上に設定して実行ボタンを押せば、自動でテストデータ作成用SQLが生成されるというものだ。

 バッチ処理のテスト結果をチェックする作業もExcelで自動化した。バッチ処理後のデータをDBから自動で抽出し、あらかじめ設定した期待値と照合させて合否判定をしてくれる。このほか、所定のフォルダに保存した画面キャプチャーの画像を、Excelシートに自動で張り付けるマクロも作った。これをテストのエビデンス(証跡)として利用する。Cさんは「Excelによる自動化は、市販のツールの導入よりも前に検討すべきだ」と強調している。

 これらの取材で分かったのは、テスト軽視の風潮は見られなくなったこと。そして、テストへの意識が高まり、テストのセオリーが現場に広く浸透してきたことだ。ところが、テストがそれ以上に難しくなっており、なかなか突破できなくなっている。“テスト重視”に様変わりした今、現場では悪条件に勝つために、教科書には書いていないさまざまな工夫が求められている。