Testing と 私と 苦い出来事
この記事は、TDD Advent Calendarの20日目。
cubeon さんの 後になります。
http://atnd.org/events/22027
http://d.hatena.ne.jp/cubeon/20111219
今日は、Developer Testing について私の過去の苦い経験を１つお話しします。
この体験は私の中で Testing について強く印象に残っている５本のエピソードの中の１つです。
この出来事は、時々思い返します。
（Testingの苦い経験とか、ちょっと趣向の違う記事あってもいいよね！）
はじまり
あれは今から数年前、私が社会人２-３年目で、 TDDや XPに初めてトライした プロジェクトのでした。Java開発者向けに、とあるフレームワークをつくるというプロジェクト。このプロジェクトには、XPやTDDを強く支持している外部コーチや先輩の人たちがいました。私は先輩から多くを学び、ある種の驚き（え？red-green- refactor てこんなに小さく回すの!?等々）とともに がむしゃらに吸収していました。私にとって、とても貴重な体験で TDDの大ファンになりました。幾つかお話ししたいエピソードがあるのですが、今日のお話ししたいことではないので先に話を進めます。
雲行きが少し怪しく
リリースしてから数ヶ月、フレームワーク利用者から数ヶ月何度か問い合わせが、たまに来ていました。メールベースでやり取りしていたのですが、私は特に問題視しておらず、軽くメールで応答し、新機能をつくることに気をとられていました。ちなみに、この頃には、先輩やコーチは抜けて、チームサイズは小さいながら私が初めてプロジェクトの新米リーダーでした。老練のリーダーなら、この段階でプロジェクトの不吉な匂いを察知し、対策アクションをとるタイミングだったかもしれません。
転落
しばらくすると、リリースしたフレームワークに大きな機能的な欠陥があることの報告を正式に受けました。
この話を聞いたとき、かなり慌てました。別件の機能開発の件も進捗が芳しくない中、既存の修正も必要ということで、プロジェクト炎上確定。途方に暮れる状態で、会議室で文字通り「orz」 の体勢になっていたと記憶しています。修正リリース日の設定をお客様とお話するのに、かなりヒリヒリしていました。
「エンドユーザーにとって役立つフィーチャーか」を 捕らえる Testing 活動を出来ていたのか？
「テストを記述していたか？」と言えば、かなり歯を食いしばって記述／実行していたプロジェクトだと
自負しています。多分、それが盲点を生み出した１つの要因だと思います。
開発者目線の テスト記述 に熱中するあまり、ユーザー目線の機能性に関する Testingの活動、 特に機能性に関するテスト項目を見つけ出す 「会話」 の時間が少なすぎたと思います。
見つけられた欠陥は、おそらく、現地に行って0.5 -1h、どう使われているかを話をしていれば
もっと早くに見つけられるテストケースだったと思われます。実際は、長い間放置されていました。
後だしじゃんけんの見解ですが、普段のユーザーストーリーの 満足条件となる実例の話をする時、
定期リリース時、「雲行きが少し怪しく」の 問い合わせが増えたタイミングが一つ確認するターニングポイントだったのでしょう。
私の教訓
Developer Testing 活動は、注意しないと、開発者目線で、熱中するあまり、エンドユーザー
目線を失いがちです。もし、開発の際にテストコードとプロダクションコードを記述することに
の多くの時間を割き、顧客やユーザーとの対話に時間をほとんど割いていないのであれば、読みや
すく、修正しやすく、テストしやすいコードだが、エンドユーザーが使えないストーリーをつ
くり込んでいる罠に落ちっているかもしれません。お気をつけてください。
その後
実は、その後、Developer Testing とんでもなく、助けられました。何を修復すればよいのかを
的確に把握できればこっちのものです。修正リリースまでを、なんとかこぎ着けたのですが、
テストの自動化なしに短期間でつくり込むのことは出来なかったと思います。
私の 過去の経験のなかで、最もドライブ感のある Testing サイクルでした。ここの話も自分の中では、
Testing の貴重な体験でお話したいところですが、長くなってしまうので、この記事は、ここまで
にしたいと思います。
次は Tugu Katagiriさんです。
http://blogs.wankuma.com/esten/archive/2011/12/21/232961.aspx
