自動化以前の失敗談
ギア本について、いろんな方がブログなどでまとめや感想を発信されていてとても嬉しいです。ここではそうした内容のまとめ、というよりも、テストに関わる筆者の拙い失敗体験をご紹介します。期間的には2000年ぐらいから現在までの約15年間です。ギア本の原著は1999年刊行ですので、もし私がこの本に出会う機会に恵まれ、英語の壁はあるものの、買って読もうと思えば読めた時代の話と思って読んでください。
最初は、テスト自動化以前の失敗談です。
2000年ごろ、Java EE（当時はJ2EEと呼んでいました）の仕様がようやく固まり、WebLogicやWebSphereなどの商用製品がぼつぼつ出始めて、エンタープライズ系開発でもJavaの採用が増えていました。ただStrutsのようなフレームワークも特になく、開発ではJSPやサーブレットを直にごりごり書いていました。「JSPに業務ロジックを書くとメンテナンスできないから書いてはいけない」といった開発規約があった時代です（今だとサーバサイドもJavaScriptで書いてしまうぐらいなので隔世の感があります）。
筆者はそれまで担当していた仕事が一段落し、「Web内製フレームワーク」の開発に移りました。そこでは、フレームワークの1機能を開発したり、フレームワーク自体を商用Java EEサーバに載せ替えて動作を検証したりしていしました。
そうこうしているうち、実案件の話が持ち上がります。とある製造業のお客様向けイントラWebシステムです。自分の役割はその「Web内製フレームワーク」の普及活動だと思っていのですが、プロジェクトの怒濤の流れに飲み込まれ、そのまま異動になって開発の一兵卒（ソルジャー）として働くことになりました。
当時、筆者はテストについて全くの素人でした。かなり昔のことなので詳細は忘れてしまいましたが、おそらく以下のような感じでテストをしていたように思います。
- 仕様書をコピー＆ペーストして語尾を「を確認する」に変換（現在このやり方にはCopy, Paste & Modify、略してCPM法というあだ名がついています）
- 単体テストフレームワークはなかった（JUnitの登場は2002年ごろ）
- 機能仕様以外のテスト観点があるとは思いもよらなかった
- パフォーマンスは全部出来てから確認するものだと思っていた（結局時間切れでトラブル発生）
テスト技法の1つである「エラー推測」の実例としてよくいわれる、いわゆる「～」化け問題に遭遇したのもこのプロジェクトが初めてでした。現在では漢字コードは上から下までUTF-8で揃えるのが当たり前になっていますが、データをSJISで格納していてシステムはJavaで、という時代にはつきものの悩みでした。
品質は推して知るべしで、このころは土日でも頻繁に電話で呼び出されたものです。
開発はその後も粛々と進みましたが、だんだん敗色が濃厚になってきました。マルチベンダでの開発だったのですが、だんだんとシェア（担当する仕事の配分）が下がっていきました。このとき、私の尊敬する先輩が「テストの仕事が取れなかった」とくやしそうに語ったことが、今でも頭から離れません。ライバル企業のテスト設計書を見せてもらいましたが、すでに品質機能展開（QFD）に近いことをやっていて、確かにこれはかなわないなと思いました。
この話でギア本第1章から学んだ教訓
改めて当時のことを振り返ってみると、次のような状態だったといえます。
- そもそもテストで何を確認するかがわかっていない
- そのテストの方法がわかっておらず、アドホックに同じようなところをムダにテスト
- 経験が少なくバグの知識が溜まっていなかった
- テストで失敗するとお客様は実際に離れていく
この最後のポイントが、筆者をテストや品質への道に駆り立てました。
この失敗ケースの体験と『システムテスト自動化 標準ガイド』の第1章でシンクロする部分を挙げてみます。
- 「テスティングは一種のスキルである」
-
プロジェクトの開始当初、筆者はテストについて興味も関心もありませんでした。しかし、ライバル企業のテスト設計を見て、技法や方法論を知らないのは罪だと身にしみたので、以降テスト関連の本を読みあさりました。
- 「まずいテストのやり方」
-
テスト要求分析やテスト設計がそもそもまずいとうまくいかないというのは、自動化以前の問題です。実際、開発現場はカオスの連続です。方法論を学ぶだけではなく現場で使ってもらう必要があったので、テスト計画のテンプレート作りや普及活動にも注力することにしました。
