DevLove 実践アジャイルテスト読書会 #3

DevLove 実践アジャイルテスト読書会に行ってきました。
毎月1回、翔泳社さんをお借りしてやっているのですが、地震の影響でしばらく中断。久々の開催でした。

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

この会では、実践アジャイルテストをあらかじめ読んできて、気になったことやみんなに聞いてみたいことをざっくばらんに話していたりします。
昨日話したことをマインドマップに描いていたので、公開してみます。

いくつか書き残しておきたいことを列挙してみます。

技術的負債

WFだと技術的負債を溜めに溜めた結果、テストフェーズで負債解消しようとしてもしきれず保守フェーズにまで回してしまう。
アジャイル…というよりTDDやCIなどテスト自動化の仕組みを導入すると技術的負債をあまり溜めることなく開発がすすんでいくから、やっぱりいいんだなぁと。
既存のソースコードがあってそいつがテストファーストとかされていないと、技術的負債がたまっていて、どうにかしたくてもなかなかどうにかできないのかなと。
レガシーコード改善ガイドのテクニックを使いこなせるようでないと、戦い挑んでもしんどい戦いになっちゃうのかなと。

レガシーコード改善ガイド (Object Oriented SELECTION)

定義がわからない

実践アジャイルテストで書かれているプロジェクトや、テスト4象限はどういった世界を対象にしているのかなという話も出てきました。
どうも製品開発のような感じがあると話では出ましたが、とらえ方次第では、製品でもWebサービスでも受託開発でもあてはまるんじゃないかなぁ。

TDD・CIやってる？

僕も含めてみんななかなかできてないようで。でも、みんな現場でなんとかしたいともがいていたりします。（ってことでいいのかなぁ＞参加者の皆様）
でも、テスト仕様をテストフェーズに入ってから決めるよりも、テストファーストで書いたほうが品質があがるという話を聞いて、やっぱそうなんだなぁと。
本のなかでは、テスターは単体テストを書くべきでないと書いています。それは確かにそうなんだけど、だからといってそこにこだわって手をつけれないようであれば、テスターが単体テスト書いて、プログラマがソース書いたほうがよっぽどいいなと思いました。

テストの止めどき

例外系のテストをどこまでやったらいいんだろうかという話です。
画面を通してのテストの場合は、最低限正常系はやっておくといいよという感じで平鍋さんからお話を聞いたことがあります。単体テストの場合は、システム障害系のテストとかはきつそうだなぁというのが僕の間隔。正常シナリオ・代替シナリオはこなしておきたいなぁと思うのですが、どうなんでしょう。

ミニウォーターフォール

第2章あたりで、ミニウォーターフォールという概念が出てくるのですが、どうやらテスト自動化の仕組みなどを設けず、WFの開発方法でタイムボックスを区切って機能単位開発をしたりすると、ミニウォーターフォールになってしまうようで。
この罠にひっかかって「アジャイルだめじゃん！」って言ったりしたチームもあるのかなと。

感想

マインドマップでCIうまくできなかったと書いてあるのは、僕のことです。昔CC.net+MSBuildの組み合わせでネット上の記事を見ながらやろうとしたんだけど、なかなかうまくできなくて。
既存のコードベースに乗せようとしたのだけど、負債もたまっていたのかな。結局うまくいかなかったことがありました。
でも、今日の会に出てみて、「やっぱCIやらなきゃいかんな」と思ったので、今度の休みにちょっと時間を割いて、CIの環境作りを試してみようと思う。