DevLOVE Test Day「我々は、テストで世界を繋げる。」

DevLOVE初参加。
熱いうちにOutput。感想中心です。

Tracの導入にあたりいろいろ調べていたとき、昨年10月のShibuya.tracでのRyuzeeさんの資料をみつけて、プレゼン聞けなかったことが非常に残念だったので、今日聞けるのが楽しみだった。

* @Ryuzee さんによる発表「テストについて考える(仮)」
資料はこちらにアップされている
http://www.slideshare.net/Ryuzee/devlove-6720342

すごくわかりやすいプレゼン。資料の写真もきれい。
agileについて話していて、開発全体を捕らえているのが素晴らしいと思った。
(自分に欠けているので)

現在のプロジェクト事情にあてはめていろいろな気付きをもらった。

★品質とはどれだけビジネス価値を生むかということ

→以前おききした平鍋さんのはなしとかと同じ考え方
　今の開発は顧客対話が足りない。反省。なんとかしよう。

★完了条件(Definition of DONE)を顧客と握っているか？
→握れてない。現状スタンドアロンアプリのリプレイスなので、基本要件は変わらないけど、アプリ形態が変わるのでその動作などは早期に機能要件確認をとらないと。

★テストの4象限でCIできるよ！
→単体テスト×
　　やってない
　GUIテスト○
　　やってる。NUnitForms使用
　受け入れテスト△
　　ここはテスト部隊の厳しい人手チェックに頼る。
　　テスト環境へのデプロイ、データ以降、外部I/Fとのデータ連携はある程度自動化)
　非機能要件テスト×
　　やってない。やらなきゃ！！！

★単体テストはやってない
→単体(各レイヤごとの)テストは自動化はあきらめている。これはRyuzeeさんもやってないといっていたし、いつか見たt_wadaさんのスライドにも、ある程度粒度の大きいテストがTDDでは有効だとい話もあり、勇気付けられる。
GUIのテストは書いている。ここのメンテコストはそれなりにかかるが、頻繁にリファクタしていくときはやはり大きな力となっている。仕様変更にどう対応しやすくするかはいろいろと工夫が必要な感じだが、それも困ったときに一番いい形に変更していきたい。
重複テストコードのリファクタ。
DBレイアウト変更→テストデータ一括変更ツールなど。

★テスト結果はチーム、顧客が評価
→テストケースは日本語名である程度どんなテストをするのかがわかるので、顧客(または顧客に近い立場の人)に網羅性確認してもらうぐらいはすぐにでもできる。
　

明日からやろう。

* @haru01 さんによる発表
　「XPをベースに　AcceptanceTesting入門を解説するよ。(仮)」

顧客と1つのチームになってぐるぐる回すといいものができるヨ。
agile的な
テストは顧客とのコミュニケーションツールとなる。
FIT。良いソフトウェアは、顧客とのコミュニケーションとコラボレーションを求める。
　

* 話し合い

なんと昨日講演を聞いたtomohnさんと同じテーブルに。
机の上に出された本は何故かtomohnさんのヤンジャンｗ。

印象に残ってるのは、JaSSTのパネルディスカッションでツールベンダの立場で参加した際、「ツールは必要ないです」と話したとのこと。
ツールがテストするのではなく、あくまでサポート。チームでテストするのが重要だよねということ。
ここでも完了条件というかテストを評価するのはだれかという話がでて、Ryuzeeさんの話と同じく、品証ではなく、チーム、顧客だ、という話に。

Webの機能テストをseleniumで書いている人がいたけど、要件が結構変わってテストケースをそのたびに書き直しになるのでとてもメンテナンスコストに合わないとのこと。
テストのメンテナンスコストは自分のところでも問題になるところ。
コンテキスト毎にどんな対策を採ればいいのかは変わるんだろうけど、対応に当たっての工夫の事例もいろいろ見てみたいな。でもうちからもOutputできないといけないな。

あと自動テストは通っても、見た目あきあらかにありえないようなものがあがってくるのはどうなの？という人が2人もいた。
UIテストをしないとこうなる？
またテストケース自体に漏れがあるとその後で発覚してしまう。ある程度は仕方ないけど、ペアプロ、レビューなどでテスト側の精度もあげていかないと。

DevLOVE、熱くて、いい雰囲気で気付きもあり、とても楽しかった！
ありがとうございました。

#ああ、もうこんな時間。。。
#そういえば、t_wadaさんがいて、今日たまたまプログラマが知るべき97の・・本を持っていたので思わずサインしてもらった。ありがとうございました。